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 :)

> 1.  Delete the affected udev rules that run the problem commands (in
> udev/rules.d/55-lfs.rules) and run them explicitly when we want them to
> run.  This could create a potential, but unlikely, race condition.

I'm not particularly enamored by this one.  The rules are in there for a 
reason, and in particular, if we get rid of the snd* devices action, 
that will stop folks from being able to plug and play sound devices in 
particular.

> 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.

> 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.

> 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')"

> 6.  ???

Use a combination of systemd + initrd :-)

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'.

Thanks,

Matt.
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Reply via email to