Bug 391641 - Fedora 8 doesnt boot after install
Fedora 8 doesnt boot after install
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
x86_64 Linux
low Severity urgent
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-11-20 03:07 EST by Pierre Juhen
Modified: 2008-12-07 08:49 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-12-07 08:49:49 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Pierre Juhen 2007-11-20 03:07:06 EST
Description of problem:

Please read rather long thread.  


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.
Comment 1 Karel Zak 2007-11-20 08:43:36 EST
mount(8) is not part of any initrd image. The nash has build-in mount

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)
Comment 2 Pierre Juhen 2007-11-20 11:21:50 EST
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.

Comment 3 Karel Zak 2007-11-20 16:09:17 EST
(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

 (in the rescue shell)

Comment 4 Pierre Juhen 2007-11-21 15:35:40 EST
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.

Comment 5 Andy Lindeberg 2008-07-14 16:38:04 EDT
Have you encountered the same problem in the final release of F9?
Comment 6 Pierre Juhen 2008-07-17 16:08:08 EDT
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).

Comment 7 Bug Zapper 2008-11-26 03:36:01 EST
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: 

Note You need to log in before you can comment on or make changes to this bug.