dj at linuxfromscratch.org
Wed May 11 23:46:38 PDT 2011
On 05/11/2011 11:14 PM, Bryan Kadzban wrote:
> DJ Lucas wrote:
>> After updating from udev-165 to udev-168, I ran into a timing issue
>> with settle using tmpfs for /dev. My swap partition failed to mount
>> because the device node was not present. No other changes than those
>> made to the bootscripts and FS layout to account for /run.
> Ah. /run.
> Does settle not work with the new location of the udev database?
>> I rebooted a few more times to see that the problem was consistent.
>> One other variable is that I'm using new bootscripts (which _should_
>> provide a very minimal speed increase), but order is the same as
>> stock LFS.
> Is it easy to swap them out for the standard scripts?
Easy enough to do for troubleshooting purposes....delete rc.d symlink,
install regular bootscripts, correct setclock path in 55-lfs.rules,
modify inittab path to rc, but it'll have to wait till the weekend.
> What happens if you boot with init=/bin/bash, then manually run scripts
> one at a time, until you get to udev, then both (a) run it, and (b) list
> out /dev/sd*, in the same shell command? What happens if you do (a) and
> (b), then (c) rerun udevadm settle, then list again? (All in the same
> command again.)
> Where is your swap?
/dev/sda3...which gives a much better explanation as to why it works
with devtmpfs. I did not buy the "faster" bit.
> (I'm thinking the kernel isn't sending the event to udev in time after
> the trigger. There's no way settle can wait for an event that udevd
> doesn't know about yet.)
I think you hit the nail on the head there. Have to get logging going to
same files on a tmpfs to be sure. We are likely talking about a very
small timing issue. I think, at least in my case, a couple hundredth
seconds sleep would suffice after trigger...wonder what would be worst
case scenario on say i586. A tenth second? If the event is in queue, I
suspect settle will work as expected. Alternately, the man page isn't
real clear about --seq-end, will settle sit there and spin until that
event number is reached or timeout is reached, or will it check the
empty queue and continue? If the former, set the value to around 200 and
give a really low timeout, say 1 second.
>> Following a hint I found on a Debian mailing list claiming that
>> devtmpfs was faster, I enabled devtmpfs, commented out the /dev mount
>> in the udev script, and sure enough, the problem resolved itself.
> Even if you use a symlink to the swap partition? (Say, something in
> /dev/disk/by-uuid.) I'd be extremely surprised.
> The kernel will put raw sd* device nodes into devtmpfs for you, but
> using anything more stable in userspace will still have problems if
> udevadm settle is broken somehow.
As above, that's why the devtmpfs works.
>> 1. The obvious one (at least to me) is to force the use of devtmpfs
>> as upstream has intended, and remove the /dev mount from the udev
> Still breaks if you want to use stable names, I believe.
>> 2. Add a sleep to the end of the udev script (how long?).
> Not that I like this, but this is what the livecd did. It added a
> rootdelay=xx, to stuff an extra "sleep xx" in the initramfs.
Can do a really low value, .1?
>> 3. Changing bootscript order to put checkfs before swap should give
>> enough time for udev to get the coldplug events handled and written
>> to the tempfs.
> Except then one of the targets for checkfs will be missing. :-)
Yep. Bad idea.
>> 4. It is a local issue and my troubleshooting skills are not up to
>> par. ;-)
Incorrect path for setclock script in 55-lfs.rules - not related and
works fine BTW.
> 5. (I really really hate this one...) Bite the bullet and set up a
> fully dynamic set of bootscripts, interfacing with udev directly.
> (Because black magic, a la upstart or systemd, is *obviously* the right
> way to go. Sigh.) So mounting a given filesystem will only happen
> after the proper device node shows up (and will depend on udev, which
> will depend on kernel FSes), and then anything that requires that FS
> will depend on the mounting script.
> It's a *LOT* of work though, for what I thought was very little gain.
> However, if upstream has broken settle, we may not have much of a
> choice... :-(
No, settle is supposed to work for normal sysv setups. Something must
have been broken in new trigger.
-- DJ Lucas
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
More information about the lfs-dev