Re: udevadm --settle
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. 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. > > 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. > > Now, that said, I'm probably a bit of a minority with so many > partitions on my disks and this surely has some weight, however,the > results are consistantly reproducable on my system. Why settle is not > doing what it is intended to do is beyond me. We are only discussing > a very small amount of time, a few ms at best here, so I see a couple > of options: > > 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 > script. I don't use either. I prefer a persistent /tmp, but that's just me. If I download a file, say a pdf, from the browser, it saves it to /tmp even though it goes directly to the pdf reader. I'd rather it takes up disk than ram and I prefer it to stay in /tmp until I specifically delete it. Yes, I modified cleanfs. > 2. Add a sleep to the end of the udev script (how long?). Two seconds has been reported as working. > 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. That seems like a reasonable approach, but it may not be enough depending on the size and number of the partitions and if they are clean or not. > 4. It is a local issue and my troubleshooting skills are not up to > par. ;-) I doubt it. udev is a bit troublesome. I suppose there could be a custom udev rule to automatically mount the swap partition when, say /dev/sda3, becomes available. That's probably not really satisfactory though. Another thought would be to do something like: while ! -b /dev/sda3; do sleep 1; done swapon -a The problem seems to be inherent with dynamic devices. If you try to do something before the driver tells udev it's there, the operation will fail. It's a race condition. I don't see a solid solution that will work in every case. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: udevadm --settle
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? 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? (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.) > 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. > 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 > script. 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. > 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. :-) > 4. It is a local issue and my troubleshooting skills are not up to > par. ;-) 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... :-( signature.asc Description: OpenPGP digital signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
udevadm --settle
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. 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. 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. Now, that said, I'm probably a bit of a minority with so many partitions on my disks and this surely has some weight, however,the results are consistantly reproducable on my system. Why settle is not doing what it is intended to do is beyond me. We are only discussing a very small amount of time, a few ms at best here, so I see a couple of options: 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 script. 2. Add a sleep to the end of the udev script (how long?). 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. 4. It is a local issue and my troubleshooting skills are not up to par. ;-) I'm fairly sure that I've proven #1, and disproven #4. Haven't tested 2 or 3 yetworking on that now. More later. -- DJ Additional note: Setclock failed to run the first time, but ran fine for the replay. This also did not happen for 165. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Using the LSB Bootscripts
On Tue, May 10, 2011 at 6:39 AM, Jeremy Huntwork wrote: > On 5/10/11 8:25 AM, DJ Lucas wrote: >> * Most important, pull as much as possible of the items below from >> LightCube OS's files to ease merging and keep the diffs to a minimum so >> that they are easily shared across distributions. >> * Move ifup and ifdown scripts to /sbin. >> * Move network service scripts to /lib/services (there was one >> minor objection here, should that be /lib/network-services or >> /lib/network? I don't really have any preference here, /lib/services is >> fine by me). >> * Move network configuration files to /etc/network. >> * Move network (hostname value) and clock config into >> /etc/default/rc.site (default to UTC?) >> * Use /etc/default for rc configuration files (remaining items in >> /etc/sysconfig currently). > > All fine from my perspective. :) > >> * Add initd-tools to book - This is required for the new scripts. >> Jeremy what is the status on this in LightCube OS? I remember a few >> months ago about you possibly taking over maintenance of them, adding a >> service binary/script and such? At last check, Dan did not have them in >> an RCS, which is not an issue for now, just curious about the future of >> the tools. The tarball and homepage are available in Dan's home >> directory on freedesktop.org if we need for the book. Dan? > > I never got around to adding these into a repository, but I could do so. > I'd be happy to maintain them. I'll need to schedule some time to get > the infrastructure together for them and then post links. I nominate you as the new maintainer. :) Since I don't roll my own anymore I don't actually use the programs, but DJ has used them and they worked for me at one point. I put the repo on freedesktop.org in git://anongit.freedesktop.org/~dbn/initd-tools. I updated the webpage with the relevant info, but it'll take a little longer for cgit to display the repo. http://people.freedesktop.org/~dbn/initd-tools/ Let me know if I can help. This was my first major C project, so you might find some ugly code in there. Good luck! -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
