Created attachment 3660 [details]
/var/log/dracut.log

/etc/fstab entries, as created by diskdrake
/dev/vg1/root / ext4 acl,relatime 1 1
# Entry for /dev/sda1 :
UUID=eb50363f-beb4-4504-9231-9ac52707fadf /boot ext4 acl,relatime 1 2
none /proc proc defaults 0 0
/dev/vg1/usr /usr ext4 acl,relatime 1 2
/dev/vg1/var /var ext4 acl,relatime 1 2

Just realized /usr is getting mount read only.

Is that intentional?

I believe it's intentional that /usr is mounted ro in the initrd. It will get remounted with the options in /etc/fstab when the system itself kicks in.


Also in the initrd, the var LV *should* be left inactive. It's not (usually) the initrd's job to bring up LVM or RAID etc. for anything other than / and /usr. It tries to do the least possible work and leaves the rest for the running system.
 An exception for this is the /var mount needed to do the /usrmove. It's possible that the configuration file used by mageia-prepare-upgrade to mount /var in the initrd was left over somehow (i.e. the magea-prepare-upgrade package was not removed before initrd generation time - quite feasible) but even then that's likely not the issue per-se. I'd say this bit (var not active) is actually OK and correct.

The missing symlinks on the other hand are certainly not intended. This is likely what causes the problem I suspect. As the initrd shouldn't be mounting /var (which you can confirm by typing "cat /etc/cmdline.d/*lvm*" in the shell to see what LV's it is specifically configured to start), I suspect adding the symlinks for just root and usr would allow the boot to continue and var will be activated and mounted by the system proper. Can you confirm this?


After getting a working boot, does backing up and regenerating the initrd produce a working setup again? If so can you give me an lsinitrd diff of the two initrds (preferably ignoring the dates on the files :))


A quite common cause for this is that the bootsplash stuff regenerates *all* initrds and ends up borking them as the system is in a half upgraded state. Even when the new kernel installs itself the system won't be fully ready. With urpmi, there is really no easy way to defer initrd creation until everything has been upgraded which is why I generally always regenerate the initrds at the end of the urpmi process before rebooting to ensure binaries from the latest packages are used. Personally I feel that regenerating the known-good initrds to add a new bootsplash is wrong also.


So we have a couple things to look at here:
 1. Find out why the symlinks are not being done properly (perhaps a missing udev rule).
 2. Find out if a simple regeneration of initrds is sufficient.
 3. Find out if a regeneration of initrds at the end of the urpmi process before reboot is sufficient to create a working boot (vb snapshots are awesome for this kind of debugging!!)

Many thanks :)

(In reply to Colin Guthrie from comment #3)
> I believe it's intentional that /usr is mounted ro in the initrd. It will
> get remounted with the options in /etc/fstab when the system itself kicks in.

Then there is some problem with the remount, as I had to manually
remount it rw.  (Found out it was ro, when I used rpm -e on a
package, only to have it removed from the rpm db, but all of the
/usr files left orphaned). 

> So we have a couple things to look at here:
>  1. Find out why the symlinks are not being done properly (perhaps a missing
> udev rule).
>  2. Find out if a simple regeneration of initrds is sufficient.

The initrd created after getting a working installation is actually
worse, as it failed to include lvm.

I made a mistake, and backed up the wrong initrd before running
dracut -f, so I no longer have the initrd created during the upgrade.

>  3. Find out if a regeneration of initrds at the end of the urpmi process
> before reboot is sufficient to create a working boot (vb snapshots are
> awesome for this kind of debugging!!)

As it failed from a working installation, I expect it would have
failed if rerun before the reboot too.

This was a test where I started with a Mageia 2 boot-nonfree.iso,
selected a custom install, and selected all package groups,
except individual package selection.

With over 2500 packages, the upgrade took around 3 hours.

I did create a snapshot before I started the upgrade.  Should have
created another one, before running the dracut -f.

Looking through the dracut.log, the first run for the 3.8 kernel
has ...
I: *** Including module: dm ***
I: Skipping udev rule: 64-device-mapper.rules
I: *** Including module: kernel-modules ***
I: *** Including module: lvm ***
I: Skipping udev rule: 64-device-mapper.rules

Why would it be skipping the device-mapper rules?

In the dracut run from a working booted system, it has
I: *** Including module: kernel-modules ***
I: *** Including module: resume ***

It completely skipped lvm.

I'll create a new minimal install just for sorting out this problem,
and will add more info later.

(In reply to Dave Hodgins from comment #4)
> (In reply to Colin Guthrie from comment #3)
> > I believe it's intentional that /usr is mounted ro in the initrd. It will
> > get remounted with the options in /etc/fstab when the system itself kicks in.
> 
> Then there is some problem with the remount, as I had to manually
> remount it rw.  (Found out it was ro, when I used rpm -e on a
> package, only to have it removed from the rpm db, but all of the
> /usr files left orphaned).

Ouch. rpm should really check this before running (I think it checks a ro / but I could be wrong).

I also stand corrected on the remount. It's only in the rootfs that gets remounted with current systemd. Not sure if newer systemd solves this differently. I guess I'll have to look at dracut for a solution to this for the time being.


> > So we have a couple things to look at here:
> >  1. Find out why the symlinks are not being done properly (perhaps a missing
> > udev rule).
> >  2. Find out if a simple regeneration of initrds is sufficient.
> 
> The initrd created after getting a working installation is actually
> worse, as it failed to include lvm.

Double ouch.

> I made a mistake, and backed up the wrong initrd before running
> dracut -f, so I no longer have the initrd created during the upgrade.

Darn, but....
 
> >  3. Find out if a regeneration of initrds at the end of the urpmi process
> > before reboot is sufficient to create a working boot (vb snapshots are
> > awesome for this kind of debugging!!)
> 
> As it failed from a working installation, I expect it would have
> failed if rerun before the reboot too.

... yeah, you're probably right, so no great loss with the above.

> This was a test where I started with a Mageia 2 boot-nonfree.iso,
> selected a custom install, and selected all package groups,
> except individual package selection.
> 
> With over 2500 packages, the upgrade took around 3 hours.
> 
> I did create a snapshot before I started the upgrade.  Should have
> created another one, before running the dracut -f.

If the VM disk is large enough, I usually do a urpmi --no-install to download all the files, then take a snapshot. Just makes the repeat testing that bit quicker (not lightning speed but I've replayed enough installs/upgrades now that I want every bit of speedup possible!).

I always take a snapshot again after all the urpmi processes are finished too but before any other post-upgrade reboots etc.

> Looking through the dracut.log, the first run for the 3.8 kernel
> has ...
> I: *** Including module: dm ***
> I: Skipping udev rule: 64-device-mapper.rules
> I: *** Including module: kernel-modules ***
> I: *** Including module: lvm ***
> I: Skipping udev rule: 64-device-mapper.rules
> 
> Why would it be skipping the device-mapper rules?

IIRC this is a SuSE specific rule that we don't ship.
 
> In the dracut run from a working booted system, it has
> I: *** Including module: kernel-modules ***
> I: *** Including module: resume ***
> 
> It completely skipped lvm.
> 
> I'll create a new minimal install just for sorting out this problem,
> and will add more info later.

Awesome. I suspect it must be a variation on a problem we've already had and should have been fixed already:

http://svnweb.mageia.org/packages?view=revision&revision=399625

But I guess something more is wrong here :s

This change might give you some hints as to how to debug dracut however if you'd be happy doing that?

As I mentioned on irc, create the directory and symlinks
/dev/vgname/root and var, fixes the boot issue, right
after update.

I don't see why the symlinks are not being created, as
/usr/lib/udev/rules.d/11-dm-lvm.rules
is present in the initrd.

I've added  systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M
to the boot options, but dmesg is not showing any debug info,
until after the root is mounted.

from dmesg ...
[    2.465853] dracut: inactive '/dev/vg1/root' [2.00 GiB] inherit
[    2.467250] dracut: inactive '/dev/vg1/var' [2.00 GiB] inherit
[    2.467628] dracut: inactive '/dev/vg1/usr' [9.00 GiB] inherit
[    2.546128] bio: create slab <bio-1> at 1
[   23.941830] dracut: Scanning devices sda6  for LVM logical volumes vg1/root vg1/usr
[   23.962354] dracut: ACTIVE '/dev/vg1/root' [2.00 GiB] inherit
[   23.966763] dracut: inactive '/dev/vg1/var' [2.00 GiB] inherit
[   23.967193] dracut: ACTIVE '/dev/vg1/usr' [9.00 GiB] inherit
[   23.970776] dracut: Partial mode. Incomplete logical volumes will be processed.
[   55.826430] dracut Warning: Could not boot.
[   55.832072] dracut Warning: "/dev/vg1/root" does not exist
[   55.833125] dracut Warning: "/dev/vg1/root" does not exist
[   55.833781] dracut Warning: "/dev/vg1/usr" does not exist

I presume you meant root and usr above :)

The systemd.* kernel command lines won't help much in dracut (at least for mga3 - for mga4 we'll likely start using systemd in the initrd too and make things nice and efficient and fast!).

There are however lots of debug options for dracut too in the form of the rd.* variables. See man dracut.cmdline for info, but IIRC rd.debug is sufficient here.

That said, it's likely udev who is responsible for creating the symlinks. I'm just wondering if some other package has been updated recently in this regard that somewhat interferes with the operation of things. e.g. perhaps it's not creating the symlinks until all volumes are ready...

Certainly it's worth running "udevadmin info /dev/dm-0" to ensure that all the relevant bits are set on it... e.g. DM_LV_NAME and DM_VG_NAME and anything else the udev rule needs to process when adding the symlinks.

Another test woudl be to run "udevadmin test --action=add sysfspath" where sysfspath is the path in sysfs... typically you can read this from "udevadm info dev/dm-0" it'll start /devices/...

This might help shed some light on it. In actual fact, just running udevadm test as above might actually *create* the symlinks for you (it's certainly not side effect free!). Either way it should definitely print out what it's doing along the way.

Hope that helps :)

From the udevadm info command right after the mount fails
E: DM_UDEV_DISABLE_DISK_RULES_FLAG=1

The rule has
ENV{DM_UDEV_DISABLE_DISK_RULES_FLAG}=="1", GOTO="dm_end"

I guess something changes that flag later.

https://forums.gentoo.org/viewtopic-t-926264-start-0.html

Not the first to encounter this problem.

Arggh.  Looking at the wrong rule.

13-dm-disk.rules has
ENV{DM_UDEV_DISABLE_DISK_RULES_FLAG}=="1", GOTO="dm_end"

11-dm-lvm.rules, which should create the symlinks has
ENV{DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG}=="1", GOTO="lvm_end"
which seems ok.  The full info for dm-0 is ...

P: /devices/virtual/block/dm-0
N: dm-0
S: mapper/vg1-root
E: DEVLINKS=/dev/mapper/vg1-root
E: DEVNAME=/dev/dm-0
E: DEVPATH=/devices/virtual/block/dm-0
E: DEVTYPE=disk
E: DM_MAJOR=252
E: DM_MINOR=0
E: DM_NAME=vg1-root
E: DM_OPEN=0
E: DM_READONLY=Writeable
E: DM_SUSPENDED=Active
E: DM_TABLES_LOADED=Live
E: DM_UDEV_DISABLE_DISK_RULES_FLAG=1
E: DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1
E: DM_UDEV_DISABLE_OTHER_RULES_FLAG=1
E: DM_UDEV_PRIMARY_SOURCE_FLAG=1
E: DM_UDEV_RULES_VSN=2
E: DM_UUID=LVM-ifpRQGV80IKIkci03NMEIPPgIRs2Ass283pU4jxSPeRBEHLXYLxDJeEPdhpfr8Pv
E: MAJOR=252
E: MINOR=0
E: SUBSYSTEM=block
E: USEC_INITIALIZED=1930745

(In reply to Dave Hodgins from comment #10)
> Arggh.  Looking at the wrong rule.
> 
> 13-dm-disk.rules has
> ENV{DM_UDEV_DISABLE_DISK_RULES_FLAG}=="1", GOTO="dm_end"
> 
> 11-dm-lvm.rules, which should create the symlinks has
> ENV{DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG}=="1", GOTO="lvm_end"
> which seems ok.  The full info for dm-0 is ...

Yup. :)

> P: /devices/virtual/block/dm-0
> N: dm-0
> S: mapper/vg1-root
> E: DEVLINKS=/dev/mapper/vg1-root
> E: DEVNAME=/dev/dm-0
> E: DEVPATH=/devices/virtual/block/dm-0
> E: DEVTYPE=disk
> E: DM_MAJOR=252
> E: DM_MINOR=0
> E: DM_NAME=vg1-root
> E: DM_OPEN=0
> E: DM_READONLY=Writeable
> E: DM_SUSPENDED=Active
> E: DM_TABLES_LOADED=Live
> E: DM_UDEV_DISABLE_DISK_RULES_FLAG=1
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This...

> E: DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1
> E: DM_UDEV_DISABLE_OTHER_RULES_FLAG=1
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ and this...

seem to be set at the end of the 11-dm-lvm.rules rule. This implies that either a GOTO="lvm_disable" has been processed or the rule:

# Create symlinks for top-level devices only.
ENV{DM_VG_NAME}=="?*", ENV{DM_LV_NAME}=="?*", SYMLINK+="$env{DM_VG_NAME}/$env{DM_LV_NAME}", GOTO="lvm_end"

Has not been processed and falls through to the next label which is the lvm_disable (and thus those properties are set).

In this case, it's actually quite clear that DM_VG_NAME and DM_LV_NAME are simply not set here and thus the symlink rule just doesn't work... The real question is.... why are these not set?


From what I can gather they *should* be set via this command:
# Use DM name and split it up into its VG/LV/layer constituents.
IMPORT{program}="/sbin/dmsetup splitname --nameprefixes --noheadings --rows $env{DM_NAME}"


So, could you run:
/sbin/dmsetup splitname --nameprefixes --noheadings --rows vg1-root

and post it's output?

DM_VG_NAME='vg1'
DM_LV_NAME='root'
DM_LV_LAYER=''

The rule in the initrd has
# Use DM name and split it up into its VG/LV/layer constituents.
IMPORT{program}="$env{DM_SBIN_PATH}/dmsetup splitname --nameprefixes --noheadings --rows $env{DM_NAME}"


Perhaps DM_SBIN_PATH isn't set.

So now it's looking like rerunning dracut, after lvm2 gets upgraded
may have fixed the issue after all.

I'll try and test that.

Running /bin/dracut -f /boot/initrd-3.8.3-desktop-2.mga3.img 3.8.3-desktop-2.mga3
after upgrading, before rebooting does fix the problem.

So dracut needs to be triggered by the updating of
/usr/lib/udev/rules.d/11-dm-lvm.rules

Once the system has been booted with the old version of the rule in
the initrd, DM_UDEV_DISABLE_DISK_RULES_FLAG=1 is set, preventing
future running of dracut from including lvm.

In addition, it also fixes the mounting of /usr as rw, instead of ro.

Yay! That's good :)

So it's the old LVM udev rules causing all the problems! Both initially and after a fixed-up-boot with initrd regeneration.


So, there are *lots* of things that should result in an initrd regeneration really, and this is just one example. Any library that's used, any binary that's used, any config that's changed etc. etc. should trigger this.

And even then it depends on your setup. e.g. if you upgrade cryptsetup then your initrd should be regenerated if your /, /usr or swap is encrypted, but if not then it won't matter.

Reliably solving this is a very tricky problem.

Really, we should probably have some kind of specific support in urpmi for this - i.e. doing something at the end of the whole session that warns the user (e.g. much like the "You should restart your computer for glibc/kernel etc" message works, but with an option to run the bootloader-utils regenerate-initrds option for you. Adding TV and Thomas to see if either of them have a nice way to implement this.



Another option would be to remove this line from dracut:

./modules.d/90lvm/module-setup.sh:        [[ "$DM_UDEV_DISABLE_DISK_RULES_FLAG" = "1" ]] && return 1


It won't solve the fundamental problem but it will make it easier to recover from it.

CC: (none) => thierry.vignaud, tmb

@Colin: this is not the same approch.
Such messages are handled by "should-restart = foobar" provides.
eg: glibc provides "should-restart = system"
When a package with such a provide got updated, we just call a callback with the message "you should restart %s for %s".

What you want is a filetrigger I think (/var/lib/rpm/filetriggers/)

@TV I don't think file triggers would do as they run on a transactional basis AFAIUI. What we want is something that runs right at the end of the urpmi process.

With the should-restart stuff, am I right in saying that it "remembers" the need to restart across urpmi runs? e.g. if I install a new glibc  in one urpmi session, does it remind me on the next one? I have it in my head it does.

Anyway, I think we need something that is separate from file triggers and is also just a suggestion.

Perhaps certain packages could (in a post or whatever) could touch /var/lib/initrd-needs-rebuild and urpmi could check for this file when it exits and present a similar warning to the "you should reboot" one, but also says how to regenerate your initrd? It's a bit hacky but it might also work OK for the most part.

Ping ? Guys can we solve that one or at least propose something to give a try?

CC: (none) => ennael1

As mentioned above the main problem is that we simply do not have any mechanism outside of the installer that allows for any tasks to be done at the end of the whole processes. In this case we need to regenerate initrds right at the end of the upgrade process before we reboot. I've always made a point of doing this personally with all my urpmi-based upgrades in the past but really it's down to users knowing they need to do this.

I say we either have to build something into urpmi that can somehow signify to the user that they need to regenerate their initrd and warn them at the end (much like how the "should-restart" stuff works from a high level) and/or offer to build the initrd's for them.

Such a system could be simply (much like the check it does at the end for orphaned packages. Each package that knows it is often part of an initrd could simply do a "touch /var/lib/dracut/needs-rebuild" or similar and urpmi could look for the existance of such a file show a "Packages which may affect your initramfs have been updated. Do you want to rebuild your initrds? [Y/n]" type warning.

Of course there is a bit of work to be done to support that and I doubt very much we'd be able to do that in time and have it tested appropriately.

That's just plain nonsense!
You're trying to over engineering sg very simple!

As you already know that old LVM rules are bogus with newer kernels (comment #15), just make the mga3 kernels conflicts with too old lvm2.
eg: Conflicts: lvm2 < 2.02.98-3.mga3

Source RPM: dracut-025-5.mga3.src.rpm => kernel

That's a bogus fix. It's just playing whack-a-mole with a specific case rather than putting in proper infrastructure to fix the problem properly. This comes up again and again, and even the security team folks have expressed concern that old initrds might contain daemons or libs with security bugs in them. But sure, if you want to solve this specific problem and ignore other issues with upgrades resulting from old initrds then fine.

I think for mga3 we will use the conflicts on too old lvm2 (I already committed it to svn) to cope with this issue as we are getting too close to release.

for mga4 it would be nice to have a "hook" to only rebuild initrd once after last transaction as we do have several packages that want to be in updated initrd.

as for the deabate about "old initrds with security bugs" I think we have to be careful to not rebuild all initrds as it can render a system unbootable if there is a bug in dracut or one of the files added to initrd during rebuild

(In reply to Colin Guthrie from comment #21)
> That's a bogus fix. It's just playing whack-a-mole with a specific case
> rather than putting in proper infrastructure to fix the problem properly.
> This comes up again and again, and even the security team folks have
> expressed concern that old initrds might contain daemons or libs with
> security bugs in them. But sure, if you want to solve this specific problem
> and ignore other issues with upgrades resulting from old initrds then fine.

Then then either add %posttrans to those packages in order to force a rebuild or just use a filetrigger that would cause initrd to be rebuild, which at least would reduce the amount of rebuilds.
There's no reason to hardcode sg specific to initrds in urpmi.
That's just not the right place.

And anyway, we would want such conflicts tags to ensure that lvm2/kernel/..; ends in the same transaction in order not to do too much initrds rebuilds, which are slow.

But you must also consider that blindly rebuilding all initrds, even for older kernels (as we've no way to figure which kernels' initrds should be rebuild) could break older initrds...
Think about:
- incompatible kernel/userland
- buggy new userland that would gratuitously break older initrds
 (just remember latest udev breakage)

IMHO magically rebuild won't solve everything and can break stuff.
It's always nice to keep older kernel+initds as they're, in order to have working fallbacks. And we can't tell which should be rebuild from which should not (cannot be the oldest one, think about having several flavors: linus/tmb/regular/server/...)

(In reply to Thierry Vignaud from comment #23)
> (In reply to Colin Guthrie from comment #21)
> > That's a bogus fix. It's just playing whack-a-mole with a specific case
> > rather than putting in proper infrastructure to fix the problem properly.
> > This comes up again and again, and even the security team folks have
> > expressed concern that old initrds might contain daemons or libs with
> > security bugs in them. But sure, if you want to solve this specific problem
> > and ignore other issues with upgrades resulting from old initrds then fine.
> 
> Then then either add %posttrans to those packages in order to force a
> rebuild or just use a filetrigger that would cause initrd to be rebuild,
> which at least would reduce the amount of rebuilds.
> There's no reason to hardcode sg specific to initrds in urpmi.
> That's just not the right place.

%posttrans would meant that the initrds are rebuilt several times during a urpmi based upgrade due to the fact that transactions are split (at least that's my understanding). I was also under the impression that file triggers happen at the same point in time as transactions, not at the end. Also it's going to be very trickly to install file triggers for each file rather than a package wide rule. It just seems the wrong place to manage this for me. Of course we could intragrate some kind of filetrigger generation into dracut itself such that a regexp matching any file it used last time, was installed with a script that ran the exact command. This would be an interesting idea but still suffers from the problem of keeping usable backups (tho' certainly no unsolvable!)

> And anyway, we would want such conflicts tags to ensure that lvm2/kernel/..;
> ends in the same transaction in order not to do too much initrds rebuilds,
> which are slow.

Yeah, this is why I would very much like a mechanism to only do the initrd rebuilds at the end of all upgrades. Or alternatively (being slightly more generic about it) only install the kernel package at the end of all upgrades (much like how some packages are prioritised at the start of the upgrades - glibc, rpm etc. - the kernel could be specially handled to make it come at the end of all upgrades. But to me this only handles the case where the krenel is included in an update and if udev or some other initrd component is upgraded we still need a mechanism to update the initrd if the user so desires (keeping in mind an appropriate backup solution as Thomas mentions such that we can still reuse an old initrd if everything goes wrong - not that some of the bootsplash scripts do this currently which is IMO bad practice!!!)
 
> But you must also consider that blindly rebuilding all initrds, even for
> older kernels (as we've no way to figure which kernels' initrds should be
> rebuild) could break older initrds...
> Think about:
> - incompatible kernel/userland
> - buggy new userland that would gratuitously break older initrds
>  (just remember latest udev breakage)

This happens currently when e.g. the theme is updated. This is bad IMO, but it's the way it's been for several releases. I'd rather prevent this happening automatically and give the user a nice choice instead at the end, not when the theme pkg is uploaded.
 
> IMHO magically rebuild won't solve everything and can break stuff.

I'm not asking for a magical rebuild (which happens currently), I'm suggesting we do soemthing to give the user a choice (which doesn't happen currently). I'm asking to help prevent this kind of error but also inform the user more robustly that this is needed.

> It's always nice to keep older kernel+initds as they're, in order to have
> working fallbacks. And we can't tell which should be rebuild from which
> should not (cannot be the oldest one, think about having several flavors:
> linus/tmb/regular/server/...)

I totally agree. This is sadly not what happens now. I'd much rather change things (e.g. the themes package) to not rebuild initrd's automatically and instead give the user the choice at the end of the whole urpmi process if they want to rebuild their initrd or not - perhaps offering choice to only update the newest/default kernel and not all old ones in order to have suitable backup.



FWIW, I've just installed a system with three separate LVM volume groups (only one logical volume in each). The layout is as follows:

 /boot = ext4
 / = LVM + Encrypted / ext4
 /usr = Encrypted LVM + /usr ext4
 /var = LVM 


This was installed in MGA 2. It didn't boot sadly due to the / layout (encryption on top of LVM). It worked when I tweaked the root= command line.

On urpmi upgrade the root= entry in menu.lst failed to work properly (I think due to a bug which is now fixed in drakx...) which resulted in a "root=/dev/" (where it should have been "root=/dev/mapper/luks-sdfslkfjaslkdfjlaskdjflkasdjf"). However after manually fixing that, it failed on reboot. Restoring my snapshot to before the reboot (I've been here before!), I was able to fix the root= and regenerate the initrd and it worked fine. So in terms of the "suggested soltuion" we should be OK generally with this upgrade - i.e. it technically works if the initrd is generated late. But the bug in properly propagating the root= argument does need to be resolved too and appropriate kernel conflicts added also.

/me made far too many word typos above - it's late and I'm "tired" ;) Hope the principal makes general sense.

Ultimately I agree that if the LVM conflicts on the kernel work for this case the it's the path of least resistance for mga3. I would very much like to have a proper mechanism in place for mga4 tho'.

In my current test (in progress), doesn't look like it's fixed.

    http://192.168.10.101/distrib/cauldron/x86_64/media/core/release/lvm2-2.02.98-3.mga3.x86_64.rpm
    http://192.168.10.101/distrib/cauldron/x86_64/media/core/release/lib64lvm2cmd2.02-2.02.98-3.mga3.x86_64.rpm
    http://192.168.10.101/distrib/cauldron/x86_64/media/core/release/kernel-desktop-3.8.8-1.mga3-1-1.mga3.x86_64.rpm
installing perl-SVG-2.530.0-2.mga3.noarch.rpm lib64cap-ng0-0.7.3-2.mga3.x86_64.rpm irqbalance-1.0.5-2.mga3.x86_64.rpm lvm2-2.02.98-3.mga3.x86_64.rpm perl-Parse-Yapp-1.50.0-3.mga3.noarch.rpm lib64numa1-2.0.8-3.mga3.x86_64.rpm lib64lvm2cmd2.02-2.02.98-3.mga3.x86_64.rpm kernel-desktop-3.8.8-1.mga3-1-1.mga3.x86_64.rpm perl-Date-Manip-6.370.0-3.mga3.noarch.rpm python-lxml-3.0.1-2.mga3.x86_64.rpm from /var/cache/urpmi/rpms
Preparing...                     #######################################################
1312/2592: kernel-desktop-3.8.8-1.mga3
                                 #######################################################
I: dracut module 'network' will not be installed, because it's in the list to be omitted!
I: dracut module 'network' will not be installed, because it's in the list to be omitted!
I: *** Including module: dash ***
I: *** Including module: i18n ***
I: *** Including module: drm ***
I: *** Including module: plymouth ***
I: *** Including module: dm ***
I: Skipping udev rule: 64-device-mapper.rules
I: *** Including module: kernel-modules ***
I: *** Including module: lvm ***
I: Skipping udev rule: 64-device-mapper.rules
I: *** Including module: resume ***
I: *** Including module: rootfs-block ***
I: *** Including module: terminfo ***
I: *** Including module: udev-rules ***
I: *** Including module: usrmount ***
I: *** Including module: base ***
I: *** Including module: fs-lib ***
I: *** Including module: shutdown ***
I: *** Including modules done ***
I: *** Installing kernel module dependencies and firmware ***
I: *** Installing kernel module dependencies and firmware done ***
I: *** Resolving executable dependencies ***
I: *** Resolving executable dependencies done***
I: *** Stripping files ***
I: *** Stripping files done ***
I: *** Creating image file ***
I: *** Creating image file done ***
I: Wrote /boot/initrd-3.8.8-desktop-1.mga3.img:
I: -rw------- 1 root root 8434647 Apr 18 19:03 /boot/initrd-3.8.8-desktop-1.mga3.img
F: initdir not set
1313/2592: lib64numa1            #######################################################
1314/2592: lib64lvm2cmd2.02      #######################################################
1315/2592: lib64cap-ng0          #######################################################
1316/2592: irqbalance            #######################################################
Migrating sysvinit service 'irqbalance' to systemd native unit 'irqbalance.service' via systemd install rules.
Failed to issue method call: File exists
1317/2592: lvm2                  #######################################################

So even though they are in the same transaction, the kernel is being
installed, and dracut run, before lvm2 gets installed.

Thomas, could you alter kernel %post script to be a %transpost script instead?
This would fix this.

Yep, I thought of it and had meant to do it on the last kernel, but forgot to really do it :/

now fixed in svn

Can we have a final status on this bug?

It should be addressed in latest kernel I believe. I'll do an upgrade test in a moment in my VM.

Confirmed fixed in my VM.

FS Layout:

/ is an ext4 encrypted partition on top of an LVM LV (only LV in VG)
/usr is an encrypted LVM LV with ext4 (only LV in VG)
/var is a LVM LV with ext4 (only LV in VG)

(so three separate LVM VGs with only on LV in each).

Everything worked correctly, the only issue was drakx killing the root= entries in my grub/menu.lst but this is a separate issue (and one that I think is actually fixed if the proper names are used - i.e. /etc/crypttab is fully populated which, on my test system, it is not).

I also ensured dbus was excluded form the updates as per bug #9534 which I should be able to fix with a rather hacky addition to mageia-prepare-upgrade. The only upgrade headache for me now is how to deal with mgaonline proposing updates without running mageia-prepare-upgrade... :s

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