[Mageia-dev] System doen't boot with LVM

Colin Guthrie mageia at colin.guthr.ie
Mon Feb 18 16:15:56 CET 2013


'Twas brillig, and Olivier Thauvin at 18/02/13 14:55 did gyre and gimble:
> * Colin Guthrie (mageia at colin.guthr.ie) wrote:
>> 'Twas brillig, and Olivier Thauvin at 18/02/13 12:48 did gyre and gimble:
>>> So ok, I just update my freshly installed mga2 to cauldron using network
>>> install (live upgrade don't work, it seems urpmi fail to find a way to
>>> update the system w/o filesystem).
>>>
>>> I have the exact same result: it don't boot.
>>
>> Hmm, re: live upgrade are you meaning just a urpmi based upgrade? If so,
>> I've done a few similar updates in the last week or so in VMs and it's
>> always been OK. I presume you installed the mageia-prepare-upgrade
>> package from mga2/core/updates_testing, rebooted to the boot menu entry
>> created by that package before upgrading?
> 
> Ha, no, I followed the howto on the wiki:
> https://wiki.mageia.org/en/Feature:UsrMove
> 
> and there is no reference to this package on the page :\

Yeah, I noticed that too this morning :s I'll update it (I could have
sworn I had already, but.... I guess not - it was posted about quite a
lot on the list but that's fairly transient and no excuse for my general
failure to update the wiki!).

The mageia-prepare-upgrade package is just a nice wrapper around those
commands anyway, so you should be 99% OK with those commands all the
same (although they certainly are more complicated than they now need to
be - they were originally written for cauldron users during the
transition process rather than a clean mga2->mga3, so this explains
where there are urpmi commands with skip etc. in them. I think the time
is such that I can remove some of that detail from the page - the number
of cauldron users running pre-usrmove must be ~= 0 by now :)

>> Regarding the network install based upgrade there may be issues relating
>> to bootloader config tools (in drakx) that related the use of the blkid
>> cache which might make it miss the whole LVM volume (I've seen it
>> manifest itself as putting "root=/dev/" into grubs menu.lst rather than
>> "root=/dev/mapper/foo").
> 
> The entry in grub is fine (just checked it).

Good :)

>>>> In the dracut shell, what does /etc/cmdline.d/lvm.conf say? It should
>>>> contain enough info to brink up both the root and the swap lvm.
>>>
>>> rd.lvm.lv=sagittarius/swap
>>
> 
>> The problem is that dracut itself is not detecting that the LV needs
>> activating when it runs.
>>
>>
>> In order to get a booting system, just pass "rd.lvm.lv=sagitarius/slash"
>> on the command line (obviously substituting the real name of your
>> logical volume). This should make dracut initialise the lvm automatically.
> 
> This method did work and I am now under linux.

Yay! Lucky that the 51-mageia-resume.conf file caused the lvm module to
be included in the first place otherwise the initrd wouldn't have the
lvm command in it at all :D

> What can I do to understand why dracut did not detect the lvm to
> activate properly (and hopefully fix this definitivelly) ?

Basically, the best bet is to run something like the following (as root):

dracut -f foo.img
mkdir foo
cd foo
zcat ../foo.img | cpio -id
cat etc/cmdline.d/lvm.conf

This should test whether your / lvm has been detected in addition to the
swap one.

I sort of hope that this fails, otherwise the problem will be harder to
nail down!!

If it does fail then ultimately the problem will be in:
/usr/lib/dracut/modules.d/90lvm/module-setup.sh (or one of the utility
functions it uses). It should use "udevadm info" to query the system
about LVM info. You can add debug to the check_lvm function and then
re-run dracut -f foo.img again to see where it bails out.


If, however, it works fine on your running system then perhaps the
problem is with the installer lacking some udev rules to properly
capture all the needed metadata in udev database. This will require a
bit more fiddling (i.e. running udevadm info in the installer to look at
the properties it exports about the devices).

>> You should (at least in theory) also just be able to type something like
>> "lvm vgchange -ay" into the dracut shell, then type exit (perhaps twice)
>> to continue the boot process.
> 
> This has work except I was unable to enter my passphrase to read my
> encrypted /home.

Ahh yes, the "lvm vgchange -ay" is a bit of a "enable everything"
command (normally the initrd only initialises what it absolutely must -
e.g. /, /usr and swap for resume= support). I guess it might mess up the
passphrase stuff later on as a knock on effect, but really /home (and
any passphrase needed for it) should be the domain of the booted system
rather than the initrd (in theory!)

> But it's good to know this is posible.

Yeah. the lvm command is only included if dracut detects lvm as being
needed. In your current example it was somewhat fortunate that your swap
was on LVM and the 51-mageia-resume.conf file detailed that. This
51-mageia-resume.conf is a bit of a hack really... I should likely find
a nicer way to do it without hard-coded configs :)

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/


More information about the Mageia-dev mailing list