correction: location is /usr/local/jails/classic and the command I'm running is chflags -R 0 /usr/local/jails/classic.

tp512: does it come up in dmesg / usbconfig ?

nevermnind, I've been staring at this for too long... I got it figured out. location is /usr/local/jails/containers/classic. all is good

rtprio: in dmesg it shows up as ugen1.3: <Microsoft Controller> at usbus1

I could check usbconfig, but presumably it will show up, dunno how much useful information it might have

it's just the message about it being registered on the bus, no messages from a driver loading and configuring the device

that means there's no driver for it,

unless sdl is smart enough to use it as is, which i doubt

well as-is, SDL just doesn't recognize it. honestly pretty disappointing, I had just assumed this is something FreeBSD would have support for by now

especially since PS4 and PS5 controllers appear to work

unless a developer fancied a game of tuxracer and took the effort to do it, thre's no reason to think that it would work

stop assuming that everything works, just because it happens to work on linux

well it was an assumption based on the fact that 360 controllers work, and that NetBSD already has support in their driver. I guess NetBSD shouldn't really be used as an indicator, but I don't really expect it to have better support than FreeBSD for anything from like the last decade

for vintage hardware, sure

you can check, it might be as easy as just adding the device identifier to the xbox driver

or it might be a whole new driver

I'm going to look at their driver. I *think* I tested with my 360 controller on NetBSD as well and it loaded the same driver as it did for the Series X|S controller, though this was months ago

unfortunately my 360 controller is out of commission or I'd just use it

needs to have the cable replaced, at the very least, and I don't have any soldering equipment. probably not a tough repair if I got that set up

NetBSD's anonhg sure is sluggish, bleh

so the driver is uhidev, uhidev_match gives the exact same return value for XInput controllers and Xbox One controllers, promising sign that maybe it's a really simple change to add support

tp512: i've never found 360 controllers very comfortable but maybe it's just me. i had problems using the dpad on them so stopped using them.

the d-pad is really the only thing I actively dislike on the 360 controller, but they improved that quite a bit on the Xbox One and Series S|X controllers

the d-pad on these has like microswitches for the buttons, it's not just a mushy disc like the 360's

is the software interface still based on the 360?

i was never really clear how joysticks were implemented as hardware devices

I don't really know the details either, it seems like NetBSD at least is using the old code for the newer controllers, just adding the new device IDs to get the driver to associate with the controllers

I am running latest for packages and I would like to take snapshots before upgrading them. It looks like there is a separate default zfs dataset for /usr. Should I snapshot this dataset? All packages installed by pkg go into /usr/local right?

the /usr dataset isn't actually mounted, it only exists for /usr/ports and /usr/src

had to have that cleared up for me like last month, heh

oh, so then I should snap zroot/ROOT?

zroot/ROOT/default I think actually

yes, though I might suggest using boot environments

I've just been creating BEs to make bootable snapshots of the system state before I run OS upgrades

tp512 forums.freebsd.org/threads/updating…h-zfs-boot-environments-beadm.84866 is this a good starting point?

Title: Updating FreeBSD With ZFS Boot Environments (beadm) | The FreeBSD Forums

you don't really need beadm, the base system comes with bectl

but other than that, basically seems like the process I'm using

yes I see that freebsd-update/upgrade is creating boot environments already

so I can manually create a new boot environment with bectl?

I don't know anything about freebsd-update creating BEs, I haven't run -RELEASE in like a decade

oh you're on CURRENT?

but yeah, you can manage BEs manually with bectl

I run STABLE any time I use FreeBSD, basically

STABLE is CURRENT merges after they are deemed "stable", I was just reading about that I think

sort of like gentoo's stable policy after packages pass testing/certain time period?

CURRENT is the main (aka "master") branch, each release series gets its own stable branch, and yeah some stuff is pulled back from main to stable

right, and then STABLE eventually becomes the next RELEASE?

the releng branches are where RELEASE versions come from. I don't know the exact relationship between the stable branches and corresponding releng branches

no prob, I am probably close to the right answer, I'd imagine stable factors in somewhere

like I'm guessing releng is branched off of stable, but someone more familiar with release engineering would have to chime in

so, system has been stable all day on drm-510-kmod. pretty sure drm-515-kmod's amdgpu.ko was causing page faults

hopefully the LinuxKPI stuff from CURRENT gets brought back into STABLE so that drm-61-kmod can be used, I'd kinda like to test with that

tp512: my understanding is there is CURRENT which is the current version and periodically branches off the trunk are made ("releng") which are numbered 10,11,12,13,...

so you would have e.g. 10.0, 10.1, 10.2, then on the 11 branch 11.1, 11.2, etc. STABLE refers to the latest version on one of those branches. so 13-stable would be the next version of 13

so in git the branch tag would say stable/10 or stable/13 and the build name would be like FreeBSD 10.1-STABLE

but releng/14.1 would be branched from stable/14, I presume, basically freezing the state of that point of the stable/14 branch and only pulling down stuff like bug fixes?

no it's the other way. releng release refers to the initial 14.0 release. then stable is the "latest" 14 up to that point

I'm not talking about 14.0

oh i see releng is used as a tag for all the releases on a branch

each point release has its own releng branch

guessing the patched updates that get periodically released for RELEASE are developed on top of releng, pulling down like low risk commits from stable

right. CURRENT is the dev version of the main trunk. STABLE is the dev version of a given branch. like 10-STABLE

the terminology is weird because "stable" is actually development version

what I'm confused about is the initial .0 release, like were stable/14 and releng/14.0 created from the same commit on main? did one predate the other?

Yeah, but if you are just tracking the RELEASE, and not following STABLE - You are missing out on security patches for CVEs and the like aren't you?

release gets patched

SponiX: no, RELEASE is periodically updated

my understanding is releng/14.0 is created as a branch, then 14-stable is the dev version of that on that branch

so you'd have releng/14.0 -> 14-STABLE on the git tree. can someone tell me if i'm right

CowboyNeal: oh, this where they do like 13.1-p4 and stuff?

yeah

$ uname -r

14.0-RELEASE-p5

Nice

patches can be pushed backwards from CURRENT or STABLE as well yes

i'm not sure how it works exactly

Sorry for the ignorance. I haven't actually played with FreeBSD in a decade or so

I'm basing what I said off the Lucas book and it is fairly current

hmm 2018

johnjaye: almost but not quite

14-STABLE is the branch that 14.0-RELEASE is created from.

typically patches go to CURRENT branch (actually called main in git) and stew for a few days

or weeks

and then these are moved (often called MFC, or Move From Current) into the STABLE branches for each supported release train

13-STABLE and 14-STABLE

these are called STABLE because the ABI should be ... stable .... over time

what I'm wondering about personally is whether the stable branch shows up before or after the release engineering for the next major release

like at what point in the process will stable/15 be branched

thus you should always be able to build/run 14.0-RELEASE ports and packages on a 14-STABLE kernel if you want

the official release branches are named releng/<major.minor> e.g. releng/13.3 releng/13.2

and any FreeBSD 13.2-p4 patches are landed explicitly on those branches only by re@ or security@ teams

so: CURRENT -> STABLE-x -> releng/x.y

so even in the alpha/beta/RC stages of a new major release, is there still things filtering through a stable branch forked off from main?

tp512: new 15.0-RELEASE appears in accordance with this policy lists.freebsd.org/pipermail/freebsd…-announce/2015-February/001624.html

Title: [FreeBSD-Announce] Changes to the FreeBSD Support Model

"A new stable/ branch release will not occur before two years after the X.0-RELEASE from the prior branch"

tp512: sort of. it starts off quite loose, and gets "slushier" as we get closer to a release

tp512: oh I misread your question. Yes, stuff is MFC'd all the time from current->stable branches.

you can see this atm as 13.3 was released just a week ago

e.g. commits on 13-stable cgit.freebsd.org/src/log/?h=stable/13

Title: src - FreeBSD source tree

dch: what I mean isn't current to stable merges, but like, what happens with releng/x.0, does stable/x start at the exact same point to serve as an upstream of releng/x.0? or does stable/x not exist until after x.0-RELEASE is out

tp512: aah right

so:we start with CURRENT

we start with CURRENT

then 15-STABLE would be created

and CURRENT becomes the new 16-CURRENT

then we want a release

so releng/15.0 is created off 15-STABLE

and we do the alpha -> beta -> rc -> release -> patches dance

see freebsd.org/releases/13.0R/schedule for a concrete example

Title: FreeBSD 13.0 Release Process | The FreeBSD Project

so stable/x exists first and is the branch that specific releases for releng/x.y will be taken from

kinda just seems like releng/15.0 and stable/15 would be redundant during those very early phases, having trouble thinking of what differences they'd have

like what changes to STABLE at that point wouldn't make it into the 15.0 release

unless the releng branch is just to slow things down, add an extra barrier for things that could make it into stable but might not be fully ready until the .1 release

tp512: I think in practice you're correct.

as the release moves towards completion, requests to move from the stable branch (where committers can just push), to the releng/x.y branch (where committers need explicit approval from re@ ) need a progressively higher bar to go ahead

and eventually it's like unless this breaks something critical like boot process for everybody, then the release goes ahead

and your patches either go through an Errata process and an official -p0 patch, or you wait for the next minor release

makes sense reading the 13.0 release schedule

its helpful to have the same process for all releases

and after, say, 15.0-RELEASE, releng/15.0 will become the branch from which patches are released?

yes, for 15.0-RELEASE-p0...pX

so following the releng branch would end up getting the same things that get bundled into the next patch

unless something manages to get through that does need to be reverted

tp512: yes. releng/x.y is *exactly* x.y-RELEASE-pZ

see cgit.freebsd.org/src/log/?h=releng/14.0&showmsg=1 for example

Title: src - FreeBSD source tree

seems like overall this is similar to how NetBSD does things except they don't seem to use releng branches at all, but on my one NetBSD machine I'm using what's effectively the 10-stable branch, though the builds get labeled as RCs since that's the phase 10.0 release engineering is in

like the stable branch effectively serves the same function as releng leading up to a point release

decmini.com can take a latte panda (intel's take on rasbpi size system) dfrobot.com/product-2594.html?tracking=62f46c260c041

Title: DEC Mini, a lovely 3D-printable retro computer

my birthday is coming up, I DESERVE THESE TOYS

kinda wish they'd incorporate LinuxKPI. 10.0 isn't even out yet and it's gonna be stuck on DRM drivers from Linux 5.6. if you want newer ones during the lifetime of 10.x you'd have to use current after new drivers get merged

with FreeBSD I like how the drivers are modular and allows for new ones to show up through a release series

oh huh so releng/14.0 isn't even a trickle of commits, they're merged in batches when the patch releases are to be pushed out?

yep you commit to 14-stable then beg re@ for approval, and when a sufficiently urgent patch arrives, the batch will be released

I gotta get bluetooth audio up and running at some point. plugging my laptop into this bluetooth speaker through the aux input while also charging the speaker through the laptop, I guess it forms some kind of ground loop?

I hear whining and hissing from the speaker

ugh thats bad yeah

the 50Hz whine?

well, 60Hz mains here, but the whine is regardless of whether I'm plugged in to AC

might not be a loop, maybe the noise is just going away when I unplug it from the speaker, because it mutes when it isn't plugged in. could just be a normal case of poorly isolated power components

like a case of the power signal coming over the USB cable getting into the amp's input

these archives do not show everything that is happening on this list lists.freebsd.org/archives/freebsd-jail is there another place with complete and uptodate archives? thanks!

Title: freebsd-jail⊙Fo

nevermind, I was looking at the wrong month I think, carry on :)

Trying to find which man-page I can read about the parameters mentioned in this thread; forums.freebsd.org/threads/resource-limits-for-jails.73187

Title: Resource limits for jails | The FreeBSD Forums

for example rctl -a jail:<jailname>:vmemoryuse:deny=512M <- the parameter/setting vmemoryuse. Where do you guys find the list of settings.

drobban: you can also get rctl to show current resource limits

drobban: in rctl(8)

thx nimaje

tykling: interesting.

drobban: so you can just run "sudo rctl -hu jail:1" where 1 is a jail id

I said limits above, I meant usage

nice tip. this is kinda cool to be able to control resources for every jail

yes it is fantastic

hum. pcpu is interesting, but is there a way to limit number of cpu-cores used? doesnt seem to be the case.

on the other hand. the percentage could just be adjusted to get on equivalent levels.

*I guess*

Testing Testing

ok i think its on wow

dch: so if i were to try and restate what I said. the stable branch is created and then the 15.0-RELEASE is a leaf budding from that branch

moreover as it is built up to release you need more and more permission from the team to add things to 15.0-RELEASE. then finally it is released. so you have 16-CURRENT, then 15.0-RELEASE on its branch with STABLE being the development "growing" along that branch

and due to the definitions you can always build 15.0 ports and use them without changes on 15.x leafs in the future

what pw useradd settings do i need for a user that won't get a pass and can only ssh in with a key in .ssh/authorized_keys

just -w no, then put key in authorized file?

because man page says -w no disables login

so that's prolly wrong

alepzi, Is it practical for you to configure ssh to disable all passwords and only use ssh keys? Setting "PasswordAuthentication no" in /etc/ssh/sshd_config file?

got that already

kbdinteractiveauth is no too

In that case all passwords will be blocked, unless they can get physical access to the system. Unless some access other than ssh is installed. (ftpd, telnetd, other)

just wondering the right pw useradd settings

but why set a pass at all if i only wanna allow auth via ssh key?

One thing that annoys me about FreeBSD is that they use a password database account system rather than /etc/{passwd,group,shadow} files. It's simple with the use of the files. And I can remember how it works. But with pw I don't remember and always must read the documentation.

pw is just a utility, you can edit those files manually and use pwd_mkdb if you want, well using vipw is probably better, as you don't need to remember to run pwd_mkdb then

just tried leaving -w no in, NOT setting a pass, and i can still ssh in as long as the key is in authorized_keys

so the man page for pw is kinda incorrect. -w no doesn't disable login, it disables password auth

isn't login via ssh considered login?

johnjaye: yes exactly

alepzi: yes `pw usermod name -h -` will disable login as user via console, whilst still allowing ssh

alepzi: you can add additional controls in ssh as well, I like having both

hey dch, did you ever experiment with FreeBSD on hetzner? (I did in the end) - seemed OK, and was able to install in various ways.

I'm thinking to replace Debian with FreeBSD on hetzner, but haven't looked into that yet

giro - yeah, I've done it, it works!

I hope it shouldn't be complicated. Did you encounter any tricks?

I did a lot of weird things, crazy dd's in place, there were maybe three tutorials, and ultimately even though Hetzner claimed no FreeBSD support, there were FBSD images that I could use to attach and boot against. So, go figure, you can do it the easy way or the hard way, giro. :-)

dch so since the man page for pw is a lil misleading should it be fixed?

It has been a "long" time since my last freebsd upgrade. How long did it take to install all the base system after the first reboot? It has been more than 15 mins and I'm getting nervous of not seeing any output. I'm running htop on a different tmux screen and I see many "install -S -o 0 -g 0 -m 0444 d84414e3a6f52b9356690670dbda249d265d7a1c067aa67fe2ebe90e76281e1f ///usr/share/man/man5/ypldap.conf"

s2r, I spent a long time staring at my screen too. Better not to watch. Get up. Go for a walk. It will be done when you get back. That's the less stressful way.

libXdmcp-1.1.5 is broken on latest, is there a way to rollback to 1.1.3 without local backup

?

Are you installing binary pkgs? Look in /var/cache/pkg for /var/cache/pkg/libXdmcp-1.1.3.pkg pointing to the previously installed still cached package.

yes but accidentally clean ...

Do you have any other systems that you can look around to see if they have it available for you?

rwp it finished.

ho perhaps my laptop

Teraii, bsd.to/e6Gg/raw

Title: e6Gg

s2r, Yay! \o/

Teraii, That's on my quarterly updated system btw...

libXdmcp-1.1.5.pkg -> libXdmcp-1.1.5~8a86b45642.pkg

etc

I value stability and therefore quarterly is more reliably stable and I'll see the latest updates on average 6 weeks later anyway.

Though I should spend time on the tip-of-the-spear and debug and file bug reports on latest to do my duty on the frontline too.

indeed

Teraii, Oh, I forgot to ask if you were on ZFS and if so if you had snapshots?

seems to be a recent lib because no version of this pkg is in my laptop

rwp, helas :)

but now all packages downloaded will be in backup

well no Xorg for a time

So, does "helas" mean yes or no there? And by your next I assume that the answer was no?

rwp, ho sorry "helas" => no

i'm sad

I mean helas might have meant hella good too.

is there a repo lately sync ? :)

And you have no snapshots either?

no

it's all my fault, i know

But you are still running Latest? Me shakes my head. Life! You get the test first and the lesson second! :-)

:)

Fortunately this is a pretty mild problem that will definitely sort itself out within a day or so in the worst case. So things could be worse.

yes

probably solved on next build

If you are interested in any of the files from my paste above I would make them available to you trivially on my web site tmp area. But I don't know if those quarterly pkgs are compatible with your Latest system. I don't know. But you could try the latest of them to see.

i think not

but good news :)

i have found a backup of the repo :)

Excellent! Backups are a good thing.

hope the file is not too old

multiple backup are better :p

+s

The backup rule is 3-2-1. At least 3 copies. On at least 2 different types of storage. At least 1 off site.

yes ! found !

indeed :)

the first backup is broken but the second one is working :)

hoping my xorg work again

hum :( semm not

seam not

rolling back all other packages

ok issue found and corrected :)

the faulted pkg was : libxcb

last working version : libxcb-1.15_2.pkg

Glad to hear you are back up with X working again. And that you were able to diagnose the problem to the problem package.

Maybe make snapshots before upgrading next time? :-)

indeed, moved on my new X :)

yes allready added on my scripts ;)

my X seems to be faster than before :p

now the backup work exactly like my poudriere :p

only branch working are pushed in prod :p

rwp, thank you for moral support ;)

:-)

ChatGPT is unable to describe correctly what each option in "portmaster -adBG" stands for.

Gemini Advnaced is unable to do it either.

wow, the man page can probably describe it

I asked ChatGPT, "what option should I pass to portmaster on FreeBSD if I want it to do the same thing as "make rmconfig?" It responded, "To achieve the same effect as make rmconfig with portmaster on FreeBSD, you would use the --rmconfig option."

I told it, "Illegal option --rmconfig". It responded, "portmaster doesn't have a direct equivalent to make rmconfig. However, you can manually remove the configuration for a port by deleting its options directory under /var/db/ports."

ok, read the man page, unless you really enjoy being told the wrong things

Given the statistical nature of the LLMs, it seems consistent with the response to such a question will statistically likely to be "read the man page". Though it does seem one thing lacking about the current trendy LLMs is the lack of ability to say when they don't know something and to go elsewhere

I am reading the man page and still can't figure out what portmaster's equivalent to "make rmconfig" is.