Bug 287420 - upgrade to 14.3 made system unbootable (zfs unencrypted boot, encrypted root)
Summary: upgrade to 14.3 made system unbootable (zfs unencrypted boot, encrypted root)
Status: Closed Not A Bug
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: 14.3-RELEASE
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2025-06-10 08:51 UTC by Paul Ivanov
Modified: 2025-06-10 21:37 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Ivanov 2025-06-10 08:51:07 UTC
I just did a `freebsd-update -r 14.3-RELEASE upgrade` on a 14.2 system (followed by `install` ) and on reboot now cannot get the system to boot into FreeBSD. 
After `Setting currdev to zfs:rpool:` I see several `zio_read error: 5` and 
`ZFS: i/o error - all block copies unavailable` messages, with a `Failed to find bootable partition` and an `ERROR: cannot open /boot/lua/loader.lua: no such file or directory` at the end.  One thing that might be related to this is that I have been running an unencrypted boot with an encrypted root partition as described in this forum thread (https://forums.freebsd.org/threads/the-quest-for-unencrypted-boot-and-zfs-native-encrypted.91940)  and one of the messages during `freebsd-update -r 14.3-RELEASE install` that might have been the source of the pain I'm dealing with was 

`Installing updates...Removing conflicting directory ///boot/boot`

I am able to boot the system from an iso and both the unecrypted boot pool and the encrypted root pool are fine. It seems that the upgrade did not leave the contents of /boot in a bootable state.
Comment 1 Paul Ivanov 2025-06-10 21:37:17 UTC
After re-reading my own thread for how I set up this system, it turned
out that this was a quirk in my setup and the result of using the same
zfs dataset as both an initial root partition, and later a /boot
partition. After re-reading my own thread for how I set up this system,
I needed to have /boot/boot be a symlink to '.' in order for the dataset
to work as an unencrypted root partition. As this system doesn't use the
/boot/boot MBR, I was able to get away with having /boot/boot be a
symlink, and I had moved aside the contents of the original /boot/boot
in case I ever need it later. The upgrade overwrote the /boot/boot
symlink I put in to make /boot also function as a standalone /,
replacing it with the MBR /boot/boot. Putting back the symlink fixed my
booting issue.