[Mageia-dev] New dracut - please test

[Colin Guthrie]

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