I have an FC9 system that has been working just fine with the 2.6.26.5-45.fc9.x86_64 kernel. I recently performed a yum update which upgraded the kernel with several other updates to 2.6.26.6-79.fc9.x86_64. The system no longer boots successfully since the upgrade with the new (now default) kernel. However, if I select the old -45 kernel, all appears to function correctly. However, this is a problem in that it limits my upgrade path for this box. My system is 64bit box with a hardware supported (not LVM or software) RAID 1 installation. My install does not use LVM and is built on ext3 file system. The failed boot with the new -79 kernel produces as switchroot failure similar to the following: Loading ext3 module Trying to resume from /dev/dm-a unable to access resume device (/dev/dm-1) Creating root device Mounting root filesystem mount:error mounting /dev/root on /sysroot as ext3: No such file or directory Setting up other filesystems Setting up new root fs setuproot: moving /dev failed. No such file or directory no fstab.sys, mounting internal defaults setuproot: error mounting /proc: no such file or directory setuproot: error mounting /sys: no such file or directory Mount failed for selinuxfs on /selinux : no such file or directory Switching to new root and running init unmounting old /dev unmounting old /proc unmounting old /sys switchroot : mount failed: No such file or directory Booting has failed. Additional details regarding this problem as well as others experiencing the same boot problem following a yum update can be found in this thread: http://forums.fedoraforum.org/showthread.php?t=202549 The thread also includes details of my attempts to rerun mkinitrd as well as rerunning mkinitrd with various RAID preloads .... both attempts produce the same switchroot failures on boot. Finally, I'm including (below) the contents of several files that you may wish to have as you diagnose this. I'd greatly appreciate you attention to this issue as this has stopped our upgrade path for Fedora. ________________________________ My grub.conf includes: # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/mapper/isw_bbjcddjgif_Volume0p3 # initrd /initrd-version.img #boot=/dev/mapper/isw_bbjcddjgif_Volume0p1 default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title Fedora (2.6.26.6-79.fc9.x86_64) root (hd0,0) kernel /vmlinuz-2.6.26.6-79.fc9.x86_64 ro root=UUID=baac05cd-cb93-473d-86f2-775547ad7358 rhgb quiet initrd /initrd-2.6.26.6-79.fc9.x86_64.img title Fedora (2.6.26.5-45.fc9.x86_64) root (hd0,0) kernel /vmlinuz-2.6.26.5-45.fc9.x86_64 ro root=UUID=baac05cd-cb93-473d-86f2-775547ad7358 rhgb quiet initrd /initrd-2.6.26.5-45.fc9.x86_64.img title Fedora (2.6.25-14.fc9.x86_64) root (hd0,0) kernel /vmlinuz-2.6.25-14.fc9.x86_64 ro root=UUID=baac05cd-cb93-473d-86f2-775547ad7358 rhgb quiet initrd /initrd-2.6.25-14.fc9.x86_64.img ____________________________ My /etc/fstab includes: UUID=baac05cd-cb93-473d-86f2-775547ad7358 / ext3 defaults 1 1 UUID=63724ed0-4aec-439f-b7cb-46bea100821d /boot ext3 defaults 1 2 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 UUID=e08c1f51-2d93-4030-acb1-7da50a655707 swap swap defaults 0 0 ________________________________ My /boot includes: total 21713 -rw-r--r-- 1 root root 80174 2008-05-01 04:16 config-2.6.25-14.fc9.x86_64 -rw-r--r-- 1 root root 82841 2008-09-20 01:31 config-2.6.26.5-45.fc9.x86_64 -rw-r--r-- 1 root root 82852 2008-10-17 12:29 config-2.6.26.6-79.fc9.x86_64 drwxr-xr-x 3 root root 1024 2008-10-16 14:50 efi drwxr-xr-x 2 root root 1024 2008-11-05 20:55 grub -rw------- 1 root root 3014124 2008-10-16 14:53 initrd-2.6.25-14.fc9.x86_64.img drwxr-xr-x 12 root root 1024 2008-10-29 16:13 initrd-2.6.26.5-45.fc9.ppc -rw------- 1 root root 3028297 2008-10-17 19:12 initrd-2.6.26.5-45.fc9.x86_64.img drwxr-xr-x 12 root root 1024 2008-10-29 16:11 initrd-2.6.26.6-79.fc9.ppc -rw------- 1 root root 3036217 2008-10-30 16:10 initrd-2.6.26.6-79.fc9.x86_64.img -rw------- 1 root root 2983615 2008-10-30 16:05 initrd-2.6.26.6-79.fc9.x86_64.img.ORIG drwx------ 2 root root 12288 2008-10-16 14:40 lost+found -rw-r--r-- 1 root root 1118248 2008-05-01 04:16 System.map-2.6.25-14.fc9.x86_64 -rw-r--r-- 1 root root 1153739 2008-09-20 01:31 System.map-2.6.26.5-45.fc9.x86_64 -rw-r--r-- 1 root root 1154746 2008-10-17 12:29 System.map-2.6.26.6-79.fc9.x86_64 -rwxr-xr-x 1 root root 2069432 2008-05-01 04:16 vmlinuz-2.6.25-14.fc9.x86_64 -rwxr-xr-x 1 root root 2141072 2008-09-20 01:31 vmlinuz-2.6.26.5-45.fc9.x86_64 -rwxr-xr-x 1 root root 2143536 2008-10-17 12:29 vmlinuz-2.6.26.6-79.fc9.x86_64
I'm having a similar problem with both 2.6.26.6-79.fc9.x86_64 and 2.6.27.5-37.fc9.x86 kernels. The only difference is I get the error: Buffer I/O error on dev sda3 logical block 1092467968 (logical block 1092467968?. The box is set up as a raid 0 and works fine with the install kernel (2.6.25-14).
something changed during .26 -> .27 which has upset mkinitrd. For some reason it doesn't set up md devices any more.
Can you attach the initrd for the new and old kernels?
This has nothing to do with drivers becoming built-in. It's not even a 2.6.27 kernel problem...
(In reply to comment #4) > This has nothing to do with drivers becoming built-in. It's not even a 2.6.27 > kernel problem... Correct, this appears to be a problem with 2.6.26.6-79.fc9.x86_64 following a yum update from a perfectly functioning 2.6.26.5-45.fc9.x86_64 system as described in my original submission. I will attach initrd-2.6.26.5-45.fc9.x86_64.img and initrd-2.6.26.6-79.fc9.x86_64.img as requested anf will greatly appreciate any and all help in getting this resolved.
Created attachment 324265 [details] Original (pre yum update) initrd file Original (pre yum update) initrd file
Created attachment 324266 [details] Post yum update initrd Post yum update initrd
When booting 2.6.26.5-45.fc9.x86_64 kernel does dmraid segment fault? Mine does--when I stated above that: "The box is set up as a raid 0 and works fine with the install kernel (2.6.25-14)" I lied. This is true only after I do a dmraid -ay. This appears to be due to the fact the ids in /dev/mapper differ on each boot (at least they differ from what's in fstab).
(In reply to comment #8) > When booting 2.6.26.5-45.fc9.x86_64 kernel does dmraid segment fault? Mine > does--when I stated above that: "The box is set up as a raid 0 and works fine > with the install kernel (2.6.25-14)" I lied. This is true only after I do a > dmraid -ay. This appears to be due to the fact the ids in /dev/mapper differ > on each boot (at least they differ from what's in fstab). Booting 2.6.26.5-45.fc9.x86_64 works flawlessly for me. I ave problems after a yum update to 2.6.26.6-79.fc9.x86_64....
ok, I have same problem with fake raid on intel dp35dp mobo. read my comments 30 and 32 in bug 313411 https://bugzilla.redhat.com/show_bug.cgi?id=313411 would people stop breaking stuff that works ???
Hello, I was have same the problem. When this will be fixed? Thank you.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.