> > > > But in groovy+, the udev rule from multipath-tools that has > > > > always attempted to remove the devices nodes for the partitions > > > > of a disk that is a multipath member actually succeeds, and > > > > > > Won't this break curtin on older multipaths that don't have this rule? > > > > No, if the device node for a partition of a disk that is a multipath member > is still present, this branch ignores it (or at least that's the intent...) > > > > > Or will this work with older multipath output since we're only referring > to > > > the mpath dev (rather than a path of the mpath device)? > > > > Er, I think so. Not completely sure about the distinction you're making > here. > > In the description, in groovy+ we will no longer have the partitions on the > path members IIUC. For example (say a 2 path disk with 1 partition) we'd see: > > /dev/sda > /dev/sda1 > /dev/sdb > /dev/sdb1 > /dev/dm-0 (mpatha) > /dev/dm-1 (mpatha-part1) > > And on Groovy+ we see: > > /dev/sda > /dev/sdb > /dev/dm-0 (mpatha) > /dev/dm-1 (mpatha-part1) > > Is that correct?
Yes. > My concern was if the single-path partitions are present (as they are on > Focal and older) does the new code still handle things OK? Oh I see, you're worried about the downstream impact of this: whether the storage configs produced by curtin after this change can actually be installed. That's a good question! > I *think* it's yes due to the fact that curtin knows how to create partitions > on MP devices since 20.04. I think you're probably right but I should also do some testing of this situation. > I've added some replies in-line, awkwardly, you have to select your previous > commit to see those. Replied. -- https://code.launchpad.net/~mwhudson/curtin/+git/curtin/+merge/392353 Your team curtin developers is subscribed to branch curtin:master. -- Mailing list: https://launchpad.net/~curtin-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~curtin-dev More help : https://help.launchpad.net/ListHelp
