RFE: remove from mkosi-initrd the udev rules copied from dracut

[aafeijoo-suse]

We should consider removing these 2 udev rules:

• 10-mkosi-initrd-dm.rules is no longer necessary since 10-dm-rules sets the db_persist option (https://gitlab.com/lvmteam/lvm2/-/commit/eb4f744820832aff3d6da1bba14f12e91a5b3535).

• Regarding 10-mkosi-initrd-md.rules, it does the same as 63-md-raid-arrays.rules (https://github.com/md-raid-utilities/mdadm/blob/main/udev-md-raid-arrays.rules), also included in the initrd, except setting db_persist. This option was set by @prajnoha in the dracut's matching 59-persistent-storage-md.rules with the addition of 69-dm-lvm-metad.rules (dracutdevs/dracut@b874d4b) to fix LVM on md activation (year 2013), but this rule is not added anymore (dracutdevs/dracut@50e7466) and it was also replaced by 69-dm-lvm.rules (https://gitlab.com/lvmteam/lvm2/-/commit/67722b312390cdab29c076c912e14bd739c5c0f6) and removed from lvm2 (https://gitlab.com/lvmteam/lvm2/-/commit/042fbd43d25f4cc69ceec1aea4d0658bec54b6e3).

I had not any problem booting LVM on top of RAID using initrds generated by mkosi without the 2nd udev rule, but maybe I'm missing a specific case.

@prajnoha, @teigland, could any of you confirm if it is still required to set db_persist for LVM on md devices? In that case, a PR can be submitted here https://github.com/md-raid-utilities/mdadm, so we can safely remove the 2nd rule.

[DaanDeMeyer]

10-mkosi-initrd-dm.rules is no longer necessary since 10-dm-rules sets the db_persist option (https://gitlab.com/lvmteam/lvm2/-/commit/eb4f744820832aff3d6da1bba14f12e91a5b3535).

So annoyingly enough, Ubuntu is rather behind on newer versions of lvm2, and even in Noble they only have 2.03, which does not have the upstreamed udev rules yet.

[aafeijoo-suse]

So annoyingly enough, Ubuntu is rather behind on newer versions of lvm2, and even in Noble they only have 2.03, which does not have the upstreamed udev rules yet.

Thanks, I didn't know that. At least now we have this issue open so we can track the status of these leftovers.

[prajnoha]

@prajnoha, @teigland, could any of you confirm if it is still required to set db_persist for LVM on md devices? In that case, a PR can be submitted here https://github.com/md-raid-utilities/mdadm, so we can safely remove the 2nd rule.

If there's an LV on top of an MD device, the dracut in initrd will activate both layers properly - there' s no problem with that.

The db_persist is needed only for tracking the activation state of LVM and MD devices over to rootfs. That is because of their multi-step activation scheme where we need to differentiate various "add" udev events properly and to do that, we need to persist certain records in udev db.

In case the db_persist was missing for MD devices, the udevadm trigger --action=add (that is also used for after-pivot-to-root-fs "coldplug" as part of systemd-udev-trigger.service) would not trigger the pvscan on such MD devices, which in turn would not activate any LVs on top of MDs during the coldplug. But in majority of situations, the whole stack with MD and LVM is activated in initrd already (if needed - if not, the stack is activated after pivot to root fs). So we don't need to care that much - it's already activated fully or not, the job is done.

The issues would be if we already activated the MD layer in initrd, not using the db_persist, and then trying to autoactivate the LVM layer after pivot to root fs. And it's just the --action=add that would not work, the --action=change still works even without the db_persist.

In my opinion, It's still good to have the db_persist in place for consistency and completeness to avoid future surprises like "why don't the udev trigger with ADD event work for the stack where we have LVM on top of an MD device?". These are exactly the details and little omissions that can cause hidden issues and which we can prevent. So in case we're using the same MD udev rules for both initrd and rootfs, we should add the db_persist to the MD udev rules, just like we did for LVM already.

[aafeijoo-suse]

Thank you very much for your feedback.

But in majority of situations, the whole stack with MD and LVM is activated in initrd already (if needed - if not, the stack is activated after pivot to root fs). So we don't need to care that much - it's already activated fully or not, the job is done.

That explains why I could not reproduce the issue.

[aafeijoo-suse]

md-raid-utilities/mdadm#143