On Thu, Sep 15, 2011 at 2:49 PM, Bruce Dubbs <bruce.du...@gmail.com> wrote:
> 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
Another thought (one I have not actually tested, forgive me if It's
not possible) is trigger only block devices in the first pass, then
try devices/subsystems on the 2nd pass?
It looks like udevadm trigger could match "specific" devices, what
about something like
udevadm trigger --type=devices --subsystem-match block
udevadm trigger --type=subsystems --subsystem-match block
mountfs
udevadm trigger --type=devices
udevadm trigger --type=subsystems
--
Nathan Coulson (conathan)
------
Location: British Columbia, Canada
Timezone: PST (-8)
Webpage: http://www.nathancoulson.com
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
