Bug 475495

possibly a dupe of 470628

You're the expert, Dave, but to me the bug doesn't sound related.  This isn't a pause... it just flat out won't boot at all... or if it is a pause, it's a _lot_ longer than 10 seconds.  Bug 470628 seems to have started at an earlier kernel than the one that breaks for me.

Bug 470628 does sound like it might be related to a different bug I filed, bug 468800.

I'll try the mkinitrd fixes though and see if that helps.

You could try adding --with=scsi_wait_scan to your mkinitrd invocation, or adding
MODULES="scsi_wait_scan"
to /etc/sysconfig/mkinitrd. I get a similar boot failure to you on one of my machines (root filesystem handled by aic7xxx) except that I get (IIRC) "No such file or directory" rather than "Invalid argument". It seems to be because it's trying to mount the root filesystem before the SCSI modules have finished starting up. Adding scsi_wait_scan works for me, but I don't know whether a) you have the same problem or b) this is a problem with the kernel or mkinitrd.

Could be related to bug 466534 ?

kernel-2.6.27.7-134.fc10.x86_64 does not fix this.

mkinitrd-6.0.71-3.fc10.x86_64 (via bug 466534) does not fix this; yes I regenerated the initrd.

Going to try both the scsi_wait_scan trick and the suggestion from bug 470628 right now.

Ah ha.  The working initrd I have for the older kernel was generated with mkinitrd 6.0.69.  I downloaded 6.0.70 from Koji and regenerated the initrd for the newer kernel (2.6.27.7-134.fc10.x86_64) and the system booted up just fine!

So it's something in mkinitrd 6.0.71 that breaks things for me.  It seems that -2 was the first package for f10 in that series; the -1 package revision in Koji is tagged as f11, so I'm not sure it's safe to test that.

Maybe whatever causes bug 468800 is also related to why the newer mkinitrd doesn't work?  It seems only me and one other person are affected by that one (that are reporting it, anyway), and it doesn't sound like anybody else is having this specific issue.

Let me know what else I can do to help fix this.  For now I'm just going to yum exclude mkinitrd/nash/libbdevid-python so I can update without breaking boot.

I tried mkinitrd-6.0.73-7 (rebuilt on F10 from the source RPM so it works with Python 2.5) and the error still occurs.  Every single mkinitrd since 6.0.70 generates unbootable initrd images.

I guess I'm also hitting this mkinitrd bug:
I use to have a self compiled kernel that is linus' git tree, but I've got nearly everything compiled in. Booting without "quiet" option I get to see:

Setting up hotplug.
Creating block device nodes.
Creating character device nodes.
Making device-mapper control node
Setting up disk encryption: /dev/sda4
key slot 0 unlocked.
Command successful.
Setting up disk encryption: /dev/sda5
key slot 0 unlocked.
Command successful.
Unable to access resume device (LABEL=SWAP)
Creating root device.
Mounting root filesystem.
mount: error mounting /dev/root on /sysroot as ext3: No such file or directory
"

rootfs is encrypted and is a labeled ext3 partition (name=ROOT). swap partition is labeled as "SWAP".
The funny thing is: The cryptsetup seems to complete successfully. But the mount of the rootfs fails. The question is why?

My mkinitrd version is:
$ yum info mkinitrd
Geladene Plugins: refresh-packagekit
Installierte Pakete
Name       : mkinitrd
Architektur : i386
Version    : 6.0.71
Ausgabe    : 3.fc10
Grösse     : 142 k
Repo       : installed

Relevant init "script" from initrd is:
"(cut)
mknod /dev/ttyS3 c 4 67
/lib/udev/console_init tty0
daemonize --ignore-missing /bin/plymouthd
plymouth --show-splash
echo Setting up hotplug.
hotplug
echo Creating block device nodes.
mkblkdevs
echo Creating character device nodes.
mkchardevs
echo Making device-mapper control node
mkdmnod
modprobe scsi_wait_scan
rmmod scsi_wait_scan
mkblkdevs
echo Setting up disk encryption: /dev/sda4
plymouth ask-for-password --command "cryptsetup luksOpen /dev/sda4 luks-sda4"
echo Setting up disk encryption: /dev/sda5
plymouth ask-for-password --command "cryptsetup luksOpen /dev/sda5 luks-swap"
resume LABEL=SWAP
echo Creating root device.
mkrootdev -t ext3 -o defaults,noatime,ro LABEL=ROOT
echo Mounting root filesystem.
mount /sysroot
cond -ne 0 plymouth --hide-splash
echo Setting up other filesystems.
setuproot
loadpolicy
plymouth --newroot=/sysroot
echo Switching to new root and running init.
switchroot
echo Booting has failed.
sleep -1"

Boot command line is "
ro root=LABEL=ROOT rhgb lapic_timer_c2_ok resume=LABEL=SWAP usbcore.autosuspend=1 nomodeset initcall_debug"

The root= and resume= options are pretty useless for encrypted disk as they are hard-coded into the init script of the initrd... But that's another story.

By the way: Why is the initrd file called ".img" and not ".cpio.gz" which is way more midnight commander friendly?

I see from the copied init file, that you've got noatime in your options field for / in fstab. This is know to break nash (and is never put there by any Fedora tools, you've put that there yourself).

Removing the noatime option from your entry for / in fstab should fix this.

Closing.

*** This bug has been marked as a duplicate of bug 296361 ***

Erm, scrap my last remark, the know issue is with norelatime, not with noatime, reopening, sorry for the spam.

For what it's worth, I tried both with and without relatime.  (I have not tried the noatime/nodiratime options.)

Is there any other information I should provide to help?  I'm at a total loss as to what to do, and so far even the F11 packages remain broken for me.  I was tempted to try a fresh F10 reinstall, but given it looks like that would just result in a completely unbootable system for me, I'm not really keen on risking it.  Same with F11 pre-releases.

Maybe some tweaks I should try to make to the mkinitrd code, or a way to enable more verbose log messages about what the message I'm getting is being caused by?

Did you rebuild your initrd after removing relatime? See bug #296361 comment #4

I was pretty sure I did, but I tried again with a newer version of mkinitrd and now it works when relatime is not there.  So I was wrong, and it is just the same bug about relatime not being supported, apparently.  My apologies.

(In reply to comment #9)
> echo Setting up disk encryption: /dev/sda4
> plymouth ask-for-password --command "cryptsetup luksOpen /dev/sda4 luks-sda4"
> echo Setting up disk encryption: /dev/sda5
> plymouth ask-for-password --command "cryptsetup luksOpen /dev/sda5 luks-swap"
> resume LABEL=SWAP
> echo Creating root device.
> mkrootdev -t ext3 -o defaults,noatime,ro LABEL=ROOT
> echo Mounting root filesystem.
> mount /sysroot
> cond -ne 0 plymouth --hide-splash
> echo Setting up other filesystems.
> setuproot
> loadpolicy
> plymouth --newroot=/sysroot
> echo Switching to new root and running init.
> switchroot
> echo Booting has failed.
> sleep -1"
> 
> Boot command line is "
> ro root=LABEL=ROOT rhgb lapic_timer_c2_ok resume=LABEL=SWAP
> usbcore.autosuspend=1 nomodeset initcall_debug"
> 
> The root= and resume= options are pretty useless for encrypted disk as they are
> hard-coded into the init script of the initrd... But that's another story.

maybe above statement is not totally true:
I need to change my boot command line to

"ro root=/dev/mapper/luks-sda2 rhgb lapic_timer_c2_ok resume=LABEL=SWAP usbcore.autosuspend=1 nomodeset fastboot"

to make boot work again for my selfcompiled latest linus' git tree kernel, that as nearly no modules, i.e. everthing is compiled in.

Who's responsible of creating the /dev/root device?

I guess the boot command line parameter "root=xxx" seems to be directly involved in creation of /dev/root device?!

Closing as a dupe based on comment #14 from Sean (original reporter)

Thomas -- /dev/root is created based on root=, yes.

*** This bug has been marked as a duplicate of bug 296361 ***