[Mageia-dev] Issues with dracut

[Colin Guthrie]

'Twas brillig, and David W. Hodgins at 03/02/12 08:04 did gyre and gimble:
> On Tue, 17 Jan 2012 07:22:30 -0500, Colin Guthrie
> <mageia at colin.guthr.ie> wrote:
> 
>> Are things working OK for you now with dracut or is it still busted?
> 
> Just to clarify why I think the problem is happening on single
> core systems.
> 
> On a multi-core system, the bash and udevd processes will be
> running on different cores.
> When the script executes the udev settle command, it continues
> to execute, so the loop checking to see if udev is done finds
> it isn't, so it then looks for/runs the initqueue jobs.
> 
> On a single core system, the bash script waits for the settle
> command to finish, so then finds it's done, and exits without
> even trying to run the initqueue jobs.
> 
> The patch in my prior message is effectively changing the script
> from "udev done or jobs done" to "udev done and jobs done".

Hmm, actually thinking about this more, I'm not 100% sure I agree with
this argument. The number of cores should be irrelevant here as the
program itself should be dealing with things synchronously anyway.

I'm wondering if it's more of an issue relating to the fact that it's
not specifically waiting for the LVM device to be ready. I guess your /
is either not on LVM or is in a different Volume Group? In my tests it
worked, but perhaps the dual core machine is simply that bit faster (and
it's speed, not #cores that is important)?

In the file parse-lvm.sh, it does a for loop and has a wait_for_dev
call. This function will put stuff into the initqueue that should
prevent the exiting of the loop until that device exists...

    for dev in $(getargs rd.lvm.vg rd_LVM_VG=) $(getargs rd.lvm.lv
rd_LVM_LV=); do
        wait_for_dev "/dev/$dev"
    done

Now according to the man page, these options are only meant to be used
to restrict what devices are activated so they shouldn't be needed per-se.

But it brings an important point... there does not appear to be any
"wait_for_dev" calls for the usrmount module  So nothing is going to be
waiting for the device to exist. If it takes a little while to come up
it could lead to your error.

And herein we have chicken and egg... we don't know where /usr is (i.e.
which /dev/foo) until we mount /  (as we have to read /etc/fstab). But
by the time we've mounted /, we've already exited this loop and thus
cannot re-enter the loop to wait for more devices.

Tricky, and certainly something I'll discuss with Harald this weekend.
He does have a separate branch that deals with usr mounting in a more
holistic way (i.e. it handles /usr/bin being a separate mount if that
floats your boat!), but I've not looked at this for a while to see if
he's progressed any with it.

All in all, it's perhaps just the fact that the first call to udevadm
settle is skipped due to there being nothing in your initqueue/finished/
folder? You can check via passing rd.break=initqueue and looking in the
folder.

If so, then all that should be needed to get this into shape is to put a
dummy file in there as part of the 98usrmount module, have that file
delete itself and return and error code, thus causing check_finished()
to return non zero and thus the call to udevsettle will be reached.


If this is NOT the issue, then it should just be a timing thing plain
and simple. To confirm, this you should simply be able to pass
rd.break=pre-pivot to the command line, wait a little while and then
just type exit to continue the boot process. This extra time should be
sufficient for udev to "see" the LVM stuff and for the mount command to
succeed (I hope!)

Sorry for the long reply. You will likely have to poke in the dracut
code to understand everything I'm saying, but it looks like you're doing
that happily already :D

Col



-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/