Bug 144753

Werner, I don't think this is a kernel issue. SUSE 10.0 works just fine with the same kernel.

Can you please at least give a reason when you assign a bug away? Thanks.

One more data point - /dev/sda2 _does_ show up, just only right after fsck has attempted to open it. Assigning back to basesystem/werner.

Why this is basesystem? Please tell me the name of the
maintainer of libata.

Because I think it's a basesystem bug? The device node does show up, it just appears that fsck check happens right before it's there.

Jens, do you know that there is no devs package anymore and
how large the basesystem is, don't you?
Wilde guess: udev problem, but this is a guess. I've no
idea when and what is loading the libata kernel module
and if the device nodes are static entries or rules of
the udev configurtation. Maybe this should also be done by
mkinitrd because of the kernel events for this disk
or any other boot script.  Beside this, if the kernel
does not trigger events for the devices, this would also
a bug but in this case this would be a kernel bug.

I thought that udev and such would fall under the base system umbrella. Dunno if this is a udev bug, or a bad interaction between udev and init scripts. You mention modules, but there are no modules involved, the driver and libata is statically builtin. The device entry does show up, as mentioned.

Which fsck? Called from where? /var/log/messages output?

Jens, tststs.

Hannes, fsck called from boot.localfs. fsck fails with stat() failing to stat /dev/sda2. If I put this in boot.localfs _right_ before fsck is run on non-root devices (/dev/sda2 is /home):

if [ ! -f /dev/sda2 ]; then
    mknod /dev/sda2
fi

I get an error from mknod saying the device exists and fsck works fine after that.  A sleep 1 would likely fix it too, haven't tried it though. So it looks like tight timing.

Let me know if you need more info!

In:
  /etc/init.d/boot.localfs
is:
  # Required-Start: boot.rootfsck

Does changing that to:
  # Required-Start: boot.udev
help?

Dunno if the depends get updated automatically. Just run:
  insserv
after that.

Seems so, at least the first boot worked fine. I tried perhaps 2-3 before that all failed. Let me try a few more just to be on the safe side.

Did 2 more, both worked great. Thanks Kay! Closing this one as fixed.

I'm afraid it happened again, now it seems to happen consistenly on every boot.

I get something similar with todays update to autobuild. Does commenting out the rule in /etc/udev/rules.d/85-mount-fstab.rules help?

Made the change, will try and reboot the laptop 10 times :-)

Seems to happen on every boot with that rule commented out, but I switched to beta2 meanwhile so that could mix things up. beta2 continues the boot when fsck errors on /dev/sda2 not being there which does help me, but I'm not sure it's a great idea :)

Kay, same thing happens on an install of SLES10 beta3 I just did. This one uses the megaraid kernel module, and it fails fsck of /dev/sda1 (the root fs) and thus boots with / RO and nothing works.

Any ideas? This really hinders testing of kernels, so I'd say it's quite important that we find a fix for this ASAP.

This is a kernel without any initramfs, right?

/dev/sda1 is the rootfs that the kernel itself has mounted, right?

fsck /dev/sda1 fails, cause it misses the device node or something else?

Yes on all three questions. mount/fsck complains about /dev/sda1 not being there. Which one depends on whether I touch'ed /fastboot or not.

Kay, do you have a quick work-around I can use until you get this fixed? I badly need to test stuff today, and so far I wasted half a day on this already...

BTW, I already tried the suggestions listed here for 10.1, none of them work for me (add boot.udev as required start for boot.rootfs and commenting out that line in /etc/udev/rules.d/85-mount-fstab.rules).

Jens, this is fixed, right?

Yes, I think so! Feel free to close it.

Closing.