Anyone got Frama-C working on FreeBSD?

Hi :) I'm running FreeBSD 13.1 on a Thinkpad X250. Everything works well except for my docking station - when I dock the laptop all my peripherals work (USB), but the monitor isn't detected unless I reboot. I'm obviously missing *something* but can't find anything in the docs that explain it. After a reboot xrandr finds the external monitor just fine.

Anyone got Frama-C running on FreeBSD?

Nobody here uses Frama-C?

any idea why am I allowed to destroy a jailed dataset from the HOST ?

I thought that jailed dataset couldn't be removed from the HOST

mage, I cannot answer your query. For my own curiosity, do you mean by "jailed dataset" a dataset on host to be used for|by a jail; or, a dataset set up inside a jail?

parv: a dataset with jailed=on property and which has been zfs jail /my/dataset in an exec.created jail.conf

Thank you

So that dataset is on host; in which case, do not see any reason to treat such a dataset specially. It is just like any other, saya dataset for $HOME which I consider to be more precious than root

mage: simply put, the host system reigns supreme over the pool and there is no *reason* to prevent it from being able to destroy that dataset (unless you want something like system immutable aka schg for datasets)

Have you ever managed to get a newer postgresql client (i.e. pg_dump) running on an older PostgreSQL server in order to dump the data? Or have you always done it with two hosts?

i vaguely remember that vt is getting deprecated in some freebsd version. is that happening in 13.1, 14.0 or even later?

also just starting bringing my homeserver from 11.2 to 13.1, wish me luck. ^^;

dvl: ‘Because pg_dump is used to transfer data to newer versions of PostgreSQL, the output of pg_dump can be expected to load into PostgreSQL server versions newer than pg_dump's version. pg_dump can also dump from PostgreSQL servers older than its own version. (Currently, servers back to version 8.0 are supported.) However, pg_dump cannot dump from PostgreSQL servers newer than its own major version; it will refuse to even try, rather than

risk making an invalid dump.’

Title: PostgreSQL: Documentation: 14: pg_dump

Remilia: Yes, taht part I follow.

Remilia: The hard part, getting that all done on one host.

well, you cannot run a new major postgres version with an old version's data directory

but your question was ‘new pg_dump with old server’

which will work

Remilia: Yes, so far, we are in complete agreement.

my approach when I really need to upgrade with minimum possible downtime is jails

mhh, i just did the first reboot updating from 11.2 to 13.1 and now all the child datasets of root don't get mounted anymore – anybody got any pointers what to search for?

canmount property for these datasets are 'on' and my rc.conf does have zfs_enable="YES" – far as I can tell these should be mounted, but I think I already had this problem on a different machine where I found no solution but just put all of the datasets into /etc/fstab which seems… wrong.

mountpoint is also set for each of these datasets.

does when you get logged in, does zfs mount -a mount them without any troubles?

scoobybejesus: i assume so, still in the rescue shell and it worked fine from there – except for the boot pool not having been imported previously.

so after i did `zfs mount -a && zpool import boot` everything is mounted where it belongs.

have you made it to another reboot yet? it's possible you experienced a one-time issue

no, i haven't, wanted to ask before i progress.

i assume this will recur, but i can finish the version upgrade first.

also, to clarify, the root dataset of the root zpool mounts fine, it's just the child datasets that are affected.

one suspicion i should probably look into is if the update maybe messed with the zpool.cache file…

i don't know the answer, at least not with confidence. i'm trying to dig into my memory and ask questions to help you get a few details written here so someone a bit more of an expert can have their own memory jogged and say "oh yeah, you're in good shape, just do X and check Y real quick"

ah dang, i need to now create a new poudriere jail and rebuild and update all my software. this is gonna take a… day, or three.^^

Anyone using wifibox? What kinda of overhead is there with that?

how do i manually update the root CA's? I copied a newer /usr/local/share/certs/ca-root-nss.crt over and made sure it's linked to from /etc/ssl/cert.pem, but even after that validating certificates fails…

(and yes, I'm sure the validated certificates are correct, talking about download.freebsd.org and other major infrastructure, works perfectly from my systems that aren't quite so out of date)

mhh, i noticed that the thing the boot seems to stumble over is actually my tmpfs fstab entry. i added tmpfs_load="YES" to my loader.conf, but that didn't fix it, still says something along the lines of "tmpfs": unsupported operation (can't scroll up anymore, will have to see at next boot :F)

also even tho tmpfs_load is in loader.conf, when i can drop into the rescue shell, kldstat does not show me tmpfs

after I do zfs mount -a (to have /boot properly mounted so kernel modules are actually findable), it does show me tmpfs, so it definitely didn't get built into the kernel itself…

and `mount -a` after that results in a tmpfs being mounted at /tmp without any fuss…

Mhh, so I thought it might be the outdated bootloaded, but the current gptzfsboot does not fit on the bootloader partition I have… what do?

Okay, as it seems I have to re-create my /boot anyways – can anybody point me to docs describing how to manually install an UEFI boot chain?

man 8 uefi does not really detail what I need… do I need to call 'gpart bootcode' with some other parameters – or is that just not done anymore and I just need to create an EFI partition and slap loader.efi on there? closest thing to concrete info was a post on the freebsd forums saying it all resides on the same partition as /boot now, but that only confuses me more…

phryk: i didn't know gpart does that… well, more like, i forgot about it

meena: does what? you mean the gpart bootcode thing?

phryk: i thought freebsd-update would take care of updating the bootcode

meena: mhh, i don't think it did, otherwise I assume I should've gotten the same error as wenn trying to manually put gptzfsboot onto it (partition too small)

i tried overwriting with the current gptboot, but that fails booting (this is a completely redundant install, so I can boot with the old loaded from the second disk, so no harm done – yet)

s/loaded/loader/

i'm currently thinking about trying a 'gpart resize' on the /boot partition, but have two ugly suspicions: a) this will break the boot zfs pool b) it will only free space at the end of the /boot partition, instead of the start where i need it…

also, wiki.freebsd.org only throws varnish errors. :F

mhh, with the old bootloader from the second disk, it boots up perfectly fine, *IF* i comment out the tmpfs on /tmp in my fstab…

this seems to imply that kernel modules defined in loader.conf aren't actually loaded from the same filesystem the kernel is loaded from, but rather that it first mounts vfs.root.mountfrom and then look into /boot (which on my system is an extra partition) and then it just runs into a failing cascade and goes asplode…

oh wait, i can look up how to manually do a bootable uefi setup. i have a script somewhere to recreate the bootsticks for my encrypted laptop.

ah yes, create msdosfs partition, copy loader.efi to EFI/BOOT/BOOTX64.EFI on it.

A fresh install (with zfs) creates users in /home but /home is a symlink to /usr/home.

This means /bin/pwd != $HOME and prevents bash's ~ prompt optimization.

Newbie question. Why /usr/home? Why not /home? Or /users? Or /u? There must be some backstory which explains this odd choice. Anyone know?

okay, detached the first drive partition from the boot zpool, going to build up an alternative one with a big msdosfs partition in front of it for efi – wish me luck. ^^;

Good luck! :-)

rwp: i wondered about that myself, i assume it's more or less historical reasons, because anything above /usr is considered part of the base system, but I can't say I'm certain that's the right explanation.

and thanks :D

Glad I was not alone in this question phryk!

I decided to change my home directory from /home/rwp to /usr/home/rwp to regain bash ~ prompt optimization. Since that is easy.

dvl: yes, but I had the freedom to install two different major versions between the host and the jail. Withink the same logical system, I'd just install from PG sources into two different prefixes (so not from ports)

docs.freebsd.org/en/books/handbook/basics is rather quiet about it. Just documenting the various typical ones.

Title: Chapter 3. FreeBSD Basics | FreeBSD Documentation Portal

rwp: mhh, man 7 hier also doesn't mention it…

most pertinent line in there is probably "/usr/ contains the majority of user utilities and applications"

FreeBSD seems to be unique with this default /usr/home installation choice. It's /home on NetBSD, OpenBSD, and GNU/Linux systems. It's /users on HP-UX.

And honestly I would not notice if it were not for the /home -> /usr/home symlink mismatching the canonical location with the password database home.

rwp: I think in days of yore (like 2.6 and earlier) many linux distros also used /usr/home, tho memory can be a tricky thing. :P

I don't recall any use of /usr/home/ for any of the linux distros at any time. But there are many distros and I only used a handful of them. I'll say Debian derived and Red Hat derived for a selection cone.

For days of yore we all know that Thompson and Richie had their homes in /usr/ as that was the definition of the user disk.

Anyway... It's not important. Back to your UEFI boot challenge.

yeah, killed the first two partitions on the first disk (redundant setup, so I only shoot myself in the foot, not the head), created efi and zfs partitions as well as filesystems and copied the needed data over…

this probably won't *properly* boot, but i should already at least try to see if the efi loader works and actually loads the new boot zpool

huh, reboot gives me a dark red "Error: fail" line… i'm sure this is fine T_T

mhh, if i try to boot from the first disk, all i get is "Missing boot loader" :'D

pstef: Yeah, I was thinking of launching a jail

mhh, the board boots from an efi partition on a usb stick, but not one on an actual hard disk? o_O

trying to flash a new firmware onto the board, hoping that'll fix the uefi weirdness…

*prays to goddess* please no power surges or any other crazy shit right now

"Update successfully!" such transration

so i have a freebsd 9 disk i'm trying to boot on a modern motherboard with both uefui and legacy boot modes. legacy won't boot the disk. it just hangs at btx loader

is there anything i can do? update btx loader?

install modern freebsd on modern motherboard, run legacy freebsd in emulator ...

nacelle: i just want it to boot so i can transfer files from it

but can a modern byx loader be installed?

YAS I CAN HAZ EFI BOOTLOADER

CCFL_Man: I assume the btx is the oldschool bootloader? I think all you need for that would be something along the lines of:

gpart add -t freebsd-boot -s 512K -l gptzfsboot0 ada0

gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0

out of curiosity, is anyone working on pkgbase? (the wiki page is mostly unchanged for a few years, and the mailing list is mostly quiet as well)

(gptboot instead of gptzfsboot if you're not booting from zfs, don't recall what the right thing is if you don't use gpt)

phryk: it's ufs, not zfs

it's freebsd 9

yeah, it's an older bootloader

CCFL_Man: ufs is what /boot/gptboot is for

CCFL_Man: the textmode one, right? that's the one installed with gpart bootcode. :)

i just deprecated that one in favor of efi in the hopes it fixes in issue i'm facing upgrading my homeserver. :P

mhh, but no it didn't fix the issue i was trying to fix… tmpfs still isn't loaded even tho it's noted in loader.conf…

huh, the fix for my problem was actually *removing* tmpfs_load from loader.conf? o_O

that's both confusing and goes against what man tmpfs says…

gonna try and see if that's also the fix with the classic bootloader

huh?

kevans: yes, that confused the hell out of me, too.

what's the original provlem?

kevans: "tmpfs: Operation not supported by device"

and just made sure it's independent of the bootloader – taking tmpfs_load="YES" out of loader.conf fixes the issue for both loader.efi and gptzfsboot

kevans: there were some error messages in dmesg about tmpfs already being loaded (tho kldstat showed it not being there) and something about an error 22 when trying to unregister oid tmpfs.

kevans: should i recreate the problem and paste the dmesg output somewhere for you?

phryk: yes please. if you can capture loader output too, that'd be helpful

kevans: does that go into some file automatically or do i have to set some option for that?

phryk: you'd have to habe a serial console

phryk: alternatively, drop to loader prompt and issue boot-conf command

then interrupt it and write down the output

kevans: and then… take a photo of what's shown on my screen?^^

yeah

that works too

interrupt it?

it'll try to autoboot again once you issue boot-conf

ah, so basically press esc

the usual press a key to interrupt, yeah

alright, rebooting into the thing now

keep forgetting you can't put # comments behind lines in loader.conf^^

okay, got it with the tmpfs_load line properly recognized and throwing the error. snapped a pic of boot-conf and saved the output of dmesg to a file and am now rebooting into the fixed system without the tmpfs_load line and will be able to upload the files shortly

kevans: here you go…

loader.conf: paste.xinu.at/whD

Title: loader.conf

dmesg: paste.xinu.at/1qd2

Title: dmesg

boot-conf: paste.xinu.at/iXw7