Bug 499746 - Installed system fails to boot; could not find filesystem '/dev/root'
Installed system fails to boot; could not find filesystem '/dev/root'
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-07 17:57 EDT by Jason Tibbitts
Modified: 2009-05-11 15:11 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-11 15:11:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
ls -l /dev after chroot /mnt/sysimage (8.80 KB, text/plain)
2009-05-07 17:57 EDT, Jason Tibbitts
no flags Details
Log from mkinitrd -v test.img $(uname -r) (7.12 KB, text/plain)
2009-05-07 17:58 EDT, Jason Tibbitts
no flags Details

  None (edit)
Description Jason Tibbitts 2009-05-07 17:57:05 EDT
Created attachment 342943 [details]
ls -l /dev after chroot /mnt/sysimage

Using a fresh set of rawhide images, an install in a KVM guest proceeds fine but the installed system fails to boot properly.  The last messages printed are (typed manually):

Creating initial device nodes
input: ImExPS/2 Gemeric Explorer Mouse as...

In bug 499057, Hans requested that I file a separate ticket and include the contents of /dev and a log from mkinitrd; I will attach those.  /dev seems to be properly populated, but I'm not expert.

I unpacked the initrd and removed the two plymouth calls, with the idea that they were eating some output.  Indeed that was the case; the output gets further:
  Creating root device.
  Mounting root filesystem.
  mount: could not find filesystem '/dev/root'
  Setting up other filesystems.
  setuproot: moving /dev/vailed: No such file or directory
and various other failures, down to:
  Booting has failed.
Comment 1 Jason Tibbitts 2009-05-07 17:58:45 EDT
Created attachment 342944 [details]
Log from mkinitrd -v test.img $(uname -r)
Comment 2 Jason Tibbitts 2009-05-07 18:06:42 EDT
Obviously the "setuproot" line above has been mangled by my poor typing; it should say
  setuproot: moving /dev failed: No such file of directory

One additional note is that when I boot into the rescue image and chroot to /mnt/sysimage, /dev is nearly empty.  I don't completely understand why it is not empty when I look at it during the installation process, but the modern dynamic /dev stuff is mostly a mystery to me.
Comment 3 Jason Tibbitts 2009-05-08 11:22:55 EDT
Information on the hardware was requested.  I don't really know what I can provide besides "it's a KVM guest"; it's a 64-bit guest configured with 2GB of RAM and 160GB of disk in an image file.  The network is bridged.  The host machine runs updated Fedora 10; Xeon X5355 CPUs with 16GB of RAM.

It was requested that I supply more information from the log before "Creating device nodes"; here's everything after the kernel messages.  I can try to type those kernel messages if you think they would be useful, but that's a good bit of typing so please let me know.

Freeing unused kernel memory: 1304l freed
Weite protecting the kernel read-only data: 1840k
Mounting proc filesystem
Mounting sysfs filesystem
Creating /dev
Creating initial device nodes
Setting up hotplug.
input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input3
Creating block device nodes.
Loading pata_acpi module
Loading ata_generic module
Creating root device.
Mounting root filesystem.
mount: could not find filesystem '/dev/root'
Setting up other filesystems.
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
Switching to new root and running init.
switchroot: mount failed: No such file or directory
Booting has failed.

I hope this is useful.
Comment 4 Jason Tibbitts 2009-05-08 11:29:25 EDT
Also, the system is currently using LVM although I did an install without using LVM but the behavior was unchcnaged.  I can do a non-LVM install if you like (guests are mostly free and it only takes a few minutes).
Comment 5 Jason Tibbitts 2009-05-08 14:15:17 EDT
Hey, guess what?  You shouldn't do this:

part / --size 518
part /boot --fstype ext3 --size 256
part swap --size=4096
part pv.0 --size=100 --grow
volgroup vg0 pv.0
logvol /usr --fstype ext3 --name=usr --vgname=vg0 --size=12000
logvol /scratch --fstype ext3 --name=scratch --vgname=vg0 --size=1024
logvol /tmp --fstype ext3 --name=tmp --vgname=vg0 --size=4096
logvol / --fstype ext3 --name=root --vgname=vg0 --size=1024
logvol /var --fstype ext3 --name=var --vgname=vg0 --size=8192

Note that / is specified twice.  I've been doing that ever since we started allowing / on LVM and somehow nothing ever complained about it so I never noticed the mistake.

It was suggested that this is still a bug and that anaconda should error out instead of creating an unbootable system, so I'll change the component and keep this open.  However, I wouldn't object if you wanted to close it IDIOTUSER.
Comment 6 Chris Lumens 2009-05-08 15:05:45 EDT
Seems like if you specify a given mount point twice, the later one should replace the earlier one.  We don't want to just error out if a mount point is listed twice because of some bizarre and seldom-used feature of kickstart where you can specify autopart and then redefine / to make it bigger/smaller/whatever.  Oh joy.
Comment 7 Jason Tibbitts 2009-05-08 15:52:24 EDT
> Seems like if you specify a given mount point twice, the later one should
> replace the earlier one.

That is what appears to happen in F10 and earlier; the erroneous '/' seems to simply be ignored.  But of course everything's been rewritten and I've had particularly poor luck getting my crufty kickstart files through the new code.
Comment 8 Chris Lumens 2009-05-11 15:11:42 EDT
This should be fixed in the next build of anaconda.  Thanks for the bug report.

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