Public bug reported:
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
** Affects: ubiquity (Ubuntu)
Importance: Undecided
Status: New
** Attachment added: "/var/log/installer contents - including syslog and
partman"
https://bugs.launchpad.net/bugs/1961733/+attachment/5562615/+files/installer-logs.tar.gz
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1961733
Title:
Jammy on ZFS: Ubiquity installer creates efi partition, then uses
existing efi partition on another drive
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1961733/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
