Matthew Burgess wrote:
> On 15/09/2011 20:38, Bruce Dubbs wrote:
>
> <snip nice description of the issue>
>
>> There are options about what to do right now:
>>
>> 1. Leave in the warning message and optionally write something about it
>> in the book.
>
> We try, generally, to accomodate changes in upstream programs. I'll
> defer to upstream's views on the fact that blindly retrying failed
> actions in the hope that the system is now somehow in a state that will
> enable them to run is not a particularly 'clever' option. What's the
> point in retrying them if we can't guarantee that they'll work this time
> around?
>
> So, I think we should do something to remove the warning, and therefore
> not have to explain it in the book...
>
>> 2. Add 2>/dev/null to the udevadm command above.
>
> ...well, I guess that counts as something :) I'd rather not hide the
> error. As you say below, when the --type=failed option is removed, this
> will just come back and bite us anyway.
>
>> 3. Modify the source to remove the warning (delete 1 line).
>>
>> When the --type=failed option is removed, we need to consider some other
>> options:
>
> Same as 2. This is just putting our hands over our eyes and pretending
> the problem's gone away :)
The above options were only intended for udev-173. Removing the
warning would only be a solution while --type=failed still exists. The
options below are intended for the situation after the option is removed.
Removing the error message in this case only removes an ugly warning
that we already know about.
These options are intended after --type=failed support has been removed.
>> 2. Declare that separate /usr and /var partitions are not supported.
>> They could be supported with an initrd that mounts the partitions before
>> the kernel starts, but that would need to be in a hint like the one
>> Bryan wrote in 2005.
>
> I'm 50/50 on this one. It does have the benefits of being a) simple and
> b) toeing the upstream line. It does though, obviously mean we drop
> support for a configuration that we've long supported.
>
>> 3. Declare that we do not support hwclock settings that are not GMT.
>
> Well, you'd be insane not to set it to GMT anyway, right? :) Again,
> whilst I think this simplifies things, it does mean we'd drop support
> for a configuration we've supported in the past.
Well, I certainly use GMT, but the issue is dropping support for some
users and I don't like that.
>> 4. Reinsert the deleted retry code into udev with a patch.
>
> Where was the smiley on the end of that one, Bruce? :) I really
> wouldn't want us to do this.
How do you do a half-smiley. I think I could do this, but I don't
really think it would be appropriate for LFS.
>> 5. Since (I think) udev commands are run asynchronously, change the
>> affected scripts (e.g. setclock) to wait in a loop for the appropriate
>> partitions to be mounted. For example:
>>
>> for i in {1..10}; do
>> if [ -d /usr/share ]&& [ -d /var/lib ]; then break; fi
>> sleep 1
>> done
>>
>> if [ $i -eq 10 ]; then error(); fi
>> ...
>
> Now, if it's true that udev actions are in fact asynchronous, this is
> probably the most pragmatic of solutions. It's not clever, but then it
> doesn't really have to be. It could even be factored out into a
> function, such that bootscripts could just call something like
> "wait_for_path('/usr/share')"
I'll note that on my system, setclock runs almost immediately after udev
starts, but udev takes a while to finish:
Sep 15 15:29:17 -05:00 (none) Populating /dev with device nodes...
Sep 15 15:29:17 -05:00 (none) Setting system clock... OK
OK
Sep 15 15:29:23 -05:00 (none) Mounting root file system in read-only
mode... OK
Sep 15 15:29:24 -05:00 (none) Remounting root file system in read-write
mode... OK
Sep 15 15:29:24 -05:00 (none) Recording existing mounts in /etc/mtab... OK
Sep 15 15:29:24 -05:00 (none) Mounting remaining file systems... OK
So that's 7 seconds for udev. Other systems may take longer.
Also note that the two OK's in a row are for udev and setclock. I don't
know for sure which OK comes first, but I suspect setclock because I
don't have a separate /usr or /var partition.
>> 6. ???
>
> Use a combination of systemd + initrd :-)
I'm glad you used a smiley there.
> So, based on the above, 5 is definitely something to look into I think.
> If that doesn't pan out, then I think option 2 is the next 'least worst'.
I agree.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
