'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 >> <mag...@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/