OK,
At this point I'm about to go on break, so I'm not confidident pulling the code into trunk rigth now, but I believe the branch at lp:~smoser/curtin/trunk.lp1523779 represents fixed curtin for this issue.
There are still basically 2 MAAS issues that will block this though:
a.) maas will need to not send entries for both backing disks of a multipath disk. (bug 1526542).
b.) maas will need to learn that power systems need a PrEP partition and also that they should use GPT.
Curtin does still have a bug if using MBR and storage config, that it will not understand or act 'flag: prep' in msdos mode.
any powerNV system likely needs both 'a' and 'b' (as I believe they have multipath almost by default).
a KVM guest (powerKVM or kvm on ubuntu) or a powerVM is not likely to see mutipath, so 'b' is probably only necessary.
I believe that powerVM is what Newell was testing with.
OK,
At this point I'm about to go on break, so I'm not confidident pulling the code into trunk rigth now, but I believe the branch at
lp:~smoser/curtin/trunk.lp1523779 represents fixed curtin for this issue.
There are still basically 2 MAAS issues that will block this though:
a.) maas will need to not send entries for both backing disks of a multipath disk. (bug 1526542).
b.) maas will need to learn that power systems need a PrEP partition and also that they should use GPT.
Curtin does still have a bug if using MBR and storage config, that it will not understand or act 'flag: prep' in msdos mode.
any powerNV system likely needs both 'a' and 'b' (as I believe they have multipath almost by default).
a KVM guest (powerKVM or kvm on ubuntu) or a powerVM is not likely to see mutipath, so 'b' is probably only necessary.
I believe that powerVM is what Newell was testing with.