actually I dont think so

make installkernel worked, make installworld attempted a rebuild

will need to to test with NFS to confirm

polarian: if you attempt installing onto an nfs mount, i think you will run into considerable difficult. but if you are installing from a remote install tree that is mounted over nfs, that should work

jmnbtslsQE: this is installing from

NFS is the supported way of doing it

swee: there is some mechanism to run scripts after installation, which is in the port somewhere i think. not sure of the details. i think it would be in the "port handbook" or similar

I was curious if I could with sshfs instead, as all you really need is the obj and src tree without modifying the mtime

i wonder why your installworld started to rebuild. that somehow does not seem like it's related to sshfs

sshfs propertly treats mtime though, doesn't it?

*properly

jmnbtslsQE: thats what I thought yes :p

so I said I would try with NFS, see if it happens with that

i use sshfs a lot and i never had any issues with metadata over sshfs, but not to the point of trying to install from it, so, not sure

actually, i don't even know why installworld would ever do a build, but i don't have much knowledge of the build system. if there's no build, it should report that there is no build and suggest MAKEOBJDIRPREFIX needs to be set

maybe you are actually seeing installworld work on the temporary directory structures it uses?

I'm attempting to use pkgbase to upgrade from 14-STABLE to 15-STABLE. mounted a new boot environment at /mnt, then ran: env ABI=FreeBSD:15:amd64 pkg-static -c /mnt upgrade

the upgrades fail partway through installation with this error:

ld-elf.so.1: Shared object "libedit.so.8" not found, required by "sh"

pkg-static: POST-INSTALL script failed

oh, I suppose this is maybe a consequence of using -c instead of -r

in this case, will -r download and cache the packages in /mnt/var/cache/pkg, or will it download them into /var/cache/pkg?

seems like probably the former, it's not prompting to redownload all of the packages

not sure if it's ill-advised to attempt to have pkg upgrade continue where it left off after failing

on 15-STABLE now. I had forgotten about this issue that I encountered when I tried 15 back around ALPHA1, and that's how my trackpoint's sensitivity is cranked up vs. how it is on 14

I don't think anyone explained to me why it's like this here on 15

I just have this stuff set to the defaults

for me for my desktop i had to turn off the new input drivers to be able to use my usb mouse

this is apparently using the psm driver, which dmesg warns might be removed by 16.0-RELEASE, but the psm man page doesn't offer any alternative driver, at least afaict

I'm gonna boot back into 14 to see if there are any hw.psm.trackpoint knobs that got their default values changed between 14 and 15. also going to check whether Xorg's libinput driver is settling on different acceleration values or the like between the two versions

the Giant lock has been rescheduled for removal by 16R, and psm uses the Giant lock; if it still needs to exist by then it will still exist by then

I'm back on 14. the hw.psm.trackpoint sysctls don't even exist here

hw.psm.trackpoint_support is set to 1, but I can't check what hw.psm.trackpoint.sensitivity is set to

So I’ve never got FreeBSD to get sound working on my Chromebook.. I had a question .. my Chromebook uses did-firmware which FreeBSD doesn’t support but even on Linux vetting distros I can’t use sod-firmware but I can use pro audio with pipe wire and sound works perfect.. question is can I install Fr

eeBSD on my Chromebook get an X session up and running install pavcontrol pipe wire and jack and get pro audio ?

Sorry long post

OSS probably won’t let me

so even though trackpoint_support is apparently enabled, here on 14 libinput is recognizing the trackpoint as a generic PS/2 mouse, whereas on 15 it's recognizing it as a trackpoint. that's probably the reason why the trackpoint feels totally different between versions

maybe setting trackpoint_support to 0 on 15 is enough to restore the feel I've gotten used to on 14... or I could just learn to adapt to the higher sensitivity

I just ended up setting hw.psm.trackpoint_support=0 in loader.conf, seems to force 15 to behave like 14 in that regard

I guess on 14, trackpoint support in psm is bugged for my specific machine (ThinkPad T495), but it flew entirely under my radar since it did not noticeably affect functionality

i need a sane way to sample as many different UIs as i can, i don’t suppose someone makes a collection of freebsd livedisks, each with a different UI preinstalled and ready to use?

and i guess the livedisks don’t really need to be freebsd at all do they? if i’m just sampling the GUI i want to put on freebsd, testing it in linux should work as well as anywhere else

GoSox: what do you mean with „sample“ and [G]UI? If just testing different graphical environments, then it might be feasible to just fire up a test VM and test them?

well yeah thats basically exactly what i (think i) mean

i guess i’m wondering if anyome makes a sampler disk image just for this purpose to make it nice and easy to do

hmm weir

weird*

oh wait nvm fixed it, ignore me :p

GoSox: I would just fire up a linux distro live ISO. easier no install necessary

?

hello people

hi

@haskyll

how are you doing

hello

I have a pair of firewall (running pf, pfsync, carp) which are still running 13.5-RELEASE. I'd like to upgrade to 14.3-RELEASE and I was wondering what would be the best procedure as I rememberd that there are some pfsync protocol changes in 14.3 (which are incompatible with the one in 13.5) ..?

can I simply start by updating the BACKUP node to 14.3 and update rc.conf with pfsync_ifconfig="version 1301" and then update the MASTER ?

rtprio: i'm back dudes

from a new server

wait and see if this server fails, but i'm pretty sure it will work like a charm

mage: that sounds like an ok idea, but i've never done it

does freebsd have an equivalent to gnu mailutils package? it has a bunch of utilities for doing POP3, IMAP, mbox, MH, Maildir and dotmail.

i... think you could install mailutils for your uses?

oh you're right. it's in freshports. i didn't expect that.

"pkg install mailutils"

And of course "pkg search -f mailutils" for information before installing.

so i'm trying to install freebsd on a r730xd; the h330 has the options of ata, achi or raid

but which between ata or achi is preferred

Go with ACHI.

it that's what i thought, but it greys out some other options

ACHI is the higher performance selection. I had to refresh my memory looking it up. Supports NCQ Native Command Queing allowing reordering of commands. Enables hot swapping.

in the lifecycle controller there was another raid controller (presumably for the back or internal drives) but now i can't get it to show up again

Also enables power management features. (I don't know anything about this one.)

i don't know if i love the /dev/mfisyspd0 device numbering

How is it numbering devices?

(I don't currently have any Dell server hardware. Just a couple of Dell laptops. And none of them are running *BSD.)

like /dev/mfisyspd[1-3]

rather than da0 or ada0

oh, i found it, mrsas

now it's da0 and so on

I don't operate any Dell servers... I thought that the mfisyspd driver was some Dell specific driver for drives that is used instead of the hardware raid driver which hides the hardware behind the raid device. No? I have no idea.

The kernel didn't number them from 0, 1, 2, ... N? That would be odd. But as you know we always push GPT labels is possible and UUID labels if possible and other persistent label methods.

in my experience zfs usually doesn't care if they're persistant so long as the bios/efi knows which disk to start from

ZFS does not care. But if (when?) a drive fails then I need to know which drive it is that failed so that I can eject it and replace it.