[Mageia-dev] Issues with dracut

Fri Feb 3 17:00:47 CET 2012

'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/
+