Unable to install with recovery partition while preserving existing EFI Partition.

[zaphod80013]

Reporter info Ray Sutton

Distribution - pop-os 18.04 intel_21 iso SHA256: b35364af1fe4ac46a6bf653d66e7833c2bf4b15deaa5c146a838ecdda03e4475

Issue/Bug Description Unable to perform a complete UEFI install while preserving existing EFI partition.

Performed a test install on a spare drive with an existing EFI Partition containing grub and a bootable Kali Linux iso. Erase & Install did exactly what it said it would. Did a 'dd' restore of the EFI partition and attempted a manual partitioning but it did not give me the option to allocate the recovery partition.

Steps to reproduce (if you know):

Expected behavior: It should be possible to perform a uefi install, including recovery partition, in the spare space of a disk containing another operating system. I'm not asking that grub necessarily maintain bootability for the other OS only that an option exists to install into the spare space and if it finds a pre-existing grub install it maintain the entries for pre-existing operating systems, even it it replaces the grub install.

Other Notes: Personally I think It should be possible to mark one (or more) existing partitions as 'protected' and have the install process work around these when configuring the disk.

[mmstick]

This is what the custom partitioning view is for.

[zaphod80013]

re 'mmstick' comment, yes but if you use the custom partitioning view and allocate space for the root and recovery partitions there's NO way to assign a partition to the recovery function, recovery is not in the drop down list. If you assign the combined space to root it does not reapportion space to create a recovery partition of it's own accord (as OS X does), additionally it doesn't offer the option of encryption. So the custom partitioning option offers me significantly less functionality which is what the tickets about.

Basically I want control of the disk layout without loss of functionality. On Pop-OS 17.10 I manually installed full disk encryption (including boot partition) and a bootable Pop-OS iso (stored on the EFI partition) to provide my own recovery function. I also need a bootable live kali iso on the machine and an enlarged EFI partition has proven the simplest way to organize things.

The installer at it's current level of development offers no middle ground, the ability to resize partition during the automated erase & install would go a long way to addressing my concerns.

[mmstick]

@zaphod80013 There may not be a drop down for it, but you can specify that partition by setting a custom mount point at /recovery. And while there's currently not a way to create LVM on LUKS devices in the custom partitioning view at this time, you may create this outside of the installer and install to it via the custom partitioning view.

[zaphod80013]

@mmstick Thanks for the info, I was in the process of shrinking the luks partition so I could slide it right to make some room but your approach sounds a boatload easier, I'll give it a shot.

[zaphod80013]

@mmstick , thanks again your approach worked a charm. One thing to note, initially the installer didn't see the luks partition as an encrypted partition. I opened 'modify partitons' to see if gparted was seeing it as encrypted (it did) without modifying anything once I exited gparted the installer recognized it as encrypted.

This approach solved another issue that drives me crazy, assigning random meaningless names to things, on decrypting the partition it offers the option to name it, this name is used during boot to specify the partition to decrypt and by creating the VG manually I could give it a sane name.

One thing I did note is root ended up on the partition I designated as swap and vice-versa, I don't know if that something wonky in the installer or me (I've been up over 19hours) I'll investigate that tomorrow evening.

While @mmstick's solution worked for me, I'm going to leave the issue open because I think the discussion could act as input to make the installer more flexible.

[mmstick]

@zaphod80013 These things are already in the works to be done, it just requires more time to implement. The randomly-generated names will remain within the automatic installs though, due to VG/PV name conflicts causing installs to fail, and UI designers not wanting users doing auto installs to have to worry about things like PVs and VGs.

One thing to note, initially the installer didn't see the luks partition as an encrypted partition. I opened 'modify partitons' to see if gparted was seeing it as encrypted (it did) without modifying anything once I exited gparted the installer recognized it as encrypted.

What did the installer say the partition was? None?

One thing I did note is root ended up on the partition I designated as swap and vice-versa, I don't know if that something wonky in the installer or me (I've been up over 19hours) I'll investigate that tomorrow evening.

If that's what happened, I would like to know your disk layout, and the UI steps you took that caused it to happen. This would more than likely be a bug within the UI frontend's code.

[zaphod80013]

It was showing the pre-encrypted disk as free space. I tried 3 more trial installs and couldn't reproduce the issue, the space showed as an encrypted volume. As to the logical volumes within the encrypted volume I allocated (in ascending order of starting logical extent) root, swap, home. The order displayed was home, root, swap (suggests sorted list) I was, perhaps mistakenly, expecting the partition order to mirror the physical layout on disk. The presentation order was counter intuitive to me, causing me to select the wrong partition as root. The UI is consistent in that the tool tip lv name mapped to the correct partition on disk in the final install.