Jammy on ZFS: Ubiquity installer creates efi partition, then uses existing efi partition on another drive
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ubiquity |
New
|
Undecided
|
|||
ubiquity (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
Expected:
Ubiquity would create efi partition, `/dev/nvme2n1p1`, on installation drive for Ubuntu, `/dev/nvme2n1`, and use the Ubiquity-created partition for installing efi bootloader
`/etc/fstab` would reflect the installation of efi bootloader on partition created for efi, `/dev/nvme2n1p1` on installation drive, `/dev/nvme2n1`, mount appropriate partition at `/boot/efi` on startup, and direct future invocations of `grub-mkconfig` accordingly.
Actual:
Ubiquity created the efi partition on the installation drive, `/dev/nvme2n1p1`, and presumably installed grub/efi on the newly created partition, but somehow referenced a different efi partition in the system, `/dev/nvme0n1p1`, when creating `/etc/fstab`.
Having targeted this other existing efi partition in `/etc/fstab`, `/dev/nvme0n1p1`, all subsequent `grub-mkconfig` invocations were targeting this other efi partition on a separate drive, `/dev/nvme0n1p1`, instead of the partition created by Ubiquity for efi, `/dev/nvme2n1p1` on the drive where it installed Ubuntu (the one where efi was "supposed" to be located).
Note `/var/log/
```
Feb 17 20:10:14 ubuntu grub-installer: info: Installing grub on '/dev/nvme2n1'
Feb 17 20:10:14 ubuntu grub-installer: info: grub-install does not support --no-floppy
Feb 17 20:10:14 ubuntu grub-installer: info: Running chroot /target grub-install --force --target x86_64-efi "/dev/nvme2n1"
Feb 17 20:10:14 ubuntu grub-installer: Installing for x86_64-efi platform.
Feb 17 20:10:15 ubuntu grub-installer: Installation finished. No error reported.
Feb 17 20:10:15 ubuntu grub-installer: info: grub-install ran successfully
```
However, `/etc/fstab` shows that `/dev/nvme2n1p1` is not the efi partition, `/dev/nvme0n1p1` is:
```
# <file system> <mount point> <type> <options> <dump> <pass>
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=B045-5C3B /boot/efi vfat umask=0022,
/boot/efi/grub /boot/grub none defaults,bind 0 0
UUID=584b9b78-
```
Steps:
On computer with >= two hard drives, the opposite drive targeted for installation having a previous linux installation and existing (leftover) efi partition:
Boot jammy installer USB
Select install
Select ZFS as filesystem
Wipe installation target drive
Proceed through installer as normal (no special conditions)
reboot
check `/etc/fstab` to find opposite drive used for Ubuntu has been configured for efi partition
Background:
I started investigating this situation when I noticed there was no history entry in my grub menu for the zfs snapshots taken by `zsys`. Finally tracked down that it was because efi had been put on another drive, but not until exhausting several other possibilities.
Initially thought it was an issue with `zsys` not creating snapshot entries. When I determined `zsys` was working I thought it might be `/etc/grub.
However, I am assuming that because of the automatic entry created in `/etc/fstab`, Ubiquity was most likely responsible for choosing the other drive for efi, despite what its logs say. Ubiquity should probably use the partition it creates for efi instead of using one from another drive, therefore I think this is a reasonable bug to report.
This is similar to issue: https:/
Long story short, had Ubiquity configured `/etc/fstab` for the partition it made for grub/efi, history entry would have been present in grub menu. Once I changed `/etc/fstab` to use the partition Ubiquity created for efi, the history menu appeared and was able to be viewed and utilized as normal.
There is a very long comment on Github zsys repo here regarding the steps I went through to debug - it is missing the part where I investigated `/var/log/
Looks like a duplicate of 1396379 installer uses first EFI system partition found even when directed otherwise although the improper log information may warrant a bug report.