i was hoping for the FreeBSD 14.1 torrents

darwin: that would be nice

I like torrents, and like to stay away from anything.0 releases

i always upgrade to the latest release. I haven't found any ending in zero any worse

trying to upgrade one FreeBSD 14 to 14.1 server, it keeps saying there's ld-elf.so.1 errors, when I don't think I ever installed Linux compatibility

ld-elf.so.1 is the FreeBSD dynamic linker. It has nothing to do with the Linuxulator.

hey i found out freebsd compiles with the c++ compiler, but last time it froze up on boot.. anyone want to flesh this out and get c++ in the freebsd kenrel+userspace?

if we do c++ in the freebsd kernel/usespace you can do some crazy things, like inheritence and encapsulation, instead of a linear system of programming, a terminal application can inherit all properties of a few classes. and theres an stl for queues/vectors/lists

i couldn't edit the new sshd_config file and now need to find the new one

how can I reinstall the linker then?

so far my conversion from truenas core plugin to jail is failing miserably

truenas appears to have set a bunch of acls on the zfs mount and i haven't found the magical incatation to undo them

i'm stuck in a loop editing my old and new sshd_config... wasn't explained what 'merge markers' are or how to resolve this...

sounds like your upgrade failed somewhere

this is a different upgrade with the merge markers

how do I fix both?

i just reinstalled

the one that had the upgrade error (still don't know how to fix sshd_config on the other)

since I could only reinstall with FreeBSD 12.2, how would I upgrade that to 14.1... do I have to upgrade to 13.0, 13.1, 13.2, 14.0, 14.1 in that order?

you can probably go straight to 14.1

but it'll be lots of merge and vi work

ok

why not install 14.1 direct?

not available yet at that virtual private server (VPS) company

as an aside, this is re-confirming my policy of waiting to -p1 for upgrades

i opened a ticket please update to supported releases

i can't merge yet

don't know how

the merge dumps you into vi

with the diff output

so you have to choose which version of each conflicting line you want

i can use vi but don't understand how it organizes the files

i have a few FreeBD 14 PCs, now upgrading to 14.1. Turns out some have a large number (50 to 100) of programs/softwares installed from ports, even though I don't recall installing most/any these from ports, and I know most/all are also packages. Is there a way to get a list, uninstall them all as ports, then reinstall as regular packages?

did you use portmaster or some ports mgt tool?

don't recall

maybe it's just a few things and dependencies that didn't used to be packages years ago. Normally I use pkg

does "pkg info" show any of the ports?

i don't have access to a machine with just ports installed

yes, it does

plus regular packages I think

i think i'm going to have to setup a new nas server using real fbsd and migrate from truenas core. migrating in place should work since everything is in zfs, but it seems risky

try "pkg upgrade" then?

i already did that but apparently the ports remained

i got a message stuff was installed from ports

some of it's common stuff like curl, xfce, maybe was ports longer ago or I needed newer version, but not ow

'now'

you could uinstall the port, then install via pkg

also update to weekly pkg builds instead of quarterly

s/weekly/latest as fast as the builds happen/

isn't that standard except on NetBSD?

weekly?

freebsd defaults to quarterly pkg releases

okay; how would I switch and is there any potential problem doing so?

Title: Chapter 4. Installing Applications: Packages and Ports | FreeBSD Documentation Portal

it depends how stable you like your systems

i've run latest for decade in production without any issues

14-1 is out :)

-sh: cannot create /usr/local/etc/pkg/repos/FreeBSD.conf: No such file or directory

oh, I have to make it

actually I'm having to upgrade from 12.2 to 13.0, 13.1, 13.2, 14.0, 14.1--you can't skip steps

you can sometimes, but it's probably better not to if you aren't sure. upgrading from 13.0 straight to 14.0 is broken, for example

You can typically upgrade from 1.0 straight to 14.1 in 1 shot by just formatting the whole drive and installing from scratch.

lol

I came here to ask the same, 13.2-Release-p0 is better upgraded to 14.0 first right?

And yes I'm a bit behind

I'll install whatever 13 latest option first

13.2-p11 it is

i don't know what p means

like p0, p11, etc.

Oh it's the patch level of each release

If you run freebsd-version you will see it

i use nntp:comp.unix.freebsd.*

wildeboskat: you should always upgrade to the latest major release first, then to the later major+1 release

so if you're running 13.2 you should do 13.2 -> 13.3 -> 14.0, when 14.1 is out you should do 13.2 -> 13.3 -> 14.1

Oh there is a 13.3 too?

Oops

So basically I just follow every step

14.1 update took 17 mins :/

anyways it works \o/

My first attempt at upgrading from 13 to 14 was a big disaster, a few months ago

It wouldn't even start anything

So I rolled back ZFS and I haven't tried it since

I'll try it again now that 14.1 is out :3

I heard there was a bug also around release time

wildeboskat: what didn't work?

you had to make sure that freebsd-update is up to date

Is there a solar power wifi camera that can record 24/7?

What are my options?

solar generator, battery pack, and low-power camera?

Title: Amazon.com : SOLIOM Solar Security Cameras Wireless Outdoor WiFi 2.4GHz [24/7 Record] with 20W Solar Panel, 20000mAh Battery,360°Pan Tilt, Spotlight Color Night Vision,2-Way Talk, Motion Detection,IP65 SL800-WIFI : Electronics

Y&dib_tag=se&keywords=outdoor+live+stream+24%2F7+camera&qid=1717508689&sprefix=24%2F7+camera+live+%2Caps%2C275&sr=8-4

it hink you forgot a few trackers at the end

yeah

need to add them

I went witha reolink

trackmix

looks like i will be walking down to the basement to manually power up the box after shutdown -r now didn't behave during the upgrade process

scoobybejesus: what did it do?

it apparently ignored the -r and shut down

did it definitely shut down rather than just not rebooting properly?

polarian: Why took that much?

tercaL: no clue.

patches took a good 5-6 mins to be fetched

actually, it didn't finish shutting down the box. the box is still running. it apparently is hanging

i have a pikvm hooked up to it, and it just shows no signal, but the box is still running

i'm inclined to manually power down and then manually power up again...

this has never happened with this box before (an ASRock Deskmini w/ AMD 3200G IIRC)

Any ZFS pool upgrade needed from 14.0 to 14.1?

isn't pool upgrade always optional?

manual power down and power up, and luckily i have pikvm to give me a clue

to be clear, I just did `doas freebsd-update fetch install`, then `doas freebsd-update upgrade -r 14.1-RELEASE`, then `doas freebsd-update install`, then `doas shutdown -r now`. Then it hung. Then manual power down and power up

i'll hang out a bit without doing anything in case someone says "oh, actually, try X"

upgraded from 14.0-RELEASEp6 btw

scoobybejesus: my suggestion would be to boot from 14.1 install media, and make sure the 14.1 loader is properly installed on the system you're booting (although it probably shouldn't break like this even if that is the problem)

thank you lw

(if you use UEFI, note that this means you need to copy the new loader to the EFI (MS-DOS) partition - for CSM boot i'm not sure since i haven't done that in years)

this is weird. i can type `boot` at that prompt and it boots seemingly normally

and i finished another freebsd-update install... though it didn't ask me to upgrade ports/packages.. hmmm

would be interesting to know if the loader problem continues after you did the userland config merge

it doesn't ask you to upgrade ports/pkgs for reasons

but i can add a note to the manual page?

people read the manual page?

:'(

lol

everybody reads /usr/src/UPDATING, no?

saper: i think technically you're only required to read this if you upgrade from src, freebsd-update shouldn't need it... (although it definitely wouldn't hurt)

I was joking a bit. I absolutely love that file and yes, I update mostly from source (on -CURRENT).

although that's not quite true since pkgbase updates go in UPDATING too...

There a way to search the whois database by keyword?

I refuse to acknowledge the very existence of pkgbase :(

a lot of people i really appreciate are working on pkgbase, but i do find it scary.

CrtxReavr: your query goes to the whois server. Whatever happens there, depends on that server.

CrtxReavr: probably depends on which RIR you're querying (RIPE, ARIN, ...), they seem to use different implementations / query syntax

they should provide documentation on how to search on their website

fwiw, "whois -h whois.arin.net comcast" does seem to work to search for that word

who needs a website when there is whois

whois -h whois.cymru.com ' -v 8.8.8.8'

Hi all, I just went to update a machine to latest 14-STABLE and now I'm getting 'LUA ERROR: /boot/lua/core.lua:68: attempt to concatenate a nil value (field 'lua_path').' in the bootloader and it won't boot unless I manually load /boot/kernel/kernel ; boot

oh so it's not just a one-off problem

amigan: how did you update? did you run etcupdate already?

installworld, and yes, I did etcupdate

amigan / scoobybejesus: can you show the contents of your loader.conf?

concussious: "concussious: isn't pool upgrade always optional?" <- is it?

tercaL: it should be yes, although it's probably recommended because sometimes older zpool versions are less tested

hmm, not sure what's going on here but i might spin a 14-STABLE vm later and investigate... in the mean time i'd suggested posting this on questions@ or stable@ since it's apparently a new bug

amigan / scoobybejesus ^

Unfortunately I think I am going to have to roll back this upgrade since it's my house firewall and if it reboots for any reason I'm ded.

yeah, do post to the list anyway though if you can

14.0-RELEASE has `if lua_path == nil ...` paste.debian.net/plain/1319149

lw, the second half of the email is @freebsd.org ?

scoobybejesus: freebsd-questions⊙fo (or freebsd-stable⊙fo if you're on 14-STABLE)

Title: FreeBSD Mailing lists: subscription for freebsd-questions

i will send an email to the former, thank you (i had done a quick search, but ended up here: freebsd.org/support/bugreports)

you can report a bug too but i find the mailing lists tend to be more responsive for things like this

strange this code hasn't been touched since April though cgit.freebsd.org/src/log/stand/lua?h=stable/14 maybe it's something in loader itself

Title: src - FreeBSD source tree

amigan: sounds like you've not been updating your loader binary

presumably this is UEFI

i didn't find in the release notes a mention of updating the loader binary

though i'm now wondering if that was in some prior release notes, and it is assumed that by now everyone has updated

the feature in question was added way back in 13.0

kevin will probably disagree here but imo this is under-documented and just something you need to learn to do, i.e. update loader every time you upgrade

that would explains why I cannot reproduce

oops, kyle

(i hope)

*nod* :-)

sorry :-)

we should really just have a standing part of the release notes to update bootcode

no worries

does freebsd-update tell you to do this? i remember it tells you to do one thing, but i can't remember if it's update loader or update ports or something else

presumably i need to mount the boot partition, and then copy the updated loader.conf into the appropriate spot... that rings a bell

scoobybejesus: usually the EFI (boot) partition should be mounted on /boot/efi, if it's not you might want to add it to /etc/fstab

i don't recall re: f-u

and you need to copy the loader itself (/boot/loader.efi) into the EFI boot image which is probably called bootx64.efi

you might also be using it as \efi\freebsd\loader.efi instead on modern installs

although you might also have it installed with another name i can't remember, something like freebsd.efi

man freebsd-update does not tell you to do either, I'm working on it now, any language reccomendations?

iirc the efi loader used to be in two part, as the old loaders, and starting from 14.0 it's now a single blob, that's never automatically updated

ah, it's /freebsd/loader.efi and /boot/bootx64.efi, you need to update both

I was thinking caveats section at the bottom, but I'm kinda sleepy and "don't forget to..." sounds too informal.

inside the EFI partition, that is

we try to keep both up to date because we like to use the proper vendored one to play nicely with other OS potentially installed, but retaining \efi\boot if it's freebsd in case your efibootmgr bits get fucked for some reason

from 13.0-RELEASE notes: ESP partitions should be mounted as MS-DOS filesystems as /boot/efi, and /boot/loader.efi should be copied to /boot/efi/efi/boot/bootx64.efi if the default setup is used.

scoobybejesus: that is correct, but also, you should update /boot/efi/efi/freebsd/loader.efi -- or just delete it as your firmware should load bootx64.efi by default

i don't have my efi partition mounted on /boot/efi

(these are the same file so you just copy loader.efi over both)

scoobybejesus: check 'gpart show -l', your EFI partition might be labelled something like 'efiboot0' in which case you can use this in /etc/fstab: /dev/gpt/efiboot0 /boot/efi msdosfs rw 2 2

that's not really required but it's easier to have it mounted by default rather than doing it manually every time

(this is from 14.0, i don't remember when the installer started labelling the EFI partition but you can just use the raw device name too like /dev/nda0p1 or whatever)

"When upgrading to a new FreeBSD version, don't forget to force update your packages and bootloader"?

concussious: honestly i think this should be more forceful, freebsd-update should prompt you in large capital letters to do this

i don't know how we'll handle that with pkgbase though... maybe a pkg-message for the bootloader package

when 14.0 came out, "i upgraded my zpool and now i can't boot" was basically a faq here

I agree that it needs to be like, they can't miss it

it probably should be handled automatically (like every other OS) but that's pretty hard to do without accidentally breaking things for unusual configurations

like overwriting someone's Linux bootx64.efi with the new FreeBSD would not be appreciated, i suppose

yeah, i'm mirrored, so i have an efiboot0 and efiboot1 (and gptboot0 and gptboot1). interesting, efibootmgr -v shows i'm booting from this: `nda0p1:/EFI/BOOT/BOOTX64.EFI (null)` .. it knows it's null here

scoobybejesus: i don't know why yours says (null), possibly because the filesystem isn't mounted?

normally it shows the file path

+Boot0004* UEFI OS HD(1,GPT,ffcc8ddd-0380-11ef-afad-207c14f3d8f2,0x28,0x82000)/File(\EFI\BOOT\BOOTX64.EFI)

gpt/efiboot0:/EFI/BOOT/BOOTX64.EFI /boot/efi//EFI/BOOT/BOOTX64.EFI

looking at freebsd-upgrade.sh, it already tells them they have to rebuild ports

on my 14.0-RELEASE box, i don't show file names there at all:

+Boot0007* UEFI : SPCC M.2 PCIe SSD : PART 0 : OS Bootloader PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,35-77-60-21-01-00-00-00)/HD(1,GPT,38e021d3-da4c-11ee-a3ff-1c697a08518c,0x28,0x64000)

VenHw(2d6447ef-3bc9-41a0-ac19-4d51d01b4ce6,530050004300430020004d002e0032002000500043004900650020005300530044000000)

oh you don't have a device name either, weird

idk, UEFI is black magic to me, but hopefully updating the loader on the EFI partition will fix your problem anyway

indeed :)

-rwxr-xr-x 1 root wheel 447K Dec 19 2019 BOOTx64.efi

kevans: sorry, just saw this. I am indeed using an old EFI binary, but /boot should be updated as it always is. Would simply updating the EFI binary in the ESP be sufficient?

2019 :-)

:)

amigan: yes, that's the part installworld doesn't do, copying the new loader to the ESP

Ahhh. Okay then. I just rolled back but let me try again

Does the EFI binary have the lua interpreter in it?

yes

Okay, this makes lots of sense now

well as long as you're using the Lua loader... which is the default

Yes, I should be

Though this system did use the 4th loader at one time

i'm not sure when the switch to Lua happened but it was a while ago, personally i like not having to deal with forth

12.0

coming soon: Java loader

the lua loader is massively better, but they did take away our ascii loader, which still makes me sad.

concussious: beastie_disable=YES 4eva tbh

except that kind of sucks on systems with slow EFI text consoles... my desktop takes about 15 seconds to print all the 'Loading foo.ko' messages. i guess vendors don't really test that

i sometimes am playing with things i dont understand and need the beastie menu to fix my computer

i used beastie_disable once and then i couldn't time it right to hit the key to escape it, so now I keep it set to 2

it obviously boils down to this, and now I'm good to go. Many thanks! paste.debian.net/plain/1319157

concussious: i have the opposite problem, i can't work out how to use beastie. with the normal loader i just load the working kernel and go

I love forth personally. Lua is okay. I'm sure we will indeed have a javascript loader someday, but I hope it is after my time on this rock.

lw: you would!

I don't think we'll see a javascript engine light enough to convince us to try and embed it into loader in my lifetime

i miss the days when your system firmware could just load executables from UFS and you didn't need a boot partition

kevans: there's a tiny C JS interpreter called something like "jsint" (?) that i bet you could fit into a loader

kevans: sometimes the perception is that javascript, while unsafe, is a simple language. that perception is extremely wrong.

I'm pretty sure the uefi successor will be wasm-based

to be clear i'm not suggesting anyone should actually do this. but i bet you could

lua's pretty damn slim and we still have to knock out most of the bundled libraries because we don't want to deal with it

babz: wasm is _very_ different from JS, though some bits of it are becoming a bit annoying

I already have a bangle.js 2 smartwatch that uses esprunio, a small JS interpreter written in C designed for embedded stuff. It's really not a stretch.

lw: hmm... brief glance, all I can find is 'elk' and maybe duktape?

amigan: LOADER_DEFAULT_INTERP=4th I have. Sadly, we cannot use "full power" of Forth to tinker with stuff. It is limited mostly to interacting with stuff provided by the loader

kevans: yeah i can't find it now. maybe i'm getting confused and thinking of something i used with C#

amigan: and how much % of ECMAScript does it implement? :)

elk looks promising

SmartOS has container management tools written in Javascript and node is a part of the base system. (Joyent...)

saper: do they still have the awful Solaris Java-based management tools? i guess (fortunately) those were never open sourced

"Espruino isn't 100% of any JavaScript spec (for instance no Regular Expressions at the moment), but it's pretty much ES5, with some ES6 features (arrow functions, template strings, binary literals, forEach/etc on ArrayBuffers) where it makes sense."

saper: at some point you'll have to maintain forth as a local patch entirely, we won't be holding onto it forever

SmartOS is pretty slick. Totally a new experience to me. Like no space to install anything, you HAVE TO build containers.

SmartOS to Solaris is a bit like TinyCoreLinux to the rest of the Linux distro world :)

i'm honestly a little surprised people do enough with loader to care if it uses Forth or Lua

^

i pretty much just set some things in loader.conf and that's it

i suspect "where it makes sense" is doing a lot of heavy lifting here, because in order to be ES-compliant you have to implement a lot of obscure and often slow functionality into your runtime which is only really helped with some extreme optimization

I mean yeah, I don't really touch it. Not like I'm writing games in it a la openfirmware

kevans: I suspect that will be the case.

dstolfa: sure, but I am certain it is enough to be serviceable as a bootloader

lw: true

amigan: maybe, but it's not something i'd call JS :P

it's a scripting language inspired by JS

my bootloader is a nostalgia thing. I have contributed to OpenFirmware few years ago. Which is a real Forth bootloader. Someone even ported it to arm64 recently.

I mean it has promises and such

saper: remember the Sun 386i? an i386 system with OpenFirmware back in the 80s

don't think it ever ran freebsd though

Guy at the museum I volunteer at has a 386i

whereas i'm fairly sure that lualoader is pretty much lua, just without all the extra bits. ES requires you to be able to override a bunch of "internal" things which complicates things quite a bit

He now has "fewer than 300 suns"

dstolfa: Lua is probably full fat, but FICL was not totally ANSI forth afair

lualoader is more or less lua, modulo maybe 60-70% of the standard library and floating point bits removed

lw: never hat a pleasure, it was always sun4-something for me (starting SPARCserver 10 I think). Solaris 2.5 for Intel was installed on my startup main server in 1996, the only sane OS it could run. And I bought Solaris 8 for Intel CDs when they announced it will be the last one

We have a wollemi at the museum, but something is fux0red with it and it won't boot. Service processor runs though.

Sun's very last hardware project, killed by the borg after acquisition. ricomputermuseum.org/collections-ga…ystems-wollemi-ultrasparc-prototype

Title: Sun Microsystems Wollemi UltraSPARC Prototype

Basically a T2 blade chopped in half, sandwiched around the ilom and stuffed in a low profile case made of aluminum and tempered glass

amigan: is power supply difficult to fix?

saper: the PSU works, we think it is one of the buck converter modules not asserting PWR_OK to the CPUs

huh, i thought they'd given up on SPARC desktops after the Ultra 20

Either that or when it got repaired last time by the donor, it lost a configuration page in flash or something

lw: this was semi-skunkworks

ah

oh wow a desktop with a T2. that's definitely a bit weird

It's extremely weird

Woot, new EFI binary fixed it. Though I still have the beastie menu...

echo beastie_disable=YES >>/boot/loader.conf

No, I want the beastie menu :)

oh, i thought you were complaining about that :-)

Nah, thought someone had mentioned the lualoader 86'd it

oh no

Excellent

i think beastie will be around forever

Good

Okay, so, I guess I can proceed with the next amd64 box on the list. Pets, not cattle, here.

amigan: the lua loader made beastie boot graphical, and 86ed the ascii version on efi. still works on bios.

I was on a serial console

serial still has the ascii beastie

Ah, ok

honestly given the state of the world right now i'm just glad the new graphical beastie wasn't wearing a sexy dress or something

Lmao

lol

beastie changed to meru

loader_logo="meru"

So, since BIOS machines load lua interpreter as stage 2 (I think?), I shouldn't have to update bootblocks on this machine, yes?

I think if update bootblocks, then all of them...

Well it chainloads, and /boot/loader is a regular file. I don't think boot[12] have changed

Yay, it worked.

:-)

Not sure why I am surprised, maybe because this is the first failed upgrade I've had in 7 years, lol

Actually I can't remember an upgrade since 2003 where I was dumped back at a loader prompt

probably imp's fault, he likes to work on loader

Oh well. At least you can still boot. Unlike that time in 2003 when I did installworld before installkernel going from 5.1->5.2. That was a sad day.

i upgraded to 5.0-CURRENT once and wow was that a bad idea

Hahaha, I bet

on a good day it'd stay up for about 15 minutes before crashing with a witness panic

5.1 was the first version I ever ran, and I was amazed at how much faster it was than linux 2.4 on shittier hardware.

This was before ULE, too. Still superior for interactive use, it seemed.

some people apparently think 4BSD is better than ULE even today

because it it

This is admittedly a stupid question, but has anyone ever experienced or seen a story of trying to repurpose an android device into booting FreeBSD? I realize why one would enter a world of pain if attempting it, but am still curious. A web search gave me nothing.

Box 2. After the upgrade, install, reboot, and now second install, it's hanging... any ideas? paste.debian.net/plain/1319169

wow.. okay.. after another ^+t at 3100 seconds, and another 30 seconds, and it finished...

in other words, false alarm, it seems

scoobybejesus: ^+t?

control+t... should that be ^t, i guess?

ah

CNTL/T as we used to call it, but yes, i think ^T would be the normal Unix notation

strange it took an hour until you typed that though

i know freebsd-update is pretty slow but it's not usually quite that slow

When I went to recreate my poudriere jail for 14.1, it actually fetched the rust package rather than building it. What a glorious day. Previously, it would insist on building it every time even though I had no options set.

lw, amigan: how many computers do you each have to update?

ZedHedTed: 3 metal, 2 vm

ZedHedTed: me, 3 physical computers, several more VMs

and many more jails but i have a script for that

Yeah, a couple jails here too

Wait 3 metal, 3 vm lolol

i run 15.0 everywhere though so my usual workflow is build a new release, build new ports, run 'pkg upgrade' everywhere, done

(i have my own local fork of main for this)

Yeah, half of those are -RELEASE, half of them are STABLE that I build here with a few of my own patches that I wish would be merged

amigan: have you tried submitting your patches on github? imp@ is quite receptive

lw: I haven't, no

well ymmv but i've a good experience getting patches committed that way

the only local patch i'm still running is for ifconfig to print addresses in cidr format...

I'll try it. Some of them are not mine per se, but I found them in bugzilla and cannot live without them. Like a patch that has rtadvd deprecate routes when it is shutting down.

Err addresses, not routes

Oh, and another that disables REMOTEHOST in tcsh so it doesn't try to do a damn reverse DNS every time I start a shell

(when you use tmux, the remote address is the tmux pane ID, which obviously is not a valid IP, so it just sits there waiting for a recursive NXDOMAIN)

doesn't rtadvd do that already? i found it annoying since it does that when you just want it to restart

i guess you're supposed to use radvctl reload there

i did get an rtadvd patch committed recently to add PREF64 suppose but tbh i just use Bird now

Nope. Super annoying because my ISP gives me a new prefix every time

My patch has it as a config option

Some stuff on my network will continue selecting the old address even after getting a new prefix if it isn't deprecated

ah wait you do dynamic DHCPv6 with FreeBSD? i don't think this is even supported in the base system

that must be annoying to set up

DHCPv6-PD from ISP, then SLAAC for the ISP prefix, and DHCPv6 for my private range

With this patch I have no further complaints, but I do wish I could use DHCPv6 for all of it

ugh DHCP-PD is awful

just give a fricking static prefix to your customers

Yeah, but I was just happy verizon finally deployed v6

yeah i guess it's better than nothing

Waited for years. I still use he.net tunnelbroker to have a static IP for services

Lots of fun MTU and policy based routing shit with pf for that

i bet ISPs do this on purpose to force people onto business plans tbh

I wouldn't be surprised

But vz is very generous with how sticky the v4 IP is. You really have to try to get a new one.

And freebsd dhclient doesn't have a way to send DHCPRELEASE, which is always fun when you need a new one

nice

asked yesterday but I think it fell to the backlog, OpenBSD promotes separate partitioning for the file hiarachy, but FreeBSD just does the simple 3 partitions (efi/boot swap root), is there any FreeBSD guide on separate partitions (its only touched on in the handbook)

for example, this is OpenBSD's recommandations: openbsdhandbook.com/disk_operations

Title: Disk Operations | OpenBSD Handbook

polarian: by "separate partitions" do you mean like a separate /usr? there's really no point in doing this nowadays. FreeBSD tends towards ZFS instead

ZFS changes this how?

well, with ZFS your entire disk is one pool and you can create whatever filesystems you want

also data pool is not the boot, should the boot be its own zfs pool, or just use ufs?

it's the opposite of separate /usr which only is a thing because of ancient PDP-11 systems where your root disk was literally too small to hold /usr

since we don't live in the 1980s anyway, there's no point to do that

lw: well there is a few benefits, for example /var/log can eat tons of storage and having a separate partition prevents log spawling

polarian: sure so you can put /var/log on a separate zfs dataset if you want

I know little about zfs

anyways boot disk, benefits of using zfs? or just ufs it?

the only downside of ufs is no integrity checking

but all data will be in a zfs pool

polarian: ZFS lets you create filesystems for whatever you want: le-fay.org/tmp/zfs.txt

i would say never use UFS unless you have a tiny system (under 2GB of RAM)

and if you have such tiny system, there's no point to separate /usr. this is old nonsense, forget about it

lw: ah you mean just if you want separate mountpoints it can be done dynamically... unlike ufs

yes, but for example you said "/var/log can eat tons of storage" - well with zfs you can easily see how much space it uses and even set a quota on it if you want

the only *extremely* niche case where i might suppose separate /usr is NFS-boot systems where each system has its own root filesystem and mounts a shared /usr

but honestly, who does that nowadays? this is like 1990s SunOS stuff

if i was going to do NFS-boot nowdays i'd just give each system its own dedicated root filesystem

it's not like we're going to run out of disk space installing freebsd

lol

and to be clear, i love "1990s SunOS stuff" in general but the only reason we did this back then is that disks were so small

the same reason back in the 1980s we had separate /usr because disks were so small

nowdays? it's pointless, don't do it.

it's the ease of managing one environment rather than one per host too

|cos|: yeah but you can't even do that because FreeBSD doesn't distinguish / and /usr in its management tools

if you upgrade your diskless clients' / you have to upgrade their /usr too

ZFS is so good that I am having a panic attack when I am doing sysadmin on a system without it.

i really hope we can just get rid of /usr at some point ("usrpurge") but this is going to require a lot of bikeshedding

meena is with me here though

With zfs datasets being so cheap and easy I don't see any motivation to not have those datasets present. And /usr is just a template on FreeBSD. It's empty. It's just there to hold attributes.

Run "zfs list /usr" and it is shown that it is actually the / dataset. There is no mounted /usr on a zfs system normally. Not unless someone has gone out of their way to mount it.

This is needed to enable Boot Environments. Which I totally am in love with too.

rwp: yeah and this sucks becauses it confuses the heck out of people

"why does /usr exist when it's not mounted?"

It confuses the heck out of people.

It exists to be inherited from for the lower down datasets. Like /usr/ports

i know that and you know that, but it's not really obvious to new users who aren't familiar with zfs

I agree. It confuses the head out of people.

So... Could we move /usr/ports and /usr/src so that they are not root build constructs? If those were not there then there would literally be no need for /usr either and all three could be gone.

well the difficult part is /usr/bin and /usr/share

That would still leave /var which is just like /usr and there are many things under /var those seem to be looked into less by newcomers and so less confusion.

i've been planning to submit a patch with a build knob that makes everything in /usr be installed to / instead

which would at least demonstrate the feasability of this solution

/usr/bin and /usr/share are both in the / dataset. So nothing need to be done there.

i disagree, everything in /usr/bin should be installed to /bin and everything in /usr/share should be installed to /share

that's what i mean by usrpurge

I don't think we should move /usr/ports and /usr/src into / (but I know /usr/obj is already there)

we should, but it's complicated ofc... my /src is a zfs dataset with a lot of subdirs like /src/freebsd/releng/14.1

Ah... It would make more sense to move /usr/bin into /bin than the UserMerge folks are doing with their move of /bin into /usr/bin which is just the opposite of a reasonable direction.

yeah "usrmerge" is a Linux thing which i'm pretty sure no one is pushing on FreeBSD

usrmerge bad, usrpurge good

I hope no one is moving that direction with *BSD but insanity seems to be a contagion.

i have not seen any FreeBSD people advocating this but if i do i will argue strenuously against it

not that anyone really cares what i think but eh

i'm hoping i can prempt this sort of thing with the usrpurge patch

that would mean people can build and test a /usr-less system without breaking normal users

I don't know if it is still a deal or not but at one time if there were network mounts directly in / such as /nas42 or something, and the network drive was not available such as the network being offline or something then it gummed up the system due to the not responding /nas42 mount point. Imagine an "ls -l /" for example but lots of things stat around excessively.

And so it has been a good idea for a long time that we put things like network mounts at least one directory below / such as in /net/ or something to avoid those types of problems.