Bug 499746

Created attachment 342944 [details]
Log from mkinitrd -v test.img $(uname -r)

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.

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.

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).

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.

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.

> 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.

This should be fixed in the next build of anaconda.  Thanks for the bug report.