Re: [RFC PATCH 7/7] 10-dm.rules: bump DM_UDEV_RULES_VSN to 3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 3/4/24 17:46, Martin Wilck wrote:
> On Mon, 2024-03-04 at 12:09 +0100, Peter Rajnoha wrote:
>> One thing that comes to my mind here is cooperation between the rules
>> from initrd/initramfs and rootfs - the initrd/initramfs can have
>> different versions of the rules installed.
> 
> Yes, that's a source of pain. Are there current initramfs tools that
> user DM_UDEV_RULES_VSN!=2? I think "2" should be the standard today,
> given that it has existed since 2009. dracut just installs the upstream
> rules it finds, at least for dm, AFAICT.
> 
> I've reviewed other rule sets I'm aware of, and the only one in which I
> needed to check DM_UDEV_RULES_VSN was 11-dm-mpath.rules. I didn't have
> a close look at the rule sets that dracut ships yet, let alone other
> tools for initramfs maintenance.
> 
> Regardless, my patch set changes the availability and semantics of the 
> device-mapper udev properties, and thus we should bump the version, no?

Sure, that is expected if we do such changes to rules.

I just meant to be cautious about a situation where we have initramfs
running a different version of rules, then keeping the udev database
over the pivot-to-rootfs (which happens with dracut, not sure about
others). Then, on coldplug running from rootfs, refreshing the state
with the other version of rules.

Important here is that the rules running from rootfs do not get mislead
with the state that was taken over from the initrams.

-- 
Peter





[Index of Archives]     [Gluster Users]     [Kernel Development]     [Linux Clusters]     [Device Mapper]     [Security]     [Bugtraq]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux