Bug 391641

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