[Mageia-dev] New dracut - please test

Mon Feb 27 13:26:37 CET 2012

'Twas brillig, and Colin Guthrie at 25/02/12 10:59 did gyre and gimble:
+> 'Twas brillig, and David W. Hodgins at 25/02/12 07:35 did gyre and gimble:
+>> On Fri, 24 Feb 2012 06:42:01 -0500, Colin Guthrie
+>> <mageia at colin.guthr.ie> wrote:
+>>
+>>> The other big change here is to automatically generate a much bigger
+>>> initramfs when doing an upgrade from mga1. This will include a lot more
+>>> stuff (e.g. lvm, raid etc) that may or may not be needed on a given
+>>> setup, but until you boot with dracut you cannot generate an initramfs
+>>> that will be able to detect only what is needed for boot.
+>>
+>> Looking at the current version of the init script, it's clear
+>> what the problem is ...
+>>
+>>     check_finished && break
+>>
+>>     udevsettle
+>>
+>>     check_finished && break
+>>
+>> The above statement will always be true on a single core
+>> system, so the following code never gets executed.
+> 
+> As I've said before, I really do not think this is anything to do with
+> number of cores. I do see that there is a chicken and egg problem, but
+> why would the number of cores affect this? Nothing runs in the
+> background here.
+> 
+> As stated earlier
+> (https://www.mageia.org/pipermail/mageia-dev/2012-February/011709.html),
+> the problem is simply that there are no calls to wait_for_dev for the
+> lvm drives and thus the whole initqueue stuff just glosses over things
+> and doesn't ever activate them.
+> 
+> What is different to the last time is that now for hostonly initrds (not
+> the one you generated), the wait_for_dev call WILL be added. I had hoped
+> this different approach would have fixed your problem.
+> 
+> However, due to me now doing this fallback non-hostonly initrd, the
+> original problem still manifests itself.
+> 
+> Can you test that generating a new initrd after booting via dracut (and
+> thus getting a hostonly one) does actually activate your usr partition?
+> I'm not 100% convinced there will not still be a problem with the
+> "resume" support and swap partitions, but it will hopefully give you a
+> smooth boot even if resume support is busted.
+> 
+> The non-hostonly problem does need a fix and I'll see what can be done.
+
+Just for reference, here is my conversation with Harald Hoyer (dracut
+upstream guy):
+
+Me: haraldh, I've got a problem case with lvm again :)
+Me: haraldh, It was the same problem I had before, but it was solved in
+latest dracut with the specific cmdline files and specifically waiting
+for the known needed lvms.
+Me: haraldh, but sadly when building a non-hostonly initrd, no
+wait_for_dev calls are put in for the lvms and it can lead to problems
+when /usr is on lvm as the initqueue exits and no wait_for_dev for the
+/usr partition is ever issues and it cannot be mounted.
+Harald: coling, ah, yes... we have to redesign dracut there and put the
+mount hook in the main loop
+
+He did have a work around suggestion too tho', which I'll have to think
+about and code for, but on the surface it could provide a good stop gap
+without too much re-engineering.
+
+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/
+