Description of problem: Please read rather long thread. http://forums.fedoraforum.org/showthread.php?t=171223 Mount doesn't behave correctly. 1/ in the initrd init script 2/ If you use a previous kernel/initrd, disk are indicated as mounted, but are not.
mount(8) is not part of any initrd image. The nash has build-in mount implementation. Sorry, but I don't see any relation between initrd and mount(8). Fedora/RHEL boot process: 1. grub loads kernel & initrd 2. kernel converts initrd to normal RAM disk 3. kernel starts /init script from initrd (interpreted by nash) 4. nash mounts /dev /proc /sys 5. nash initialize system (load modules, ...) 6. nash umount /dev /proc /sys 7. nash mount / (root) 8. nash calls pivot_root 9. nash exec /sbin/init 10.init starts /etc/rc.sysinit <-- the first place where we have mount(8)
There are 2 problems that are linked together. 1/ Boot process fails at step 7 (nash doesn't find /dev/root). 2/ If I launch F8 through an F7 (2.6.23-21) vmlinuz+initrd, but pointing on the F8 partition rc.sysinit starts then fails, launching a rescue shell. From this shell: 'mount' -> all the filesystems are correctly mounted 'ls /usr' -> empty result 'mount -a' complains about /dev/pts already mounted 'ls /usr' -> now it's OK. The filesystems seems to be mounted, but are not !!!! Whereis the problem ? Thank you PS : As you can see in this thread, there are some people affected with an unbootable F8 partiton, either new or upgrade.
(In reply to comment #2) > 2/ If I launch F8 through an F7 (2.6.23-21) vmlinuz+initrd, but > pointing on the F8 partition rc.sysinit starts then fails, Any error message? What's the latest output from init scripts? (I need to locate where in the init script it fails.) > launching a rescue shell. > > From this shell: > > 'mount' -> all the filesystems are correctly mounted Please, I'd like to see output from: cat /proc/mounts cat /etc/fstab cat /etc/mtab blkid (in the rescue shell)
Sorry for responding late at this mail. I reproduced the problem on F7, so I lost control of my computer. I was not able to regain control by using rescue disk. I had to reinstall an neew fedora system on the same lvm volume to be able to reboot my principal F7 partition. One specific issue : I have a encrypted partition and /etc/crypttab contains one line ______________________________________________________ # /etc/crypttab clear_root /dev/raid1/enc_root none ______________________________________________________ in /etc/fstab ___________________________________________________________________________ /dev/mapper/clear_root /root ext3 defaults 1 2 ___________________________________________________________________________ initrd was generated from the rescue disk, with the crypted fs unmounted. ===> same problem. /etc/fstab contains a reference to /dev/mapper Obviously, in some circonstances mkinitrd generate a bad initrd file. This is not linked specifically to F8. I will try to reproduce the faulty initrd and make a diff. More data to come.
Have you encountered the same problem in the final release of F9?
No, but I did a fresh install of F9, not an update. And Up to now, I didn't migrate my principal partition (because of KDE 4). Sorry
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