[Bug 1961733] Re: Jammy on ZFS: Ubiquity installer creates efi partition, then uses existing efi partition on another drive

Ubfan 1961733 at bugs.launchpad.net
Wed Sep 7 21:46:05 UTC 2022


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.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to ubiquity in Ubuntu.
https://bugs.launchpad.net/bugs/1961733

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

Status in ubiquity:
  New
Status in ubiquity package in Ubuntu:
  New

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubiquity/+bug/1961733/+subscriptions




More information about the foundations-bugs mailing list