Because any time a mount point is made then anything that was in the directory used to mount it will be hidden by the new thing mounted there.

But I wasn't quite sure in my quick reading if that is what was happening to your case or not. Would make sense if that is what is happening.

Normally I make a dataset first and then I unpack the base.txz into it second. Then I make customizations to it third.

at first i did that ya, then the 2nd attempt was to set up the zfs commands then mv the files into the dataset dirs, but that didn't work either

seems it's because during install it's all in /mnt/* so i gotta prepend that

zpool history sounds awesome i'm gonna try that! tyvm

zpool history is really cool

why isn't my jail started automatically? after start up i verify service jail start testjail runs successfully so i know it's not broken. rc.conf has jail_enable="YES" and jail_parallel_start="YES"

and /etc/jail.conf has .include "/etc/jail.conf.d/*.conf";

alepzi: does dmesg say anything? when my machine starts up.. it has entries stating the jail is operational

not seeing anything

can you star the jails manually at least?

start

ya

that is odd, my /etc/rc.conf has the same two entries you posted

maybe a typo?

jail_enable="YES"

jail_parallel_start="YES"

and i have the same include, which picks up different jails

hm same spelling. and when server starts up i even see it say "starting jails"

"Starting jails:."

i type service jail stop, and it says "Stopping jails: testjail." (i started it manually) but then i type service jail start and it says "Starting jails:."

and jls doesn't show testjail there

but service jail start testjail does start it

is there a flag i need to add to the testjail config to get it to be included in the default startup set?

so when it is running jls does not show it

ya it does

i did not do anything special.. created <jailname>.conf in /etc/jail.conf.d

and it just works

damn

that does not help you

sad boi hours

can I backup /usr in single user mode with something like dd if=/dev/da0p6 of=/mnt/usr.bak ?

does that copy everything ?

last1: If your /usr is da0p6 then that'd get it.

last1: Verify by mounting it somewhere.

slowly

last1: see mdconfig(8) for mounting it to test

ok

I need to grow /var and I've read that I can only the last slice

which is usr, so I'm backing that up first, deleting it, growing var, then re-adding /usr back

does that sound right ?

last1: ZFS might make life more pleasant for you.

last1: Is it a good procedure? I assume you'd be doing it from rescue media, because no /usr might make life hard for the system.

from single user mode

last1: I don't know - maybe there's enough in /rescue to do it all. But even single user mounts up /usr

last1: I think you might have better luck not using dd for this, thinking about it.

You're effectively skrinking /usr so you won't be able to write out the whole dd'd file anyway.

You might want dump/restore or tar or something instead.

Which is to say, only gather the useful bits, and don't copy all the unused space too.

I'm not shrinking dd

err, shrinking /usr

usr will remain the same size

this is a vm so it's easy to add space, restore from backup, etc

last1: Oh. Oh, I see. You're embiggening the whole disk, then expanding var a bit, then laying usr back down.

yes

growfs failed

yay

make_dev_p() failed

whatever that means

last1: did you expand the partition first?

yes, that worked alright

and you see the new values. hrm

apparently it's not fatal

I'll see if it boots after I'm done copying /usr back

ah, so it worked, just noisily

might still be worth opening a bug for the error

maybe snag a picture or screenshot

yep, worked after all

good good

And with that, past time for me to become a pumpkin. o/

Anyone here running FreeBSD in a DigitalOcean droplet? I recently upgraded from 14.0-RELEASE-p5 to -p6 and after reboot the ip address config is just gone. (To be frank, I'm not sure if the root problem is the upgrade or the reboot)

I made no big effort in trying to fix it myself and contacted the support instead. This was a week ago, and all they have come up with is "try setting ifconfig_vtnet0 in rc.conf", but the rc.conf is rewritten on boot by some script from DigitalOcean themselves.

Today they apparently gave up and "would recommend that you check any open-source/developer forums such as Stackoverflow"..

During reboot, this message passes by, I suspect it might be part of the issue.

DigitalOcean: adding public IPv4 configuration

ld-elf.so.1: Shared object "libonig.so.5" not found, required by "jq"

why would rc.conf be rewritten? does making it readonly prevent it from being rewritten?

partial update? libonig.so.5 should be provided by devel/oniguruma

this is what rc.confr looks like

Title: PrivateBin

hm, if you disable that digitaloceanpre? and can you share the service file for that?

ah, no you want to disable digitalocean, but why do they even do that like this?

They don't anymore, they dropped support for new FreeBSD droplets during 2022. This is an old droplet.

I had a look at the servicefile, but since i only have console access I cannot copy as text :/

pb () { curl --form "file=@${1:--}" 0x0.st }

nice tip, but there are lots of characters I cannot type because of weird keyboard settings in console. but I just now got the network running with manual commands :)

Title: PrivateBin

with "like this" I meant editing rc.conf, why not config network via normal ways to config networks or if they want to do it via some file they drop into your vm, then how about using that directly instead of rewriting some config file, that is currently loaded, do they even report back propperly that they changed /etc/rc.conf (iirc rc has a way for that)

I got that. And i don't have an answer. If I'd just try setting ifconfig and route add default manually, could I do this in rc.conf?

disable the digitalocean service and set those ifconfig_* lines yourself (how often do they change the network config?)

that's a good point, thank you. It really should work and it sticks in rc.conf, but it doesn't seem to apply to the nic somehow.. let me try some more

I don't understand why, but running it as commands (ifconfig vtnet0 inet 46..) instead of rc.conf-statements (ifconfig_vtnet0="inet 46) does actually work. Which makes me happy :)

thanks nimaje for your help, this feels as solved as it could be. Now, let's take a step back and ask the question, is it time to ditch DigitalOcean? I'm very much inclined to say yes.

IIRC they don't support FreeBSD anymore unless you signed up in the past so I'd personally look somewhere else.

hello, any idea if FreeBSD supports the HPE Gen11 Smart Array Controller?

mage: As a starting point, please check this: github.com/bsdhw I also would suggest to run live-system and execute hardware probe for validations. In case you have the hardware available for use/testing.

Title: bsdhw (BSD Hardware Project) · GitHub

anyone have tailscale with mullvad running in a jail? i can get tailscale working just fine, but the mullvad exit nodes i've not figured out yet

when my machine starts it says Starting jails:., but the jail in /etc/jail.conf.d/testjail.conf doesn't get started (jls) until i manually type service jail start testjail. what i'm doing wrong pls?

alepzi, do you have jail_list="yourjail" in /etc/rc.conf?

no!!!

that's gotta be it

nice. for details, man rc.conf, and search for jail.

DONE

i'll read all of those tyvm!!

:) no problem

moving per jail config into jail config files and out of rc was good design decision

alepzi: your jail stuff was in rc.conf? i may of assumed in correctly.. i thought you had heah jail in itrs own conf

no

was just reading the man page note

jail_list was what i was missing

ah, i never knew you could do that way, i jsut individual jail.conf per jail and just always did that way

me too

but they weren't auto starting

weird that yours do tho

you running 13.x or what voy4g3r2?

alepzi: 14

wonder if it's changed to no longer need jail_list?

alepzi, If you declare jails in /etc/jail.conf then those are started automatically without being in jail_list. Pretty sure. But putting them in /etc/jail.conf.d/foo.conf (I think) requires them in jail_list. Pretty sure that is one of the odd differences between jail.conf and jail.conf.d/foo.conf files.

Meanwhile... I always use a jail_list because I will hack some jail together for something and I don't want it automatically starting.

So I think always using a jail_list to be explicit about what is started at boot time is the better way to do things.

rwp: No, they have to be in jail_list to start regardless of where they're defined.

mason, man 5 rc.conf jail_list "When left empty, all of the jail(8) instances defined in the configuration file are started."

Is that documentation incorrect? And that's the way I remember it working before using jail_list since then for the reasons I mentioned.

I am running a test now.

I just ran a test and every jail defined in my /etc/jail.conf was started automatically after I removed jail_list from my /etc/rc.conf file. (I commented out my test hacks that I did not want started.)

So... "Works for me." :-)

I should add that this system I just tested on is running 13.2-RELEASE-p11.

rwp: Hrm. Apologies, I was wrong.

lw

The real problem is that there is too much information to know all of it. It's just not possible.

That's really the best part about IRC and the mailing lists is that among then we can cover most of it. The important parts at least. :-)

And yet, every now and then you run into someone who seems like they really *do* know everything, and you wonder how many hours their days consist of..

I have said it before and will say it again. Experience and treachery will always triumph over youth and enthusiasm. :-)

I really wish I had a few more hours in my day that is for certain.

Continuing the jail_list experiments I moved a jail into /etc/jail.conf.d/test37.conf and it was NOT automatically started.

So that's one of the several quirks between jail.conf and jail.conf.d/foo.conf is that jails defined in the latter are not automatically started. Along with other quirks about jail.conf.d/foo.conf files too. I stopped using them for that reason. Mostly because I haven't figured out what's allowed there and what is not allowed there.

voy4g3r2: think jail_list isn't needed as of 14.x or smth?

i am not sure, i honestly do not recall making a jail list

i just made a configuration in the jail.conf.d directory and it would just work

Again, if jail_list is empty then all configured jails are started.

wait that wasn't happening to me

i didn't have jail_list and it wasn't starting my jail

Did you configure the jail in /etc/jail.conf or in /etc/jail.conf.d/jailname.conf ?? The first is started. The second is not.

the 2nd

Then all is as expected.

is that explained in the man rc.conf on it? i got it to up to read but was making dinner

/etc/jail.conf.d/jailname.conf is only poorly documented and has several quirks that make it different from /etc/jail.conf for reasons I do not understand. Not being able to figure that out and lacking the patience to explore why that's why I haven't myself been using jail.conf.d/foo.conf

In rc.conf it says exactly "When left empty, all of the jail(8) instances defined in the configuration file are started."

aha i bet that's what meena was talking about them fixing those unconventional behaviors as they go

But experimental evidence shows that this does not apply to the jail.conf.d/name.conf file.

Somewhere there is documentation that talks about some of the things that can be in each and some things that must only be in jail.conf only.

ya i saw that, but to me the INCLUDE in jail.conf including my individual config files in jail.conf.d IS the "configuration file"

docs should be updated until the behavior is changed

weird. just hit me that voy4g3r2 said his jail is in jail.conf.d/file.conf and it was being autostarted. so maybe this quirk is fixed in in 14?

rwp have you verified the quirky behavior even in 14.x?

I am running 13.2R here. So hopefully quirks will be fewer in 14.

is it possible to upgrade from 13.1-STABLE to 14.1-RELEASE ?

Yes.

It's even possible to downgrade from 14 to 13. Though that's only needed if problems affect things.

using a boot env?

You will also need to wait for 14.1-RELEASE to become available too.

heheh

14.0-RELEASE should do

You know... I haven't tested freebsd-update -r moving downward but I am pretty sure that it just moves to the specified release.

i jus bricked my 13.1-STABLE after an update

alepzi: dpaste.org/ETSqW

Title: dpaste/ETSqW (Plain Text)

this is a pretty standard jail

voy4g3r2: running 14 or 13?

I have tested creating a new boot environment and then booting to it. That definitely works regardless. One can always do the work manually. But pretty sure freebsd-update -r does it too.

14

hernan, You bricked your 13.1-STABLE after an upgrade? Boot Environments FTW! If you are using those then simply boot the previous and be up and running again immediately. Alternatively snapshots FTW! Use a previous snapshot, clone it, boot it, and again you are up and running again immediately.

14 it is

i'll bet that's the diff

rwp: right, i always screw up. i hit enter and remembered, why not take a snapshot

let me try to check the boot env

its an option in the boot menu right

but i only upgraded the packages

i dont see a boot env option...

bah .. nice way to start a weekend

Packages as in binary pkgs or packages as in compiled ports?

If it was only those either way though neither of those should prevent base from booting. That makes me think the problem is actually something different.

What are the symptoms of "bricked"?

compiled ports pkg

right now, bricked = X wont start

im attempting a pkg upgrade -f

hernan, Are you using a ports driver such as radeonkms or other similar?

yes, i915kms

intel video

and i think thats somewhat relate

I have the same problem with the AMD radeonkms driver from ports. It's a known compatibility issue with the recently changed kernel that the ports is compiled to the previous kernel.

oh great =p

So... That's not really the same symptoms that most of us would say is "bricked". That's probably causing a kernel crash upon starting X. But it is running before that point. So not bricked.

:)

yeah, not completely bricked

If you install 13.2-RELEASE then all of the precompiled binary pkgs will be valid with that kernel. That's the kernel they are compiled against in the build farm.

rwp: i dont think its possible to freebsd-upgrade from 13.1-STABLE to RELEASE

there is some way, but not straight forward as with freebsd-update

In my case I upgraded from 13.2R to 13.2R and experienced the kernel crash. Then in my case I just selected the previous boot environment. I am actually still running it.

boot env <3

I don't know why it would not be possible.

i didnt even remembered it

Also if nothing else you can create a new Boot Environment installing upon it whatever release you want to boot. Then boot it.

I am assuming that you are running zfs and if not then that's going to be additional problem.

it says: freebsd-update Cannot upgrade from a version that is not a release (including aplha, beta and release candidates) using freebsd-update. Instead, FreeBSD can be directly upgraded by source or upgraded to a RELEASE/RELENG version prior to running freebsd-update. Currently running? 13.1-STABLE

the command i used is: freebsd-update upgrade -r 13.1-RELEASE

yes, running zfs

What does it say to go to 13.2R? freebsd-update upgrade -r 13.2-RELEASE

same thing

maybe i could try a --currently-running option

and brick it even more

I haven't gone through the versions to and from current, stable, release. So that's missing from my experience.

yea, i dont even know why i used -STABLE :(

If it were me then I would create a new empty boot environment and then install 13.2-RELEASE it and then boot it. Here is an original posting explaining much about Boot Environments. forums.freebsd.org/threads/howto-freebsd-zfs-madness.31662

Title: HOWTO: FreeBSD ZFS Madness | The FreeBSD Forums

ha! vermaden

Notice the date on that and so it is from when those were originally introduced. But it gives all of the background needed to understand how they work and ideas on how to work with them. Such as for creating a new boot environment and booting to it. Which normally is not as easy but in your case I think this might be the easier way for you to recover.

right! will check it out

And I mean if you had a snapshot or a jail or something that already had all of the bits handy then creating a new BE using those would be pretty easy.

For me I always have multiple machines running so I could always just copy a system from another machine.

Notice in "6.3. Import Boot Environment from Other Machine" where there is an example of pulling the system from one machine to another machine. It's super nifty!

hmmmmmm

is that even possible .. nice

You can see that we would not consider a system that can still do these types of things "bricked". :-)

I should also say that beadm is still supported in ports. But being in ports might be a problem on a base only system or a broken system. Since then bectl has been written to be in base specifically for that reason. Use either that is available. But bectl is in base and will always be available.

right

i installed it

on that 13.1-STABLE

And the Boot Environment naming convention and such that vermaden describes has been improved upon and is different from what the freebsd isntaller installs today. After getting things into a working state then you might want to make naming adjustments such as to get on the new way things are done so that the freebsd-update tool can use it. Otherwise it won't.

how much does destination machine have to match the origin machine the boot env was built on?

They must be the same architecture.

but different hardware?

Sure. But must be the same architecture.

it's based on the kernconf=GENERIC i'm assuming?

uname -m

And both the same as in 32-bits -> 32-bits and 64-bits -> 64-bits.

alepzi, The source machine will be based upon whatever it is based upon. Since hernan is running 13.1-STABLE I assume the other machine is too.

seems like a cool way to control a campus of gui terminals for sales drones. every day they network boot a boot env from the template server

But as long as it is self-consistent on the source then it will be self-consistent on the destination. And the current problem is that the graphics driver in ports is inconsistent with the kernel in base.

And one can't simply (or shouldn't) downgrade the kernel because then base userland will later than the older kernel and probably problems with some syscalls that have changed.

That's why one should boot the kernel and base and ports that are all the same level of version so that they are all self-consistent.

alepzi, Yes on the cool ways to boot a farm of systems from a centrally maintained network server. Lots of cool capabilities.

rwp: nah, its only 1 with 13.1-STABLE. others are -RELEASE

hernan, Isn't that what you want?

Don't you need to get onto 13.2-RELEASE so that the binary pkgs including the Intel i915kms driver from ports all are consistent and X will start for you?

yes

Another alternative if you want is to compile everything on your machine for yourself. Since it will all be freshly built it will also be consistent. But that might take a while on any random hardware, possibly an old laptop without much memory. :-)

I am going to need to drop off afk but I think you have enough leverage to move things around. Or others will happily help too.

Happy Hacking!

thanks rwp

ps -J <jail> is best way to see how much cpu and ram a jail is using on the host system as if it was 1 single process listed in top?

well first thing i will do some backups. however, one thing i need to backup is a cbsd(bhyve) vm. and its in zroot/usr/home/ubuntu1/dsk1.vhd -- How can i copy that file over ? the file seems inexistant.. however i can see it in "zfs list"

looks like all a jail runs by default is cron?