At least uname and freebsd-version say so

Huh, weird. After another reboot the EOL warning is gone :O

bendodroid:generic kernel?

flatdog: yes

Hmmm, weird

I'll see if the other machine that is still installing updates shows the same behavior

Maybe it was just some weird cache thing? Are there mirrors involved in the EOL check that might have been out of date?

Upgraded from 13.2 or something else?

RC, whatnot

From 13.2-RELEASE

I think this was already happened on the forums, let me check and I will point you to the thread, if you wish (SirDice rocks)

If you have the link, yes please :)

bendodroid: I've seen this before, i think it is hopefully fixed by an upgrade to freebsd-update

but I'm not seeing anything here, freshbsd.org/freebsd/src/branch/releng/14.0

Title: FreeBSD / src - FreshBSD

Ok, so the second machine finished upgrading and it gets better: 2 consecutive 'freebsd-update fetch' invocations lead to the first having the EOL warning and the second one not having it

This sounds like a fun bug :D

can I get FreeBSD 14 torrent yet?

3 times, bendodroid. 3 times

Well, on the second machine I did the final reboot according to the handbook and then 2 fetches and it went away without a reboot inbetween

14

So I didn't miss a reboot after all *relieved sigh*

Why in the world did the update delete sudo pkg? I had to look up the root passwd!

yeah? I'll reinstall that

i'm not going to use doas or whatever

:)

pkg reinstalled 549 packages, but whatever I try to use seems to be missing: sudo, bash, startx fails.

mariuss: even when the full path is provided?

Update: startx is working after manually reinstalling sudo and bash.

Yup. The packages were gone.

Also, a number of packages (19) downgraded. Most, just revisions, but others to a previous version.

mariuss: forums.freebsd.org/threads/14-0afte…r-pkg-upgrade-sudo-dont-works.90987

Title: Solved - 14.0After pkg upgrade sudo dont works | The FreeBSD Forums

post #16

Yes, I went and edited the conflicts. Both /etc/group and /etc/password are correct.

After reinstalling both packages (pkg did not complain that they were already installed) everything worked w/o editing config files.

the EOL timestamp in update.freebsd.org/14.0-RELEASE/amd64/latest.ssl

is 1706659200 ie. in less than 3 months

so freebsd-update is warning

Whenever I do 'freebsd-update fetch install' it complains that /etc/ssh/sshd_config is affected by the updated but no changes will be downloaded because the file has been locally modified. How do I get around this ?

yea lol i remember updarting to 14.0 im loke why do /etc/groups and /etc/passwd have hashtags

s/loke/like/

I just set up the poudriere jail for 14.0-RELEASE: I also see the EOL warning. lol

mns: but it didn't say anything about /var/db/etcupdate/current/etc/ssh/sshd_config ?

if so, you should be able to merge the file with etcupdate(8)

Could it be that you are on the RC which is now deprecated?

babz: no it did't say anything about /var/db/etcupdate/current/etc/ssh/sshd_config. Just to be clear, seeing that 14.0 is out now, I'm on 13.2-RELEASE-p5

let me look at etcupdate, I've not used it before.

Looking over at the release notes for 14.0-RELEASE, I see that sendmail is replaced by dma. dma seems simple enough, but no ability to receive email ?

with direct memory access, I hope the mails go fast!

Woot! Excited to discover how 14.0 it's doing with RPI. Going to try it really soon

I haven't had a good look at dma yet, except to see that for local mail it works on its own

mns i was also wondering about the best way to get those changes. i have not used etcupdate before. perhaps it's actually easy peasy

Hmm so I tired updating to 14.0 but I keep getting errors about the i915 module not working so it won't start the desktop

s/tired/tried

I reverted the snapshot and boot env so I'm back on 13.2-p5

I did keep running the freebsd-update install as suggested after the install but no luck, and the drivers were not installed from ports :(

I also got many libcrypto errors so it looks like it didn't update many packages properly

Did I miss a step perhaps? I thought freebsd-update install should have updated everything on the second run after the reboot

I love ZFS snapshots tho <3

Oh well I'll read up a bit more and try again, but if any of you have any idea it'd be nice

bash and sudo arn't in pkg 14 repos?

er... no. They're there.. wonder why it wants to uninstall them

silly pkg doing silly pkg things.

mns, The merge notification about sshd_config was something that happened in 13 and several of us have commented upon it but so far no one has gotten to the root cause yet. It did not do that in 12 so this is new but new in 13 and 14 just appears the same as 13 for this.

scoobybejesus: yeah I don't think I need etcupdate. I made somce changes to /etc/ssh/sshd_config around April timeframe

rwp: ok so that's good to know that I'm not the only one :-)

I did the same. I mean, I think the default config has permitrootlogin no, and I have it as yes on my vps. so every freebsd-update tells me that, so I don't get the upstream changes. but I guess upgrading to 14 gives the option to edit the file

I just upgraded a couple of boxes to 14.0-RELEASE and discovered that any user who types "su", automatically gets root now!

No password required or anything.

rwp: did you make changes for hardening sshd ?

mns, You are not the only one. Recently saw this thread on the mailing list about it too. lists.freebsd.org/archives/freebsd-stable/2023-October/001527.html

Title: Re: FreeBSD Errata Notice FreeBSD-EN-23:09.freebsd-update [REVISED]

scoobybejesus: I keep that setting always set to no. no one should need to ssh in as root

That thread has many replies but no real root cause. But it did have a few interesting ideas in it.

crazy how lang/python pkg will install 2.7 - 3.11 in freebsd 14

I'll have to look at that thread

rwp: the hard drives are in the enclosures.. the fun is starting :)

the machine with the 3 drives has 14.0 also.. figure might as well try it out with a software raid restore :)

what could possibly go wrong.... sarcasm

mns, scoobybejesus, I also must change PermitRootLogin to yes now too because that's how backup works here. And no it is not a security weakness as no one is going to crack an ssh key by brute force.

voy4g3r2, Good luck with the recovery! And yes I am familiar with the SCT ERC issue. The page you want for Western Digital is this one. blog.westerndigital.com/wd-red-nas-drives

Title: On WD Red NAS Drives - Western Digital Corporate Blog

That WD page identifies which drives their marketing department slipped in SMR drives into the normal CMR drive space. If you have an SMR drive I guess you can only remove it and replace it with a new CMR drive.

voy4g3r2: after doing some research on the rpi red led thingy, if it were to lit off, it means it had a "brownout" because of not having enough power but clearly our rpis are still functioning when running 14.0-RELEASE. Another thing I found out is that in Linux, one can turn off both red an green leds if they want to. My hunch is that something in the boot process (like an rc script) might be turning off the red led by defaut.

kenrap: yeah that is what i am seeing too the gpio are "on" by default through their raspi-config

so some magic is happening

Title: dpaste/cxfx (Plain Text)

fun times..

time to fsck some drives, it looks like

rwp: interesting email thread. I didn't realise Include was a supported option

Anyone who has upgraded to 14.0-RELEASE?

iio7: a few :) arm64 here

On my amd64 boxes, all users who type "su" at the terminal gets root access without being prompted for a password now.

After the upgrade from 13.2 to 14.0.

are those users part of the wheel group?

for my install i am prompt for users to su , denies if not part of wheel group

No.

But even if they where, they are supposed to be prompted for the root password.

Noone else seeing this?

mns, The interesting idea for me out of that thread was to add specific options to the command line argument list. That does not work for Include. But it does work for the majority of my needs.

It also does not work for the Match configuration either which is another custom environment I live in too. But that's pretty unusual.

For me it was just using the '-f' option. It is a work around though, since /etc/ssh/sshd_config should be modifiable and freebsd-update should be able to work with that

Agreed. sshd_config should be locally modifiable and the update should handle it. It's a regression that it does not.

voy4g3r2, I am just a little concerned about your disk gpart paste showing all of the corrupt flags. Didn't you say your synology was running mdadm software raid on Linux? Wouldn't that be the place to do the recovery then?

iio7: not seeing that. su works as expected for me.

rwp - it is SHR/multiple disk.. i would but the synology motherboard died

voy4g3r2, I know your motherboard died but if the synology ran linux then though this might be heresy to say here I would recover it on a linux system not a freebsd system. (shrug)

yeah...

After you recover you would want to move all of your data over to ZFS on FreeBSD of course. But until then I would boot your favorite linux flavor and then do the recovery there. Because I don't know why it would be showing corrupt from gpart. That would make me nervous.

Title: How can I use a PC to recover data when my Synology NAS malfunctions? - Synology Knowledge Center

i found an article and trying to see how i can replicate..

to your point, following them may make more sense

Earlier this year I found myself in a problem on my 6 disk NAS. I was really paranoid because I didn't want to lose the data. I also did not have a backup, my bad, and so I really sweated through it. But it was ZFS on FreeBSD for me and eventually I was able to recover 100%. I now have a second NAS for backup now. Whew! Survived through it.

well at this point... i am looking at tarsnap.com

because i have hit that threshold myself and i can have a debian box up running real quick anyway

just need to flash real quick

these are time i wish my home lab was NEXT to me and not in another area of the house

I just skimmed that Synology article and it looks pretty good to me. That flow looks reasonable to me from here without warranty.

yeah i have played with lvm2 before synology

figure it could not be that hard to get it working on freebsd

fusefs-ext2 and geom

but yeah.. i get to the point of.. it is showing drives in stripe but complaining with said paste from before

It doesn't really say how to drive mdadm because I think it is likely that it might snag up there. But mdadm is very reasonable and I think you can get the raid online at that point. And then the rest should flow.

I don't doubt that you could get the array mounted up on FreeBSD. The problem is trying to get something which *might already be corrupt* up and running.

makes sense to me.. flashing the card now with debian and see where it takes me

If it were me I would try to make the best luck for myself as I could and match the Synology environment as exactly as possible. Which is Debian/Ubuntu as per Synology. And then I would migrate the data to ZFS on FreeBSD where it can be safe for all time.

yeah.. freebsd found the 3 drives.. only 2 usb3

but that is a whole other thing.. we have discussed laready

usb no bueno

i am getting too comfy with flashing these cards last few days

rwp: well that found it and yea... personality complex anyone? bsd.to/vtJR

Title: dpaste/vtJR (Plain Text)

but it found it :) progress

voy4g3r2, Good deal! Looks like it assembled the raid5 with no problem at all. I am not used to seeing "[4/3] [UUU_]" there and don't understand it with regards to a 3-disk raid. I go, huh?

hehe, yeah well that is how i roll

logic made sense at the time

EXT4-fs (dm-0): Number of reserved GDT blocks insanely large: 7491

this is a funny one, seems since the synology had such an old kernel.. the newer ones fixed a bug

You can always use mdadm to probe for more information about the array. "mdadm --detail /dev/md2" and "mdadm --examine /dev/sda" and so forth. But it looks good at this time.

which makes it not mount

Onward through LVM and then mounting. Good luck!

haha.. they fixed a bug in kernel afer 2018 that wil stop me from working

i got sloppy, i need version 18.04 of ubuntu from 2018....

gotta love it

well til tomorrow.. i have done too many flashes .. the adventure continues

That's why i like freebsd. nothing is what it seems. you gotta keep working at it. not old and stale like linux that just works. lol Freebsd prevents me from distro hopping

jb1277976: there is tons of history of this situation outside of it.. synology uses a kernel that had a flaw.. that was resolved in newere linux kernels

so the only way to get around it, is to use a kernel BEFORE the fix was done

Aw

use the tools you have.. on any given day i am jumping between 3 os because i have to

i just get use to it and do not have the luxury of just using one.. sometimes it is 4 if i have to play with an oracle database

keeps me on my toes

Nice

Now that the default shell is sh, is there a summary somewhere of the differences between sh/csh/tcsh?

tehpeh: They're different languages.

Any difference in featuers for interactive use?

Yes, you can't use the same loops, etc.

I think there were some usability features coming for sh in 14, but I'd have to look to see if they exist.

I've noticed sh needs two tabs to get an auto-complete suggestion list, and csh/tcsh only one tab

for example

I haven't been able to find a summary of features yet

tehpeh: Try them both and see what feels right.

will do

When I search for the binary package "radarr" on freshports, I get version 5.1.3.8246. When I search using "pkg search" on FBSD 14 with pkg set to latest repo, I get 5.0.3.8127_1. Anyone else seeing a newer version in pkg search?

have you done a pkg update ?

Yup.

iio7: look at the table on freshports

5.0.3 is expected for 14

markmcb, weird, so 14 gets an older version.

tehpeh: Ah, here we go: cgit.freebsd.org/src/commit/?id=d410b585b6f0

Title: src - FreeBSD source tree

mason: thanks :)

tehpeh: I used to be an avid pdksh fan, but FreeBSD's Almquist might do the trick for me now. I'll spend some time with it.

normally I'm fish, but on my server want to keep it to what's in base

Cannot find a GUI for bluetooth manager in pkg. Is there any?

how do i report a bug on the official wiki?

point 2 needs to qoute the inner " chars: wiki.freebsd.org/Ports/QuarterlyBra…_to_switch_from_quarterly_to_latest

Title: Ports/QuarterlyBranch - FreeBSD Wiki

CueXXIII, bugzilla.freebsd.org - I would think

Title: FreeBSD Bugzilla Main Page

So there is NO bluetooth gui in freebsd/

So there is NO bluetooth gui in freebsd? *

Beladona: Bluetooth in FreeBSD is something I generally try to avoid in FreeBSD since it's bluetooth support is mediocre...

I see

elirco: so bad sound quality?

no, it just is a hassle to set it up and even does not work with a lot of devices. (that is my experience)

elirco: ok by the way, is there even a gui based bluetooth manager?

Beladona: i don't think so, you have to use command line.

Beladona: GUIs for managing Bluetooth are generally integrated into desktop environments

meena: I have freebsd desktop env

which one?

meena: is there one "desktop environment bluetooth GUI" that actually works und FreeBSD? Never seen one.

meena: xfce

elirco: :) I am with you with sympathy

But freebsd is not a desktop OS at its core

(I think)

That's right, rather it's a "desktop-able" OS. Just DIY.

So like Linux, a few years ago (and i guess windows and macos users might say: still)

I mean, when It boots, your hardware, maybe...

wasn't there a great quote from Linus about QA in Linux: when it compiles it's good, when it boots it's perfect

Title: Linux-Kernel Archive: Re: LINUS ISN'T SHARING!! :)

meena: one could make the argument that modern versions of Windows and macOS are also desktop-able OS'..

With power users, it's never just pick-up-and-go - in my experience, with Windows you have to spend a few hours removing all the ads and installing a proper package manager, and with macOS you need homebrew and a whole bunch of other things.

Mind you, I treat Windows like an appliance OS - because I do all my daily work on FreeBSD; so I'm probably not the one everything should be measured against ;3

I have no idea what windows is these days, and after 7 months of using the previous version of MacOS i never want to do that again

o/

Do we manually need to execute command for ZFS update/upgrade, after FreeBSD upgrade from 13.2 to 14?

as the release 14 has new ZFS version

zpool upgrade is an administrative command, it should always be issued manually.

and don't forget to upgrade the bootstrap code

(before running zpool upgrade)

Thanks debdrup. Mage: so it seems the command is: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0 for that, "ada0" so it seems that's an example disk name, how can I check mine?

"zpool status" lists two things, 1: zroot, and 2: ada0p3 under "NAME" row.

So I assume it should be "ada0"?

tercaL: do you use UEFI or classical BIOS ?

with UEFI you can do something like for p in $(gpart show -p|tr -s ' '|grep 'efi'|cut -d ' ' -f 4) ; do mount -s msdofs /dev/$p /mnt ; cp /boot/loader.efi /mnt/efi/boot/bootx64.efi ; umount /mnt ; done

mage: It's actually a remote Hetzner bare-metal server, I don't really have an idea. How can I check for that?

on a box of mine, I get: sysctl machdep.bootmethod: UEFI

and the other one: sysctl machdep.bootmethod: BIOS

for UEFI, I just do

cp /boot/loader.efi /boot/efi/efi/boot/bootx64.efi

(and also /boot/efi/efi/freebsd/loader.efi)

babz: You do these before or after zpool upgrade command?

different answers on the forums; some do it before, and some do it after.

So far as I remember, the order of operations should be: System upgrade, then bootcode upgrade (which'll depend on the partition and disk layout), followed by zpool-upgrade(8).

wow, love phk's scathing review of blocklistd. he ends it with: "Other than that, once you get it set up right, it seems to get the job done…"

tercaL: I usually do it after because the command reminds me to do it

but i guess it's slightly safer to do I before

babz: Got it, thanks. You gave an example for UEFI systems, and what about classical BIOS cases? What would change in those commands?

bios ? what is that ?

from the before times

the long long ago

babz: non-UEFI systems

With MBR

Upgraded FreeBSD to 14.0-RELEASE according to instructions on the website. Now running "pkg update" gives me `ld-elf.so.1: Shared object "libssl.so.111" not found, required by "pkg"`.

I mean; this is my case, the output of geom -t: pastebin.mozilla.org/WNocFxYt

Title: Mozilla Community Pastebin/WNocFxYt (Bash)

there should be pkg-static, no?

babz: In such system ^^

babz: "bios ? what is that ?" Basic Input/Output System. The firmware of your motherboard on pretty much all computers (except for Apple) sold in 2010 or earlier.

lol

You can thank Microsoft and their stupid TPM bullshit they started pushing with Windows 8 and beyond.

i think the BIOS concept is older than microsoft, as a compagny

but i dont see the link with tmp 2.0

remiliascarlet: you'll want to use /usr/sbin/pkg (aka pkg(7)) to bootstrap pkg again

Do check that you have backups in /var/backups/ though

CueXXIII: Thanks. While it didn't resolve the problem per se, it did show me to run "pkg bootstrap -f", which did solve the problem.

pkg-static bootstrap -f

pkg upgrade -f

pkg-static is pkg(8) compiled statically, not the same as pkg(7).

pkg(7) only exists to install pkg(8) when you run pkg first time on a system, or to fix issues with pkg(8) like the above.

Quite a busy month in the UNIX space.

babz: it is important to do the cp for each efi partition, not only the first one

Well I only have one

BTW it was an outstanding bug in the FreeBSD 13.x installer (not sure avec 14.0)

babz: ok that's ok then

.. but if you have a raidz2 with 4 disks the bootcode should be copied to each ESP partition, otherwise of disk1 died for example the system becomes unbootable

mage: In case of two disks with ZFS stripe?

tercaL: yes, it must be done on both ESP

I'm wondering if it has been fixed in 14.x

fixed what ?

the FreeBSD installer in 13.x correctly create an ESP partition on each disk, but the bootcode is only installed in the first one

What I hope for is better laptop support, maybe one day...

so if the disk dies system is unbootable

mage: is this reported anywhere?

yes

ID?

258987

also 262770

thank you all

there is a review to fix this reviews.freebsd.org/D42150

Title: ⚙ D42150 bsdinstall: when installing UEFI, place the bootloader on all disks

also cgit.freebsd.org/src/commit/?id=0b7…2b3d8d2f1e90fade5236b44fd98d8e396c2 I really don't understand the advantage of mounting the esp partition just to "just change /boot/efi"

Title: src - FreeBSD source tree

Loading kernel modules ktls and ocf does work anymore under FreeBSD 14 it seems. Are they removed?

tercaL: they've been included in GENERIC I think

i saw that update earlier

i'm curious if it works out of the box now

mage: Well, much likely. I had: kld_list="ktls_ocf" in my rc.conf file, after upgrade, dmesg reports; kldload: can't load ktls_ocf: No such file or directory Unable to load kernel module ktls_ocf

Checked with: "sysctl -a | fgrep kern.ipc.tls.stats" and it seems it works out of the box.

The digits are increasing.

But under 14.0, the default for: "kern.ipc.tls.enable" is still: "0". So I'm going to keep; "kern.ipc.tls.enable=1" in sysctl.conf (it doesn't work without it)

You say that like it's a horrible hack.

A quick technical question on container/jail stuff and visibility on the outer levels. On Linux you can nest container stuff (like Docker inside NSpawn) and there are easy clues visible for a task manager to pick this constellation up and show that a certain process is running inside such a nested container. A) Is such nesting possible with FreeBSD (e.g. Jails) too? and B) Can this be picked up easily?

you can nest jails

can this picked up easily? I don't know which pattern you're referring to

but at least you have sysctl security.bsd.see_jail_proc

we can do jails inside jails ?

yes

what is the status of pkgbase?

freebsd-update takes forever for 13.2->14.0

I'm sure there are a ton of changes to make, and you want freebsd-update to be careful with what it does as well. I seem to recall it taking a while to do things when going from 12.x to 13.0 as well, if my memory serves me well

yeah..

point release -> release is usually longer than point release -> point release

plus, freebsd-update is a shell script, i won't expect it to be fast

mage: it works quite well, tho bootstrapping is still a pain. and we even have our first errata! bugs.freebsd.org/bugzilla/show_bug.cgi?id=275051#c4

Title: 275051 – [pkgbase] Package versions for 14.0-RELEASE should be "14.0", not "14"

i may delay until first patch to upgrade to 14 =]

Demosthenex: proper decision

won't take long, and I have plenty of cigarettes

mage: also, freebsd-update mostly just takes forever when you have src installed (but yeah, even without…)

CueXXIII: the fact that it is a shellscript has nothing to do with how slow that is.

i think implementing a relational database with cut, join and pipes is tho

Demosthenex: if you use ZFS it could be a proper decision

it looks like there are several issues with 2.2

ATM I'm just upgrading our Poudriere server, just to check if everything is OK

launching a poudriere build is often a good exercise for stability issues :p

mage: nothing specific, just my general caution =]

to be honnest I'm mostly on 12.4

my next task is to go update my jails

we do that with Saltstack

we have almost 100 jails in total here

saltstack is actually pretty okayish I feel.

more or less, it has bugs too ..

but for orchestration it works pretty well

I was happy having to use that in my previous project, it wasn't as bad as people say it is.

people say Saltstack is bad? first time I'm reading this

I guess most people would point towards Ansible or Terraform nowadays?

Don't know, I was pretty happy using that, it worked fine.

Terraform is useless on bare metal

and I thing Saltstack > Ansible (but that's just a personal opinion)

hehe :)

the problem with Saltstack, etc (and the good thing with Terraform!) is idempotency

That's a problem with all low-end solutions I think, I need to be careful of that when writing shellscripts, too.

But yup.,

mage: i have puppet setup, i experimented with salt and gave up

salt > ansible

shell scripts > ansible

I migrated my puppet setup to four shell scripts

remiliascarlet: "What I hope for is better laptop support, maybe one day..." I just checked, and unfortunately, it's still impossible to wake up a FreeBSD laptop from sleep. Missed oppotunity...

17:00 [ Demosthenex] shell scripts > ansible

Demosthenex: <3

Shell is still my #1 go-to tool in my box.

well I can wake up my laptop from s3

babz: That's not too bad.

i like ansible and terraform

I like POSIX compliant shell scripts.

we don't always get what we want :-)

meena: what sort of work do your 4 shell-scripts do that you were using puppet for before

babz: I was asking in the context of htop-dev/htop #1334 ; which would (on Linux) display a nested container as e.g. /snc:foo/lxc:bar … For FreeBSD there's already a function in the platform code FreeBSDProcessTable_readJailName that uses jail_get (jid.<pid>.name); though I guess that will only return the outer most jail?

Title: Guess container name from cgroup by BenBE · Pull Request #1334 · htop-dev/htop · GitHub

anyone have syncoid problems on 14.0-RELEASE?

moving to latest repo so see if the newer version will work, which is what i'm using on other comps

and now we're rocking at 113MiB/s. cool

yay

I'm going to stick to 13.2 for now, I still need to get my bug report for gcc13 not building m2

Hi, tried to update my Hetzner Server today to 14.0. That server needs realtek-re-kmod. I switched the sources to 14.0-Release with git checkout, followed by make buildworld && make kernel and rebooted. But now the realtek drivers can not be loaded due to version mismatch. Are the drivers incompatible?

rebuild the driver too

kk. prior to reboot I guess

armin: yaml... best to nuke it from orbit to be sure

i just downloaded the checksum file that is signed for 512 shasum

it tells me the key has expired

CHECKSUM.SHA512-FreeBSD-14.0-RELEASE-amd64.asc

8D12403C2E6CAB086CF64DA3031458A5478FE293

Demosthenex: That was my impression when I forst got in contact with it when I had to do Ansible. I was like "wait a second, I thought this is just YAML, how complex can this possibly get anymore...." at some point.

which pgp public server does have the update to the key?

armin: encoding actions in yaml is hell, yaml is easy, it's the relationships and complexity buried in yaml that is hell

clemens3: yup the one I find expired on 21.09.

Demosthenex: +1

armin: jokers, not?

clemens3: I wish I could say something more meaningful now. <3

psst

armin: i tried Salt because i could write the config directly in python and skip all the yaml nonsense, and it was declarative (puppet) instead of imperative (ie: ansible).

Demosthenex: okay but don't get me started on puppet, that was such a horror.

Demosthenex: I know how to use imperative so that the result is idempotent, I'm fine with Ansible. :)

Demosthenex: I prefer to write 200 lines of BASH over 20 lines of YAML any day.

Demosthenex: I know exactly what I do there, why would I even remotely try to get into so much abstraction that I can't follow my own thoughts anymore?

Demosthenex: The other side of the spectrum would be something like NixOS, I believe? I've even been running that as my primary workstation OS, it's hm, yea okay I guess?

Demosthenex: Meh I dunno, I want to tinker around with my workstation, I can understand the declarative approach in IaC, but that's about it.

Demosthenex: I mean come on, the way that you usually apply in your daily living is pretty much imperative, it's like "I want THIS VERY DETAIL here, to change, right now, let me experience what happens when I do that..."

Demosthenex: for servers, and infrastructure, yea, I agree, that there one could ask for the declarative approach, but still...

Demosthenex: There's a HUGE hype about immutability in general going on, what's your thoughts on this? next big thing or not?

(ah, on THAT topic, sorry, I found salt-ssh to be quite useful.)

armin: so, i think of installing packages much like the package manager does, it resolves dependencies. that's better than imperative in my mind

i also want the minimum changes to match the state

and i like that puppet has a discrete agent instead of being messed up by the local python install

Demosthenex: Well in a perfect world, imperative "install these packages plz" command would just run for a couple of miliseconds, saying "all wanted packages installed already, goodbye" or something like that.

Upgraded a couple of boxes to 14.0 yesterday. On one box I upgraded the zpool, which now cannot boot. Getting "ZFS: unsupported feature: com.delphix:head_errlog"

armin: package managers do that

armin: i just think configuration management should be the same way

that's why i prefer declarative over imperative

Demosthenex: It depends on the package manager, pkg_add on OpenBSD has this functionality since...3 weeks.

Demosthenex: before that it would just iterate over all possible matches (which obviously is not a great thing to do, but hey).

iio7: you probably didn't upgrade the boot loader before upgrading the zpool. The release notes say this is necessary

vortexx, yeah. I didn't find information on how to do that.

The system is borked. Going to install Linux on the box. Don't want to bother with FreeBSD crap like this any longer.

lol

crazy story but you have to do that on linux too

i'm missing the context, but pretty sure win11 would solve all problems here

all that person had to do was mount the efi partition and copy /boot/loader.efi to /boot/efi/efi/freebsd/

it's not exactly hard but it'd be nice if freebsd-update handled that or warned to do it

angry_vincent, thx, recompiling the realtek-re-kmod port with portmaster prior to rebooting to the 14.0 kernel did the trick :)

vortexx: zpool upgrade literally tells you to do it

wait, so he updated the version of the zpool?

instead of just doing a freebsd update?

separate items :P

It's always frustrating when people seem to work against the system rather than with the system.

Unfortunately I see people doing that for each and every one of the operating systems they run. Sigh.

isn't the best practice to keep the boot zfs pool at the lowest feature level

in case you need alternate media

When moving from 12 to 13 I think I waited most of a year before I decided I would zpool upgrade just in case I needed to boot the previous 12 again for some reason.

A question I always ask myself, do I need or want any of the new features offered? If not then there is no hurry.

And I realize everyone is excited about 14 but honestly I won't be upgrading my production boxes to 14 until I have upgraded my development and test machines to 14 and verified that EVERYTHING is happy. My production systems will be the last ones I upgrade.

+1

or i may do the os upgrade, but not touch the storage format

i mean, he basically upgraded from ext4 to ext5, and forgot the kernel module for ext needed updating

That's my desktop plan. Because then I can always Boot Environment back if needed and then still boot. And also that would only affect me. And I could laptop while I was working my desktop problem.

The real root cause of the problem was a failure to read the release notes. Always read the release notes and do anything it says you need to do. That is true on every system.

I mean, it's not a big deal

you can reboot on the latest install medium and upgrade the bootloader

I understand the advice, but I've never broken a system by not reading the release notes. I've broken them because of bugs that weren't documented at the time.

I want to say that bugs are the best reason for most people to wait until the .1 release but I want *you* to run the .0 early so you can find and fix those problems before the rest of us. :-)

babz: *always* read the release ntoes

i get paid good money to read release notes to prevent problems ;]

on current we call them "commits"

but sure

right. i haven't read commits in several hours. thanks for the reminder, babz

is it safe to upgrade to 14 yet?

issues like this make me nevous: openzfs/zfs #15506

Title: panic: corrupted memory in l2arc · Issue #15506 · openzfs/zfs · GitHub

15506 – Update x11-toolkits/gtk-engines bugs.freebsd.org/bugzilla/show_bug.cgi?id=15506

my zpool has zvols and l2arc, so if it's an issue on the 2.2 tree that shipped on 14, I'm likely to hit it

KungFuJesus: we have a different zfs version in 14 and 15

meena: which version?

the filer found the issue with invariant assertions enabled on 15. And while that may have plenty of different code from 14, it's not that fat diverged from 14's release code, I suspect

far*

KungFuJesus: 14.0: zfs-2.2.0-FreeBSD_g95785196f

zfs-kmod-2.2.0-FreeBSD_g95785196f

KungFuJesus: 15.0: zfs-2.2.99-211-FreeBSD_g03e9caaec

zfs-kmod-2.2.99-211-FreeBSD_g03e9caaec

I don't have a 13.2 right now, but i can probably stand one up quickly… or, i could do something silly like look at the code

2.2 vs 2.2.99 is not significant as far as what could be causing that issue

There's still not a conclusive bisect for the issue nor is it clear whether or not BRT is the culprit for this. It's happening in the DMU in l2arc reads, with a smashed stack. Needless to say, I have concerns

Oh shit: dan.langille.org/?p=7633&preview=1&_ppp=3ee26fb87e

Title: While restoring my PostgreSQL database to a new FreeBSD server, I discovered the wrong database server in a configuration file – Dan Langille's Other Diary

i like the end the best

scoobybejesus: It made me feel better.

I've said it elsewhere and using different words, but I wouldn't feel comfortable with that setup (I can see nothing wrong about using Bacula to backup hosts, but Postgres DBs is a different category)

I'm glad it's ok in the end

dvl, since you're here, any chance you did something to divert rctl logs to some place other than /var/log/messages? to me, it'd be nice for it to get its own log file, but i don't know how to approach that (here dan.langille.org/2023/01/16/how-to-limit-a-jail)

Title: How to limit a jail – Dan Langille's Other Diary

scoobybejesus: Usually that's via !rtctl or something similar.

Like adding a local5.none;local6.none to the /var/log/messages line in /etc/syslog.conf

many thanks, i will dig a little deeper there

scoobybejesus: But they are kernel messages, so perhaps it can be done. Not sure.

has anybody tried a yubikey *security* key (not the yubikey 5 series) with openssh?

they're 1/3 of the price of the fancier ones and I need to get some for the team

AFAICT only U2F support is needed according to openssh.com/txt/release-8.2 and developers.yubico.com/SSH/Securing_SSH_with_FIDO2.html

Title: Securing SSH with FIDO2

got 14 running now, all smooth. great release team!!

dch: i got 3 yubikeys here, and don't know which of them qualify for use with that…

meena: what sort of keys? I have 5 nfc, work great with ssh, but these security keys are 1/2 the $$

and require openssh >= 8.2 which these days is fine for me

dch: i got 2 5C Nanos, and one YubiKey NEO

anyway, bed time, too tired for work-work.