Macer, Wrong channel. :-}

rwp: Yeah. I was racking my brain wondering what that had to do with anything. Figured I'd just let ignore it and let it slide.

lol

i'm trying to bootstrap debian

for linux jails using fbsd

There are a bunch of us that have feet in various camps. It's easy to cross-pollinate.

I have avoided spending time on the wiki.freebsd.org/LinuxJails process because as it is described there can be only one wiki.freebsd.org/Linuxulator running at a time. That just felt too restrictive to spend a lot of time on it.

If multiple of those can run at a time on a host then that would be very interesting to me. I have been a pretty hard core Debian person, until, well, until Debian took that left turn. Now I am a pretty hard core Devuan person. In addition to being a pretty hard core FreeBSD person. If I could run multiple LinuxJails on a host that would be very interesting to me.

yeah that's a fair point. i just thought it was nice to have options

but i guess on the freebsd server i'll stick with native jails.

otherwise what's the point?

there's always bhyve if i desperately need linux on it

which is probably a much better option than compat tomfoolery

If there is a native FreeBSD way then that is always going to be best. But sometimes one gets squeezed needing to run a Linux only something and then it is good to have options.

I have converted most of my infrastructure from linux to FreeBSD and the improved stability has been great. FreeBSD has been a breath of fresh air.

Here is a datapoint. Ubuntu in 2024 released a security patch Linux kernel needing a reboot every two weeks over the entire year. That feels like an excessive number of kernel security vulnerabilities!

ouch

so you're saying that people had to reboot servers every two weeks?

i get mad when i have to reboot after a year lol

Macer: if you want a stupid amount of uptime. You should be on 14.2-RELEASE. It very seldom gets updates to kernel or userland that need a restart

i am

@@@ INTEL GPU OFFLOAD NOTES @@2

This feature was removed in version 1.32.2.7002

my xeon doesn't even have quicksync .. but still though. what's up with that?

Macer, If those people were following the rule that they apply all distro provided security patches then yes they would need to reboot at least every two weeks for just the kernel. But in reality it is more often than every two weeks because any update to systemd, udev, or dbus also requires a reboot to put into effect.

On FreeBSD RELEASE you can count on a quarterly roll-up of everything that is outstanding in the last quarter and I plan on rebooting them then whether they need it or not.

alright

have a plex jail running with rclone mounting the media in the jail :)

that's two down. about 10 more to go.

wow i honestly didn't realized how spoiled i was with my little nvidia P400 for the offloading. this thing only has 1 pcie slot on its riser though and i put a 10gbit nic in it :(

Hi there

Can I upgrade straight Freebsd 13.1-> 13.5 ?

Yes

This is critical due to box is located in a place which is very far away

thanks

You don't need to do a touch-and-go for each version number

yes but if something is going wrong ...

%s/is going/will go horribly/

nerozero: i highly recommend using bectl(8) with the 'activate -t' flag in that configuration, although it won't catch all possible issues. it does work better if you at least have someone on site to power cycle

ivy, i had a lot of issues with bectl i'm using zfs snapshot -R zpool...

then send it to external storage

bectl helped me only once, and failed 4 times

well, the point of -t is it can automatically reboot into the previous BE if the boot fails for some reason

if you don't want to use bectl, nextbook -k can do something similar for just the kernel

a month ago I lost access to zfs pool completely, no errors with pools, zfs just never imports pool

2 days with all possible tricks - zfs failed to mount pools

by sending entire pool to external storage at least you have a chance to recover everything

never heard about `nextbook`

s/nextbook/nextboot

ah ok

hey ivy could you bump bugs.freebsd.org/bugzilla/show_bug.cgi?id=285833 on Discord? you said the documentation team all use Discord and thats how to get things seen... this has been stale for a few months...

almost 2 months... about 1.5 months

afaik now it just needs merging nothing else...

Thanks in advance :)

hi all

nerozero: no ipmi?

Macer - a small chinisium celeron box hanged under the roof in a different town ...

thanks for reply

ah ok.

2x ssd zfs root mirror

I have a zfs pool that doesn't want to load at boot time. I have to import it again after every boot. Any suggestions on how to resolve this problem?

how do you import it?

just: zpool import storage

tsoome: this pool was exported from a prior FreeBSD 14.2-RELEASE install and I did the import on my 15-CURRENT install

zpool get cachefile poolname ?

I got it resolved now. had to remove the /boot/zfs/zpool.cache file and have it re-created with zpool set cachefile=/boot/zfs/zpool.cache storage

the "" (empty string) uses the default location.

i'm setting up vm-bhyve and i am wondering. i already have bridge0 for jails. so for the steps with the switch can i just use the same bridge?

7. vm switch create public

8. vm switch add public em0

so that would just be vm switch create public ; vm switch add public bridge0? or is this something i'm not supposed to do?

Lines 7-8 Create a virtual switch called 'public' and attach your network interface to it. Replace em0 with whatever interface connects your machine to the network.

i guess i'll roll the dice lol

/usr/local/sbin/vm: ERROR: failed to add member bridge0 to the virtual switch public

or not

hm. i guess connecting it to lagg0 is a no go either

am i going backwards with this? should the virtual switch be added to the bridge and not the other way around?

manual allows you to attach

guests to a bridge that you have created and configured manually.

ah ok. i see. so i had to -t manual -b bridge0 public

NAME TYPE IFACE ADDRESS PRIVATE MTU VLAN PORTS

public manual bridge0 n/a no n/a n/a n/a

sweet

I am seeing something in my ssh/pf setup that doesn't make sense to me

always a fun start

sshd[32814]: error: in MaxStartups throttling for 2d22h34m, 166 connections dropped

lots of these

sshd sshd-sessi 56042 4 tcp4 94.136.7.161:2200 45.135.232.177:31562

like, *lots* - right now 94 of these open in some state

the AI is learning!

yes, so I got sick a couple weeks ago from this IP range

block log on $extl_if from <blocklist> to any

and `45.0.0.0/8` is in my pf blocklist

so ... how is that even getting to ssh in the first place

are they logging?

errr, is the log part of the rule working?

make that block log quick, and lets see what I'm seeing

00:00:00.000000 rule 1/0(match): block in on ng0: (tos 0x0, ttl 54, id 6349, offset 0, flags [DF], proto TCP (6), length 52)

45.135.232.177.24212 > 94.136.7.161.2200: Flags [S], cksum 0x2bf7 (correct), seq 1170109560, win 42340, options [mss 1440,nop,nop,sackOK,nop,wscale 12], length 0

we didn't need to wait long did we

I think this is an own goal

that was a block log, but I have a `pass in quick ... port ssh` later on

ah yeah

blocklistd is supposed to handle repeat offenders already

which clearly also isn't happening

and I'm still seeing these dangling sockets

lets reboot the router first

tcp4 0 52 94.136.7.161.2200 45.135.232.177.52582 FIN_WAIT_1

50x more of these since I restarted pf

45. being the network that shouldnt get past pf

dch: do you have appropriate blacklistd rule for port 2200 ?

mzar: sort of, I have a bunch of WIP updates for blocklistd to handle more cases

anyway, pf bloch hammer now works, I just needed `quick` in my rule and a reboot

rule 'anchor "blacklistd/*"' should be sufficient

ls doesn't have a flag to show the path of a file you ls?

Macer: use `realpath` instead of `ls`?

ah ok. thanks. i just made an alias to call that lsd

i'm kind of surprised that's not built into ls tbh

in case you need to copy/paste a complete path/file into a conf or something

Macer, It's not like I don't myself use ls in scripts but the general scripting wisdom is that ls is not designed for use in scripts and one should use other commands such as realpath and stat and such instead. (stat is non-portable)

You might be wanting "readlink -f $filename" instead.

i just need something that is quick and easy to get a full path of something in case i need to put it in a config

ir crontab

*or

Macer: Yeah. That's `realpath`

just spent the better part of 10 minutes trying to sort out why an lftp script i made wasn't showing what lftp was doing and realized i forgot the ! in the shebang. :/

Both realpath and readlink -f have had a non-simple history. On FreeBSD both are about the same. But portability is troubled with those two commands. At this moment I use and would recommend "readlink -f" for best portable use.

alias lsd="readlink -f" done lol

If you use reboot, please note it's not doing the same thing as shutdown. You may want shutdown not reboot, depending on whether or not you want to run the rc.d scripts - bsd.network/web/@dvl/114568386872281585

dvl, What I am missing? That link does not mention rbooting.

Specifically for everyone else, the simple answer should be "shutdown -r now" when you want to reboot as that will do the graceful shutdown and reboot. This is important if the system runs a database server!

rwp: Well, it's bsd.network/web/@dvl/114576110897957530, sorry for the wrong url.

dvl, Recently there was a discussion about this: lists.freebsd.org/archives/freebsd-arch/2025-February/000864.html

rwp: Today I watched a YouTube video which used reboot - so I wanted to tell them.

It is wrong of us to say reboot so casually when we really mean "shutdown -r now". This is very important on database servers and other similar systems with data in memory that needs to be written to storage and flushed all of the way through.

sometimes reboot is a cool feature.

But for most random laptop users without in-memory data floating around using reboot will probably be okay. Maybe. Probably. If you want to chance it. It's no worse than a power drop.

I'm honestly surprised "reboot" isn't just an alias for "shutdown -r now".

I'm trying to remember WHY I know that they are different. manual pages? handbook? experience? bad luck?

They just perform differently. I'd chalk it up to bad luck. One would think they'd have just gotten rid of "reboot" by now, though. I've never *HAD* to use it for anything. I'd much rather use shutdown.

Even on my heavy-lifting database servers it only takes an additional, I dunno, 3 seconds or so to shutdown?

It's a little longer than that but how often do you reboot? Not often enough to make me want to shortcut the safe process.

It's also not simply a matter of saying, "rm -f reboot; ln -s shutdown reboot" either because then what do you do about "reboot -r" which is super cool functionality and needs to continue.

rwp: If it is longer, it isn't much. And, yep, what's a few extra seconds to make sure data is properly retained? For me, unnoticeable.

I wouldn't ever think about rm'ing "reboot". But, in the past when I shared BSD systems with others that used "reboot", I'd simply alias it to "shutdown -r now" just to be safe.

Never used "reboot -r", but looking at the man page that is a pretty cool feature.

I once used reboot -r to change a FreeBSD system from UFS to ZFS in place!

rwp: That's a pretty handy tool to have for that.

i didn't even know they were even different

i always assumed reboot was just something that called shutdown -r now

and i didn't know the -r was special either. you're saying it doesn't flush ram when using reboot?

okay looking at my journals, looks like I learned about it when I added a log message into rc.shutdown to "calculate" reboot time and I was using reboot, so I discovered the difference, according to my journal this was 2017, so 2 years into FreeBSD :D

i wonder what happened there. maybe two things doing two separate things that seem like they're the same but they're not?

ie: two apps from yesteryear that never really merged into one ring to control them all?

Macer: Pretty much, yes.

so i am connected to a shell using mosh. mouse works .. but if i ssh from there elsewhere the mouse doesn't get reported

i guess sort of like a passthrough? is there some option that needs to be changed for something like that or is it not really possible?

oh wait

ah yeah. so it works with the linux server i'm doing through tmux -> ssh but not with fbsd

that has to be an ssh thing

As far as I know shutdown calls the shutdown scripts and then calls reboot. Though of course shutdown could do the reboot action itself. I don't know. I haven't looked at that level of detail.

Macer, What terminal emulator are you using? It's doing the mouse proxy. Doing ssh again does not forward the mouse further. Because ssh does not proxy mouse actions. There could probably be a program which would do it on a side channel though.

Personally I am one of the old-school folks who hate that mouse proxy action and always set "XTerm*allowMouseOps:false" to disable it entirely. Because it breaks copy-paste for me. I would rather have copy-paste working normally than to have mouse ops that I don't want passed through.

oh so linux is doing some tomfoolery to get that working?

i'm doing tmux/ssh -> fbsd jail -> ssh -> fbsd server

tmux/ssh -> fbsd jail -> ssh -> proxmox / debian (mouse works)

freebsd doesn't ... so i can't click in htop as an example

Limiting closed port RST response from 1369 to 210 packets/sec

and what is that?

i wonder if that's why i can't get debian to bootstrap.. is that something from pf?

i don't even understand how it is possible for that to get scanned

it's behind my opnsense fw

there is no way for any inbound traffic to hit it

Macer, When you say linux I must translate that to terminal-emulator such as XTerm and others. It's not a linux thing and FreeBSD is exactly the same. It's an X terminal emulator thing.

Macer, I see those "Limiting closed port RST response from..." messages in my logs routinely on my private networks too and I don't know exactly what they are about. It's probably a sideeffect of something normal that hasn't been chased down yet.

However it will have nothing to do with bootstrapping a Debian VM, or at least I can't believe it would have anything to do with it.

pcregrep: line 1012399 of file /usr/local/bastille/tmp/var/lib/apt/lists/https:__deb.debian.org_debian_dists…bookworm_main_binary-amd64_Packages is too long for the internal buffer

pcregrep: check the --buffer-size option

i get that when trying to bootstrap debian with debootstrap and have no idea what's causing that. i tried a few different things like using an alias on pcregrep to increase the buffer size

or checking the debootstrap script to see if i can add that flag there but i couldn't figure it out

i guess pcregrep is perl based but i don't see where you'd change perl buffer settings anywhere

ah well i think i've given this the good college try