markmcb: how confident are you that you uploaded the right binary on your ESP? :-)

s/uploaded/updated/

kevans: I'm realizing that the man page for 14.1 (which I was referencing) gives different guidance than the stable doc. 14.1 shows /boot/efi/efi/freebsd/loader.efi as the target, while stable shows /boot/efi/efi/boot/bootx64.efi

markmcb: the answer is yes

unless you know better you probably want both right now

\efi\freebsd\loader.efi is what we configure ourselves to boot from, but in some circumstances you can end up not using the freebsd efibootmgr entry we add and you're at bootx64.efi instead

ah yeah, now that i look at efibootmgr output, i see both as entries

yep, that was it. thanks for the help.

You folks happen to use FreeBSD for "Desktop" type computing?

i've run freebsd on my laptop for the last... 7 or 8 years

I have it on a laptop that isn't my main machine because it's the only system that doesn't randomly freeze on that hardware for some reason

I run some VMs and compile stuff against FreeBSD on it

i run freebsd on all the computers i have

yes, including desktop

I got Linux Chrome and Linux Discord working decent

Chrome complains that it is out dated

just doing FreeBSD in a virt-manager vm right now

I like how it has stayed true to real Unix KISS

anyway, thanks for the input folks

I am considering swapping over to FreeBSD as my Host OS

Hm, this is getting weirder by the hour. Does anyone have an idea why "mount zpool/foo /mnt/foo" would fail with "operation not permitted", but "mount -t zfs zpool/foo /mnt/foo" would work just fine?

Neither of those two things are the correct way to do this for zfs. For zfs use "zfs set mountpoint=/mnt/foo zpool/foo" or something similar, that's off the top of my head.

rwp: mountpoint=legacy. Unfortunately it's what podman uses (and I can't see a way to change that, so far)

Hrm, it might even be stranger than that.

mount defaults to ufs (IMO), so without -t you are supposed to get error with non-ufs case

with mountpoint=legacy you are supposed to be able to use mount -t zfs (thats the whole point of legacy, so you can set those mounts into /etc/fstab.)

tsoome_: yes, I was barking up the complete wrong tree

tsoome_: thanks for confirming though. I was going from the assumption that, like on Linux, 'mount' would be able to figure out what filesystem to use

hello

Any idea why during FreeBSD 13.4 boot I use this message? "Loader needs to be updated"

I used mfsBSD to remotely install a ZFS image (13.4). Can this be related?

after the update to 14.1, boot-flagged geli partitions that don't get a valid passphrase from input aren't ignored anymore but just stop the boot in its tracks. this seems like a spectacularly bad idea – is there any way i can have it revert to the previous behavior?

CyberCr33p, Perhaps related. But not abnormal when the loader detects newer stuff than it knows about. "man gpart" and something along the lines of "gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 ada0" for GPT on Legacy BIOS booting, something like "gpart bootcode -p /boot/boot1.efifat -i 1 ada0" for UEFI. Pretty sure. Double check me here.

I assume this is a common thing but I havent been able to find a writeup of it. I am setting up a database server I have 2 pools zroot zroot is system disk(s) and tank are 4 extra disks, however the databases logs etc are all in /var still so I want to move (ideally) /var to tank/var but probably /var/db and /var/log instead (to not mess up other things). Do you know if there exists any guides for

doing this?

bbsl: "zfs set mountpoint" is the solution and zfs-set(8) your guideOD

rwp I reinstall the bootcode: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 nvd0 but the same issue

rwp also found this: reviews.freebsd.org/D45890

rwp reviews.freebsd.org/D45889

CyberCr33p: is it possible to use legacy BIOS boot on that machine ?

mzar yes it use legacy BIOS

OK

but I don't understand why I get this message. The /boot/loader is from the upgrade to 13.4

I rebuild the system world/kernel when there are patches available

CyberCr33p: what is your message? does your machine boot ? is zpool upgraded to the most recent version of ZFS available on this OS release ?

it boots without issue, zpool is alread in last version as 'zpool status' doesn't show any warning

cool, so what's the problem ?

I worry for the future, if I have to "upgrade" something or if this is a bug

Since it boots (good!) then it should be possible to replace all of the parts of the boot loader with consistent versions and then avoid this message. That you are still seeing this message indicates that what is printing this message has not been refreshed with a consistent replacement yet.

but I believe that I have already the latest versions

CyberCr33p: additional warning is never a bug, thanks to such warning you'll keep your bootcode updated

mzar I don't see the warning as this is remote server. Only if I connect KVM :D

so no worries

if you want the most recent version of the loader, I can share mine, from 15-CURRENT

it will boot 13.4

I haven't update the bootcode in other servers but on this as I have KVM connected I did: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 nvd0 and gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 nvd1

Those commands seem reasonable to me. Is it possible to determine the version of the boot loader that is loaded? Because that seems to be the test which triggers this warning.

that's fine, unless you have freebsd-boot on different slice

Sorry but I don't have any direct experience with the details here and don't know where to point you directly. I just see that the boot code is looking at the loader version and if it is below 3 then it triggers the warning message.

hmmm I believe the commit was for 14-STABLE and merged to 13-STABLE. Maybe it checks newer bootcode ?

And then the other reference you cited added additional things that would also trigger that warning message.

CyberCr33p: download.freebsd.org/snapshots/amd64/15.0-CURRENT/base.txz - you'll find the most recent version of gptzfsboot here, if it's your concern

it will boot 13.4 and 13.5

I will e-mail @imp to ask if it's bug or not

and I also try to see how to find the loader version

mzar: ok I think I somewhat grasp zfs set but its the moving existing mountpoints and especially /var Im worried about can I ex do `zfs create tank/var && zfs set mountpoint=/var tank/var && zfs set moiuntpoint=none zroot/var` or will my system blow up then?

mzar can you please run this command: strings /boot/loader | grep loader

on your 15 system

on my system it says:

BTX loader 1.00

FreeBSD/x86 bootstrap loader, Revision 3.0

I guess the loader is version 1.00 on 13.4

or it can be version 3.0 from "Revision 3.0"

also I found this: forums.freebsd.org/threads/loader-needs-to-be-updated-14-stable.94857

holy shit they read the release notes :-)

CyberCr33p: it's BTX loader 1.00 since a while, I have not checked it when I was booting FreeBSD 2.2.6, but I guess it was already BTX loader 1.00

CyberCr33p: booting from ZFS could be fragile, so the most important is to update /boot/gptzfsboot, especially when you are upgrading boot zpool

I use a ZFS snapshot created in other server, and then I use mfsBSD to install it

but now worries if you can still boot from removable or over PXE and update it later

I believe the initial FreeBSD version was 13.0

cool

and then the server I use as "image" is upgraded to 13.1 --> 13.2 --> 13.3 --> 13.4

have you considered upgrade to 14.1 ?

so far zpool status doesn't ask to upgrade the pool

so I didn't have to update boot loader yet

yes, usually the version of ZFS remains the same for whole cycle of major version

*lifecycle

I plan to upgrade to 14.x next year

why are you delaying it ?

have no much free time at the moment and it will take many hours to rebuild ports

next year we'll be upgrading to 15

I manage ~160 servers

OK, all of them run FreeBSD 13 ?

yes

for web-hosting

so you have poudriere somewhere probably ?

no

bummer

I have a ssh client that allows me to run commands at the same time on all servers

so I go the classic route with /usr/src and /usr/ports

setting own poudriere server will save you a lot of time

I plan to use poudriere in the future but it needs time to setup, because I have custom options on many ports

as well as installing own builds and following STABLE

you need one decent machine to build FreeBSD from sources and one decent machine to build packages

it could be the same machine

yes

indeed, running freebsd-update on ~160 serves is showstopper

but "make installkernel && make installworld" is fast

now I use MAKE_JOBS_NUMBER=4 in /etc/make.conf and for build world/kernel I use "make -j1 ...." to avoid server overload

you build kernels on all of them ?

yes

the same kernel

:O

CyberCr33p: have you heard of nice(1) ?

that's the waste of resource

s

rtprio yes

CyberCr33p: build on one of them and share it via NFS

then install somewhere poudriere-devel and build customised port on one machine for this whole farm

mzar I will get a seperate machine for this

you will save a lot of time, which you can spend on other things

I just have to find some free time (I work 12-16 hours / day) to setup poudriere

you will save a lot of electricity too

mzar they are dedicated servers, so electricity price is already included

:D

that's really sad story

anyone have a good solution for firewalling (pf) vnet jails on the host system rather than within the jail itself?