Jammy on ZFS: Ubiquity installer creates efi partition, then uses existing efi partition on another drive

Bug #1961733 reported by Avery Freeman
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ubiquity
New
Undecided
auto-cjwatson
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/installer/syslog` suggests grub was installed to Ubuntu installation drive without issue:

```
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,fmask=0022,dmask=0022 0 1
/boot/efi/grub /boot/grub none defaults,bind 0 0
UUID=584b9b78-7d8d-4a5a-9263-d6f6a48adc6b none swap sw 0 0
```

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.d/10_linux_zfs` not identifying the snapshots. Turns out it was the installer the whole time, although I am not sure why grub cannot create history entries in a grub menu on an efi partition of a different drive, so perhaps there is additionally an issue with 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://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1890453 However, I created a new issue since bug 1890453 involves a Macintosh installation, while my case involves choosing the ZFS option in Ubiquity installer, so I was not sure if my issue specific to the ZFS option, or theirs specific to being installed on a Mac.

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/installer/syslog`, as I only became aware of that log's existence after coming to file this bug, so it is missing the assumption that the misconfiguration was only in `/etc/fstab` and not the installer using the wrong drive altogether: https://github.com/ubuntu/zsys/issues/223

Revision history for this message
Avery Freeman (averyfreeman) wrote :
Revision history for this message
Ubfan (ubfan1) wrote :

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.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

  • auto-cjwatson Edit

Bug watches keep track of this bug in other bug trackers.