Cfxtrjtrk

I'm upgrading a current 16.04 server to 18.04. The / and /boot partitions are mirrored (simple mdadm). To avoid the risk of a failed installation, I broke (--fail then --remove) the mirror and am trying to install 18.04.1 onto the partitions I removed from the mirror.

Related: Ubuntu server install on existing partition, Ubuntu specifically disallows the ability to use pre-existing partitions (used to work years back), not sure why this feature was intentionally removed but it seems to make it harder to do upgrades.

To work around that problem, I removed the existing partitions for / and /boot, hoping to use the installer's "create software RAID (md)". However, the desired drive (it is the only drive with unpartitioned space available) is not listed on the "RAID" ascii pop-up, and a red label at the bottom states that it requires at least 2 active devices.

Perhaps I'm missing something, but it is perfectly legal to create a raid1 mirror array with a single partition and missing, suggesting a place-holder for a future device.

mdadm --create /dev/md/0 --level=1 --raid-devices=2 /dev/sdh1 missing

mdadm --create /dev/md/2 --level=1 --raid-devices=2 /dev/sdh3 missing

My intention is to bring up this newer 18.04 and, once I have successfully brought it up-to-speed and proved to myself that all will work, only then will I add the other drive's raid1-partitions and rebuild the mirrors (over-writing the 16.04 installation).

Perhaps the only way to get this to work here is to do a vanilla install (no mirroring whatsoever), then do partition-juggling where I move files around, set up one mirrored partition, update grub, move files around again, set up the second mirrored partition, and update grub again. Seems unnecessary.

Ok, research provides some more context and options.

1. 
   

   https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes#Ubuntu_Server states (emphasis mine):

   
   
   

   
   

   N.B., If you require multipath, full-disk encryption, or the ability to re-using existing partitions, you will want to continue to use the alternate installer which can be downloaded from http://cdimage.ubuntu.com/releases/18.04/release/ As of 18.04.1, the Subiquity server installer now supports LVM, RAID, vlans, and bonds.

   
   

   
   



2. The linked related-question mentioned bug 1751656 is allegedly a duplicate of subiquity bug 1680245. That second bug page references using the alternate debian-installer to be able to use existing partitions (untested).




3. Another option to my first plan (to do a new install on the second drive) is of course to attempt an in-place upgrade using sudo do-release-upgrade. Had I not nuked the mirrored partitions during my troubleshooting/first-go, this would be a lot easier for me to attempt ... not a bad time to "practice" healing/rebuilding these two partitions.




4. The last option I'll note is what I commented above and likely what I will end up doing if the upgrade hiccups at all: un-partition the whole drive that contains the mirrors for / and /boot, create a minimal partition, reboot into the older 16.04, then shuffle creating new raid1 partitions to get 18.04 installed on the desired partition schema. (This could also be done with yet another drive that is otherwise unused/available.)

My previous complaint about "this feature was intentionally removed" was premature, of course: it has not been removed from the alternate installer, it just has not been implemented in the new installer, "subiquity". I still argue (and many on the bug pages do as well) that this is a significant problem in that one might infer that wiping data is the only way to go forward, but it is not as much a show-stopper as I originally believed.

Thanks for your time.