Bug 10088

Created attachment 3972 [details]
dracut.log

fyi, /, and /usr were activated. Just /var wasn't.

Increasing the priority and severity, as this is blocking a kernel security update.

Priority: Normal => High
Severity: normal => critical

If you backup the initrd, and recreate it, does it differ from the backup ? does it boot properly then ?

By default, dracut will not activate /var.

This sounds like some kind of interference from mageia-prepare-upgrade package which generates config to make make dracut mount /var (for usrmove). Are you sure you do not have this package installed also which is somehow interfering? 

The config file will be: /etc/dracut.conf.d/53-mageia-prepare-upgrade-var.conf which is generated via /usr/sbin/mageia-prepare-upgrade-dracut-detect-var script.

Yes mageia-prepare-upgrade was installed. (I'd messed up deleting
instead of restoring a snapshot).  Recreating a good test env now,
and will retest the kernel update as soon as that's ready.

Removing the block on the kernel update.

Without the mageia-prepare-upgrade installed, it works fine.

Colin, do you want this bug closed as invalid, or keep it open
for now?  Once mageia-prepare-upgrade is pushed, anyone who
installs it, but then installs a kernel update before upgrading,
and has /var on a lvm logical volume, will run into this
problem.

Can it be fixed, or is it too much trouble, considering how
unlikely it is to happen?

Blocks: 9953 => (none)

Wellllllll, I've personally tested this code on various exotic /var mounts, including one on LVM (a separate LVM with only one vg to make sure the vg get's activated) and it worked fine, so I'm not 100% sure why it would fail in your test system.

If you could test the latest mageia-prepare-update and regenerating dracut initrds that would be great. If it fails we can then work out why (basically should just be a matter of checking the /etc/cmdline.d/ files in the initrd to make sure the vg and lv are both mentioned and what the /etc/fstab actually looks like.

This message is a reminder that Mageia 2 is nearing its end of life.
Approximately one month from now Mageia will stop maintaining and issuing updates for Mageia 2. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '2'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 2's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 2 is end of life.  If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete.

-- 
The Mageia Bugsquad

Mageia 2 changed to end-of-life (EOL) status on ''22 November''. Mageia 2 is no
longer maintained, which means that it will not receive any further security or
bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of Mageia
please feel free to click on "Version" change it against that version of Mageia
and reopen this bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

--
The Mageia Bugsquad

Status: NEW => RESOLVED
Resolution: (none) => OLD