Probably not. Like I said, only disable non-essential things. This is all essential, so don't disable those. You can remove theSince my root partition is on zfs pool if I disable everything will the system boot ?
opensolaris_load="YES"
though, it was never required (if a module depends on a another module it will get loaded automatically).Just did it yesterday - the last one of my 3 desktop machines. ZFS had no problems. Today I have also upgraded the pool and everything is working. Built world, kernel, removed graphics/drm-fbsd12.0-kmod, installed graphics/drm-fbsd13-kmod after that and replaced all EFI bootloaders.I am planning to upgrade server with zfs root running 12.2 to 13.0
Any precautions I should take care of? Or should I follow the standard route upgrading with freebsd-update?
zpool upgrade -a
before you have at least one new bootloader present.If you previously had graphics/drm-kmod installed this will automatically be done with aremoved graphics/drm-fbsd12.0-kmod, installed graphics/drm-fbsd13-kmod
pkg upgrade
.I know. I am just such an old school guy...If you previously had graphics/drm-kmod installed this will automatically be done with apkg upgrade
.
I am planning to upgrade server
failok
- fstab(5)).Servers are usually easier to maintain than desktops. If you have kernel bound loadable modules, you should rebuild/install them after upgrade. Upgrade the UEFI loader in boot partitions before you commitI am planning to upgrade server with zfs root running 12.2 to 13.0
zpool upgrade -a
. Wait with pool upgrade until everything is working and you can be sure that you are not going to move back to 12.2.I've upgraded so many systems over the years it more or less became standard practice for me. If I have some time I'll try and whip up something, with some additional notes. I see quite a few people getting caught with the renaming of fusefs(5) for example too.I could have saved myself some trouble, especially the part about disabling modules. Plus upgrading packages before the first reboot, which would have also solved the problem. You ought to put something like this in the faqs and howtos, if you have the time and inclination.
Muscle memory. Fingers type faster than my brain can keep up.Nit:freebsd-update
(notfreebsd-upgrade
…)
I can see from /usr/src/sys/amd64/conf/NOTES that there is a sectionHmm, I remember that I read something about "delete opensolaris_load="YES" " when you use zfs - it anyhow works on my box without removing. But how about "zfs_load="YES" " - is that still needed ?
#####################################################################
# ZFS support
# NB: This depends on crypto, cryptodev and ZSTDIO
options ZFS
#####################################################################
… something about "delete opensolaris_load="YES" "
… "zfs_load="YES" " - is that still needed ?
Before 13.0 (9.x, 10.x, 11.x, 12.x) it was a dependency of zfs.ko. So it's normally automatically loaded when you load zfs.ko. That's why it doesn't matter if you add it or not, it's going to get pulled in anyway. On 13.0 zfs.ko doesn't depend on opensolaris.ko anymore at all, so it's useless to load it (for ZFS at least, it has some other uses too).it anyhow works on my box without removing.
Just asking out of my curiosity - what are the other use cases of opensolaris? Did not find much documentation about that.13.0 zfs.ko doesn't depend on opensolaris.ko anymore at all, so it's useless to load it (for ZFS at least, it has some other uses too).
It used to be an ABI layer just like linux(4) but for Solaris executables. There was a time we had a System V R4 and iBCS2 ABI compatibility. That SRV4 layer kind of morphed into opensolaris.ko and it's primary use was for ZFS. To be honest I'm not sure if it supports much else nowadays.what are the other use cases of opensolaris?
… an ABI layer …
certctl(8)
. This is really a welcome surprise, since management of certificates seems pretty basic for system security. Also briefly read blacklistd man page to enhance understanding of functionality.FreeBSD initially took it directly from OpenSolaris:Was that the SPL?
Make sure to update your boot partition and/or efi loaders.
Whatever you use, you should do that.I don't use UFS, so does this even apply to me?
If so, are there any instructions on how to do this?
gpart show
.$ gpart show
=> 34 976773101 ada0 GPT (466G)
34 1024 1 freebsd-boot (512K)
1058 968883200 2 freebsd-ufs (462G)
968884258 7888876 3 freebsd-swap (3.8G)
976773134 1 - free - (512B)
$ gpart show
=> 63 500118128 mirror/gm0 MBR (238G)
63 1 - free - (512B)
64 500118120 1 freebsd [active] (238G)
500118184 7 - free - (3.5K)
=> 0 500118120 mirror/gm0s1 BSD (238G)
0 490733568 1 freebsd-ufs (234G)
490733568 8388608 2 freebsd-swap (4.0G)
499122176 995944 - free - (486M)
$ gmirror list
Geom name: gm0
State: COMPLETE
Components: 2
Balance: load
Slice: 4096
Flags: NONE
GenID: 0
SyncID: 2
ID: 2236105550
Type: AUTOMATIC
Providers:
1. Name: mirror/gm0
Mediasize: 256060513792 (238G)
Sectorsize: 512
Mode: r2w2e5
Consumers:
1. Name: ada0
Mediasize: 256060514304 (238G)
Sectorsize: 512
Mode: r1w1e1
State: ACTIVE
Priority: 0
Flags: DIRTY
GenID: 0
SyncID: 2
ID: 4267686746
2. Name: ada1
Mediasize: 256060514304 (238G)
Sectorsize: 512
Mode: r1w1e1
State: ACTIVE
Priority: 1
Flags: DIRTY
GenID: 0
SyncID: 2
ID: 2938659242