Description of problem: Kernel build 49 works fine. After installing build 63 I could'nt boot. Same problem with build 85. When I boot with 63/85 This is what I get on the screen. ...... Red Hat nash version 6.0.19 starting Unable to access resume device (LABEL=myswap) mount: could not find file system '/dev/root' setuproot: moving /dev failed: No such file or directory setuproot: error mounting /proc: No such file or directory setuproot: error mounting /sys: No such file or directory switchroot: mount failed: No such file or directory My guess is that there is a problem with LVM in these builds. My system is configured with LVM. Here are some details. [root@hp-brio ~]# pvs PV VG Fmt Attr PSize PFree /dev/sda2 POOL lvm2 a- 37.16G 32.00M [root@hp-brio ~]# vgs VG #PV #LV #SN Attr VSize VFree POOL 1 2 0 wz--n- 37.16G 32.00M [root@hp-brio ~]# lvs LV VG Attr LSize Origin Snap% Move Log Copy% myroot POOL -wi-ao 36.38G myswap POOL -wi-ao 768.00M [root@hp-brio ~]# Version-Release number of selected component (if applicable): Kernel 2.6.23.9-85.fc8 & 2.6.23.9-63.fc8 How reproducible: Install on a machine with LVM ? Steps to Reproduce: 1. 2. 3. Actual results: System not loading. Init is not starting. Expected results: Additional info:
Please attatch /var/log/dmesg from successful boot.
Created attachment 290276 [details] the dmesg file from a successful boot
Can you attach the initrd from a failing kernel and a working one? (They will be in /boot.)
Created attachment 290289 [details] Initrd for the working kernel
Created attachment 290291 [details] Initrd for the NON working kernel
Well, I've tried loading from a rescue CD, chrooting and recreating initrd, but the problem persists. Eliran.
Is someone working on this problem ? Is there anything I can do to help investigate the problem ? Thanks.
Looks like a bug in mkinitrd, or /etc/fstab was manually changed to use mount-by-label. The init script on the initrd is different: -49: resume /dev/POOL/myswap mkrootdev -t ext3 -o defaults,ro /dev/POOL/myroot -85: resume LABEL=myswap mkrootdev -t ext3 -o defaults,ro LABEL=myroot
This could be it, as I changed my system to use labels not very long ago (probably after installing F8). How should I proceed to solve this problem ? (Can I change back to NO labels then run mkinitrdm or should I use another procedure ?) Thanks.
Are all of the filesystems properly labeled? Everything should work if they are.
I've managed to bypass the problem by stopping to use labels. I'll look for a better solution later. Thanks !
I have this issue too, the labels didn't change (well not all, and certainly not the root's partition one) and what DID change was the drive "order" in /dev/ as I had to change my motherboard. So the '/' partition passed to be /dev/sda6 to be /dev/sdc6. How could I inspect the initrd images and change this in them? Thanks.
(In reply to comment #12) > I have this issue too, the labels didn't change (well not all, and certainly not > the root's partition one) and what DID change was the drive "order" in /dev/ as > I had to change my motherboard. So the '/' partition passed to be /dev/sda6 to > be /dev/sdc6. > > How could I inspect the initrd images and change this in them? > initrd files are .cpio.gz format. The "common problems" page tell how to examine them: https://fedoraproject.org/wiki/KernelCommonProblems
possible dupes bug 388901, bug 391641 my last working is kernel-2.6.23.8-63.fc8 http://tuju.fi/tmp/boot.e2.jpg
kernel-2.6.23.14-115.fc8 kernel-2.6.23.8-63.fc8 kernel-devel-2.6.23.14-107.fc8 kernel-devel-2.6.23.14-115.fc8 kernel-headers-2.6.23.14-115.fc8 115 didn't boot either.
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. 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 '8'. 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 8'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 8 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 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 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.