Description of problem: Kernel complains when Python-based init fails due to config/build error on x86_64 Not 100% sure that this is the kernel package at fault or some post-processing (dracut-009-6.fc15.noarch ??) which depends on my machine state. But even if it it was dracut and not the kernel package, I can't seem to find out why it was run from yum. Version-Release number of selected component (if applicable): 2.6.38.5-22.fc15.x86_64 2.6.38.5-24.fc15.x86_64 2.6.38.6-26.rc1.fc15.x86_64 2.6.38.6-27.fc15.x86_64 How reproducible: Seems to be tied to recently introduced Python initscripts. Every kernel since 2.6.38.4-20.fc15.x86_64 has python-based init and has failed. Steps to Reproduce: Install fc14 from LiveCD Upgrade to fc15 with preupgrade, be happy. Later try to yum upgrade kernel. Be unhappy. This is why we keep old kernels. Remove rhgb and quiet flags and boot again to capture logs Actual results: [ 1.335239] sda: sda1 sda2 [ 1.335623] sd 0:0:0:0: [sda] Attached SCSI Disk [ 1.341148] scsi 1:0:0:0: CD-ROM hp CDDVDW TS-L633R 0200 PQ: 0 ANSI: 5 [ 1.351501] sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray [ 1.351687] cdrom: Uniform CD-ROM driver Revision: 3.20 [ 1.351982] sr 1:0:0:0: Attached scsi generic sg1 type 5 [ 1.354285] Freeing unused kernel memory: 948k freed [ 1.354706] Write protecting the kernel read-only data: 10240k [ 1.361808] Freeing unused kernel memory: 1528k freed [ 1.370852] Freeing unused kernel memory: 1728k freed Could not find platform independent libraries <prefix> Could not find platform dependent libraries <exec_prefix> Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>] ImportError: No module named site [ 1.378728] Kernel panic - not syncing: Attempted to kill init! [ 1.378895] Pid: 1, comm: init Not tainted 2.6.38.6-27.fc15.x86_64 #1 [ 1.379030] Call Trace: [ 1.379127] [<ffffffff8146c72c>] panic+0x91/0x19c [ 1.379224] [<ffffffff8105848d>] do_exit+0x7c/0x732 [ 1.379351] [<ffffffff81058dc8>] do_group_exit+0x7a/0xa2 [ 1.379446] [<ffffffff81058e07>] __wake_up_parent+0x0/0x28 [ 1.379542] [<ffffffff81009bc2>] system_call_fastpath+0x16/0x1b Expected results: A shiny boot animation and working Linux system Additional info: Compaq Presario CQ56-115DX Notebook # There is no site.py -- Should init.py have -S to get around this? $ gzip -dc /boot/initramfs-2.6.38.6-27.fc15.x86_64.img | cpio -it | egrep '[.]py[co]?$' usr/libexec/initramfs-olpc/activate.py usr/libexec/initramfs-olpc/olpc_act_gui_server.py usr/libexec/initramfs-olpc/greprelease.py usr/lib64/python2.7/site-packages/bitfrost/leases/__init__.py usr/lib64/python2.7/site-packages/bitfrost/leases/core.py usr/lib64/python2.7/site-packages/bitfrost/leases/errors.py usr/lib64/python2.7/site-packages/bitfrost/leases/keys.py usr/lib64/python2.7/site-packages/bitfrost/leases/crypto.py usr/lib64/python2.7/site-packages/bitfrost/util/json.py usr/lib64/python2.7/site-packages/bitfrost/util/__init__.py usr/lib64/python2.7/site-packages/bitfrost/__init__.py usr/lib64/python2.7/site-packages/olpc_act_gui_client.py process.py 137146 blocks $ gzip -dc /boot/initramfs-2.6.38.6-27.fc15.x86_64.img | cpio -itv | egrep ' (usr/bin/python|init)$' -rwxr-xr-x 1 root root 9144 Apr 12 09:15 usr/bin/python -rwxr-xr-x 1 root root 4732 Feb 22 10:01 init 137146 blocks # Is this a yum/packager problem? c.f. http://koji.fedoraproject.org/koji/rpminfo?rpmID=2548226 # size mismatch? compare to 20971520 $ ls -l /boot/initramfs-2.6.38.6-27.fc15.x86_64.img -rw-r--r--. 1 root root 27720111 May 20 17:27 /boot/initramfs-2.6.38.6-27.fc15.x86_64.img
Removing dracut-modules-olpc-0.5.8-1.fc15.x86_64 and rebuilding the initramfs worked for me. It's a little non-intuitive that the kernel package would be modified inflight like this by rpm/yum. Perhaps this bug should be moved to dracut-modules-olpc or dracut?
In Comment #1 of Bug 621001, Mr. Hoyer gives advice on systems which do not need them, a list of yum modules should not be installed lest the install of a new kernel package fail. This seems to be a common problem, since Bug 621344 is attributed to the same root cause. Would it be impermissibly needy to request that the default dracut config ignore the module or modules loaded by dracut-modules-olpc if, as the case appears, that package supplies two alternate dracut configs intended for use with those modules? I lack the ability to move this bug from the kernel component to dracut now, but would point out that I found it easy to install dracut-modules-olpc while possibly looking for any docs or devel packages associated with dracut. Thanks.
dracut-modules-olpc really should alter the "check" script/function to check if it is really a olpc. Or the check should return 255 and a config file should pull in the module. Of course the config file should only have the add_modules=".." on a olpc and should not be shipped with dracut-modules-olpc itsself.
Created attachment 516967 [details] Patch for dracut modules for olpc I wrote this patch with the help of the maintainer, following the advice of Harald Hoyer. Regards!.
dracut-modules-olpc-0.6.0-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/dracut-modules-olpc-0.6.0-1.fc16
dracut-modules-olpc-0.6.0-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/dracut-modules-olpc-0.6.0-1.fc15
Package dracut-modules-olpc-0.6.0-1.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dracut-modules-olpc-0.6.0-1.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-14107 then log in and leave karma (feedback).
dracut-modules-olpc-0.6.0-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
dracut-modules-olpc-0.6.0-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.