Bug #10708
open
ZFS bootpool boot symlink issue
Added by Paul Magid over 4 years ago.
Updated over 3 years ago.
Affected Architecture:
amd64
Description
Using 2.5.0-DEVELOPMENT when I do an install that creates a zfs mirror (MBR), the boot directory is actually a symlink to the boot directory in the bootpool pool. As soon as I do an upgrade to a newer build the boot directory symlink is overwritten and a directory called boot is created. The boot directory in bootpool goes out of sync with the boot directory that is now physically present on the zroot pool. This causes issues with kernel module mismatches etc.
To clarify: upon upgrade a physical directory called boot is created in the zroot pool over the symlink...
Reading this symlink issue I do remember that in the past days I did notice messages, indication that some files could not be found. I did noticed that during a crash recovery startup. Just for info might be related. I do not know.
Loading configuration … done
Sh: /usr/local/pkg/pfblockerng/pfblockerng.sh: not found (note I am not even using “pfblockerng” that apart)
Starting CRON … done
ERROR: It was not possible to identify which pfSense kernel is installed
Well before this occurred I did install pfSense using an USB-install disk, in combination with an USB-config disk (to automatic recover the old config). Sometimes I have the impression that it was looking for the USB-stick, not present any more.
- Assignee set to Luiz Souza
I had another issue with bootpool getting out of sync on an upgrade and so I decided to try every partition scheme other than MBR... I found that for my hardware GPT + Lenovo Fix (BIOS) works and there is no bootpool.... (My machine is an HP by the way). So, it appears I have a workaround to this issue and it involves not using MBR.
- Target version changed from 2.5.0 to CE-Next
I believe this is the root cause of the issue I hit when upgrading 2.4.5 to 2.5.0.
The original install was performed through the 2.4.4 installer using "Auto (ZFS)" option with "GPT (UEFI)" to (unusually) enable disk encryption. As I understand, this option created an unencrypted /bootpool/boot. Note it seems this might not be the case with more recent encrypted "GPT (UEFI)" installs although seems encrypted "MBR (BIOS)" does still use this partitioning scheme.
This 2.4.4 install was successfully upgraded to 2.4.5.
Then post upgrade to 2.5.0 I notied there was no web interface or DNS resolution. I believe that the updated boot files had been (incorrectly?) placed in /boot on ZFS, leaving /bootpool/boot (that was actually being used to boot) running 2.4.5/FreeBSD 11.3 still, thus breaking everything.
Solution I took was to reinstall as I'm a novice, but this should really be fixed!
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by Anonymous 
Updated by