The PKGBASE way of things on FreeBSD is still not fully mature (and officially marked as experimental). I tried to cover all PKGBASE things in the Brave New PKGBASE World article but I need to add …

YouTube video by サクラ色のくらら。

This morning I did something that I promised myself I would not do again. I ran ` `pkg upgrade``. After several wasted hours trying to fix whatever had destroyed my personal workstation mate desktop I surrendered, activated my previous beadm, and rebooted. Now I have a working system again I can post this. I do not know what is going on with pkg or why broken software is being distributed via update but I do know that this sort of behaviour is very sketchy for what claims to be main-line software.

I'm just getting started with BEs and ZFS. As I build my understanding, reading other people's tutorials, etc, I feel like there are a few distinct ways that BEs can be used to (eg) upgrade a system. Below is my current view — does anyone do anything different? I'm just trying to see what different options are out there, with different pros and cons. (Aside: some threads on a similar topic: https://forums.freebsd.org/threads/boot-environments-beadm.87789/, https://forums.freebsd.org/threads/...ot-environments-with-make-installworld.84677/) **ZFS datasets** First, there is the question of how to arrange the ZFS datasets — the main ones being "shallow" or "deep", as described in the bectl(8) manpage. The older beadm tool seems to assume "shallow," and that's also what the installer uses when setting up boot-from-zfs. So, that's what I have. ▶ I wonder: Do many of you use the "deep" layout (or something else)? What advantages are there, other than being a more readable/obvious? **Upgrade Process** Second, there is the process used to actually perform an upgrade and roll back if needed. It seems like there are roughly 4 approaches, but I wonder if any of you do something different? Also, for all of these, I think there is still a separate concern of upgrading the BIOS/EFI boot loader, between releases? That stuff is outside of ZFS, so not covered by BEs, as I understand it. Let's say we're currently in a "v99" BE and are upgrading to v100; here are the approaches as I see them: **A:** 1. create new BE called _v100_ 2. mount it somewhere (/tmp/v100) 3. upgrade inside that mount, using appropriate flags (such as `freebsd-update -b /tmp/v100` or `make DESTDIR=/tmp/v100 ...`, etc) 4. unmount 5. reboot into it, confirm all is well 6. If something goes wrong, activate the old _v99_ BE. _Downsides:_ You must remember to use the special flags to target the dest dir. I would worry in the back of my mind that some tool assumes the wrong thing and touches the running system (rather than the /tmp/v100 dir) accidentally. **B:** This is essentially the same as (A), except rather than using special flags to do an upgrade in a dest directory, we would use either `chroot` or `jail`, and then use the "normal" upgrade commands inside there. Example w/chroot: https://vermaden.wordpress.com/2021/02/23/upgrade-freebsd-with-zfs-boot-environments/ _Downsides:_ You need some familiarity with chroot/jail. The `bectl` tool has built-in support for jail/unjail, though. **C:** 1. create new BE called _v100_ 2. reboot into it immediately 3. upgrade the running system 4. reboot again (to complete the upgrade), confirm all is well 5. If something goes wrong, activate the old _v99_ BE. _Downsides:_ Two reboots **D:** 1. create new BE called _v99-backup_ 2. rename the current BE _v99_ to _v100_ 3. upgrade the running system 4. reboot into it, confirm all is well 5. If something goes wrong, activate the _v99-backup_ BE. 6. optionally, rename _v99-backup_ to plain _v99_. _Downsides:_ You never actually booted v99-backup before an emergency situation; makes me slightly uneasy. ---- Most guides I've seen use approach (A) or (B). Personally, (C) appeals to me since it seems the most foolproof. ▶ Do you use one of those, or something different?

Following several unsuccessful attempts to upgrade from 13.2 to 14.0, I seem to have corrupted the original system in some way. Rolling back to the original using beadm has usually worked for me - but not this time. Maybe I did something without realising. Currently, on my 13.2 if I have Firefox running (for example) and then run Dolphin, the system crashes. Looking at the output of **top -n -o swap 183 | less** works, I can see that **kioslave5** use climbs relentlessly, and unless I kill **Dolphin** it will crash **KDM**. Using **Thunar** has no such effect. So two questions: 1. What can I do to fix this? (I don't like upgrading semi-broken systems) 2. Should I try to upgrade to 14.1 instead (there seems to be some bugs around 14.0) This is completely outside my previous (scant) experience. All advice welcome.

I noticed last week on a VM (FreeBSD as guest on VirtualBox, efi boot) that the boot environment didn't work when you select it on the beasty menu. The kernel runs until it comes to mount root. Then, you read "internal error: failed to initialize ZFS library". After that, it seems that the ZFS root filesystem remains read-only. You can imagine easily that it crashes soon after because there is no device in `/dev` for example. But, if you activate a BE with beadm (for instance) and reboot, all is working well. I even experimented no boot at all with efi but cannot tell the exact circonstances. I eventually understood where the problem lies. To tell the story briefly, I came from FreeBSD 12.0 (or before) and never updated this essential efi file, I mean `/efi/boot/BOOTx64.efi`. My previous BOOTx64. efi: 393216 bytes. The 12.1 loader.efi: 460800 bytes (no problem with 12.2). The 12.2 loader.efi: 488960 bytes. So, at each OS upgrade, even minor, do something like that: ` `mount -t msdosfs /dev/drive-name-partition /mnt cp /boot/loader.efi /mnt/efi/boot/BOOTx64.efi`` _drive-name-partition_ is often ada0p1 but you have to look where the efi partition lies with ` `gpart show``.