[arch-dev-public] [signoff] mkinitcpio 0.5.25, cryptsetup 1.0.6-3

[Thomas Bächler]

Eric Bélanger schrieb:
> I'm experience a small problem (it might be due to the changes you made.).
> 
> On my i686 system with lvm, after the lvm group has been activated, I get a:
> "Waiting 10 seconds for device fe00" message. After the timeout, it says that
> "root device fe00 doesn't exits attempting to create it
> /bin/mknod /dev/root b 254 0"
> 
> The booting continues successfully and everything seems to be working
> fine except I've noticed that I have a /dev/root symlink that points
> to a non-existing fe00 device. I don't know if this is expected
> because of the new poll_device function or if there's another problem
> elsewhere. BTW, this system use lilo in case it's related.

Ah, I didn't count on lilo ... lilo parses the block device id when you 
run "lilo" and passes that as the root= argument (see /proc/cmdline). 
That used to be necessary ages ago and apparently, it is still supported 
by linux (and by klibc's parseblock tool).

However, it leads to problems with things like LVM, encryption and so 
on: The major/minor numbers at "lilo" time are not guaranteed to be the 
same on the next boot. The problem was already there before, you just 
didn't notice (as was the /dev/root symlink problem). Now we just wait 
until the device exists, which we cannot really check, as it is a real 
device. I have two solutions for you:

1) (which I gave to people for a long time now) in lilo.conf:

Remove
root=/dev/....
and add
append="root=/dev/..." (or addappend=, see the lilo manpage)

That will circumvent lilo's deprecated build-time root-device id parsing 
and simply pass the device to the kernel.

2) add rootdelay=0 as a parameter to your kernel commandline, that will 
stop us from waiting so long.

Note that we will move away from klibc to uclibc soon, and also drop the 
klibc parseblock and kinit tools - and I seriously doubt busybox's mount 
command parses "fe00" as a major/minor number pair. We might add such 
parsing for backwards compatibility, but personally, I think it's a 
waste of time.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://www.archlinux.org/pipermail/arch-dev-public/attachments/20090608/036a1e62/attachment.pgp>