I’m trying to get sound working on a Yoga 7 15ITL5 alc287 Realtek.. I think I’ve done everything out there as far as device.hints in trying different search methods in different search engines but they ask come up with the same thing.. nothing.. here is a snippet forums.freebsd.org/threads/trying-to-get-sound-working.98228

oxbar: what does dmesg say

and what does pciconf -lv say

dmesg should show some info if its supported if its not you have 2 options add in the PCIID to the driver and recompile or build your own driver for that device

or option 3 youre SOL

and if you are going to use freebsd as your main machine always do a apropos x or man snd to see what freebsd actually support as comparing to Linux well we dont have the same HW support

cpet: I’m sol I’ve tried all the quirks device.hints etc… it’s cool I have another laptop slow with spinning hard drive but everything works out the box

This is my only hope forums.freebsd.org/threads/intel-ti…-alc3306-alc287-audio-success.93333

oxbar: if it orks submit a patch

oxbar: current has support for it

looking at my hdac.c i seed it shows Tiger-Lake-H

Hey friends. I need some help regarding GeoDNS mirror optimization. Please have a look at the details here: antranigv.am/posts/2025/06/analyzing-freebsds-package-mirror-geodns

So I have a StarPRO64 here that allegedly boots FreeBSD, and installed the Risc-V memstick image. I have an UART-interface plugged in. But I have pretty much no UART experience. Does FreeBSD automatically activate UART, and can I install it via it?

s/installed/dd-ed on a microSD/

uart should work automatically

Pfft... I didn't get anything over UART, decided to plug in a HDMI cable after all - and now the damned thing doesn't turn on anymore. Even when I remove the HDMI.

have you considered an exorcism? :-)

Heh, that's probably the only option left...

I got two boards. A Star64 and a StarPRO64. I foolishly tried the same with the other board - same result, won't turn on anymore.

LEDs on the Star64 turn on, though, when I plug in 5V and GND of my UART connector. Power plug does nothing, however. Actually the LED on the power brick turns off as soon as I plug the SBC in.

Why do I keep doing this to myself? I should find some old mountain farmer who needs a successor.

mountains take really, really long to grow though

zilti: don't plug in the 5V from your uart connector

it sounds like you are either powering hte board from your uart adapter (which probably won't work) or powering it from both the uart adapter and a power supply

interesting. I've a RockPro64 but didn't know the Star64 could run FreeBSD

which will break things

[tj]: I did not plug them in at the same time, at least

I'd be careful with any 5v source around board io

maybe wait a bit and see if they boards will come up? you might have tripped a fuse and it'll reset

Yeah, I'll wait for a bit

Howdy. DoI understand from usb_template(4) that it’s not possible to act as, say, a mouse and keyboard at the same time?

Sigh. “Do I understand…”.

That is, only one template active at a time, I suppose.

thats how I read it, but there are multi role template

s

Right, but you get one of those combinations only, right?

Happy FreeBSD Day! freebsdfoundation.org/freebsd-day

anth: yeah, as far as I can tell. I don't think this is a usb standards based thing and you might be able to add a new template or a multi template role

I've never really investigated this

I found the template code but am missing where the numbers are mapped to what’s included.

hey all

what is the recommended way to monitor zfs for faults and send email alerts on freebsd? On Linux I have used zed, but that doesn't appear to be available. I see there is zfsd for detection, but I don't see anything about alerts.

I have a laptop with modern Intel GPU, and it's running -CURRENT. When loading drm-66-kmod, the system panics. I'm wondering if I should compile src from scratch or if I can just use PkgBase. the problem is that PkgBase is at 1500048 while the packages are stuck on 1500043. meanwhile the current system is on 1500045

when the usb template stuff came in I really wantedit to do something different, but I was never really able to pin down what I wanted done differently and haven't spent any time investigating it

anth: you should look here: github.com/obdev/v-usb/blob/master/usbdrv/USB-IDs-for-free.txt

I found it by searching for MULTI_DEFAULT_PRODUCT_ID 0x05dc in usb_template_multi.c

it doesn't align with usb template, but its probably a good starting point

But if I wanted a new combination, I’d need a new template number in the FreeBSD code, yeah? I’m trying to find *those*.

say I want to build FreeBSD from src, but I really don't wanna do the CLANG stuff. suggestions? is it just WITHOUT_CLANG_FULL?

anth: I've gotta go, if you want to fire an email at me I can do my best to help a bit tomorrrow (thj⊙fo)

ok looks like I needed WITHOUT_TOOLCHAIN and WITHOUT_CLANG

anth: sysctl_hw_usb_template is the sysctl handler, I grepped for the sysctl description string to find it

well, guess I'm gonna send both boards back.

I plugged the StarPRO64 back in, only the power and nothing else, and it crackled, I saw a spark, and now it smells of burnt electronics.

This further extends my absolutely terrible track record with Pine64

[tj]: thanks, I’ll keep poking for a bit.

I don't want to reboot one of my boxes now because it's annoying to have to go into the syncthing jail (which runs tailscale) and put the resolv.conf back to default so it can get networking again. I suspect it's because i have tailscale running on the host too, but I'm not sure. Now, all normal, running tailscale on host and in jail, the syncthing

jail's resolv.conf has nameserver 100.100.100.100 (and search domains). After a shutdown -r now, the syncthing jail's resolv.conf has no nameserver nor search domains. And the jail startup process (bastille going through and starting each jail) has stopped too. after shelling into the syncthing jail, putting the correct default nameserver, and

running service routing restart, i can exit the jail and the remaining jails have already started up, and the syncthing jail's resolv.conf now is set according to tailscale with nameserver 100.100.100.100 along with the correct search domains. Perhaps a shutdown issue. If I stop the syncthing jail, the jail is left with a resolv.conf with no

nameserver nor search domain. Starting the jail back up again, I must manually edit the nameserver into the resolv.conf and restart networking (or add back the nameserver line prior to starting the jail).

So.. does anyone else have tailscale running in a jail and tailscale fails to clean up after itself, putting resolv.conf back how it found it?

[tj]: Okay I found the template mapping: it’s the enum in sys/dev/usb/usb_ioctl.h.

I had initially expected some sort of mapping, like “Ethernet is enabled in template X and Y”, but each template is really its own thing and enables the devices it wants.

I suppose that makes testing a lot nicer, but it’s unfortunate to have to enumerate every combination you want with a new template, repeating some of the setup code.

Still, not too bad. There aren’t *that* many.

[tj]: thanks for the pointers.

i wonder if there's some way we could've made the template # a bitmask and done combinations that way

FYI: forbes.com/sites/daveywinder/2025/0…passwords-leaked---change-yours-now

nerozero: MOTHERFU-

if you have google/insta/face/ ... etc accounts - change passwords asap

WTF, who stores passwords unhashed in this day and age?

That Forbes article is amazingly lacking in detail. How are Apple, Facebook, Google sharing passwords hash or otherwise?

i have a really hard time trusting any tech journalism in the world of AI-enrichment

"... housed in a number ion supermassive datasets..." "ion"? They couldn't grammar check the article at least?

I think it likely that a historical cache of previously ex-filtrated account+password data had been discovered. Since a collection of all of the previously exposed data would be huge.

rwp: reading the article, it seemed fairly clear this is from infostealer malware, not (e.g.) a hack of Google etc

which also means if you're on that list, just changing your password may not be enough, you also need to make sure the malware is gone

keep the malware just change your password daily

(TM)

also, don't use "login with google account" (and similar) options on "3rd-party" services.

+1

antranigv: shouldnt need sounds more like your downloaded the wrong source for the drm driver

jbo: dont use google period

anything google, anything cloud, anything that requires a login to do anything = bad

thumbs: should of just said up

would made it more amusing than +1

thumbs: up

see what I did there ?

I defy expectations.

well yeah your on libera.chat

:)

ivy, So the credentials are stolen by having malware (keyloggers, etc) on your machine. D'uh!

depends on what services you use my proton account is connected to a yubikey which akes it harder but not impossible to still break into

i say this as there was an security issue a few months back regarding the firmware of recent yubikeys

and this said issue affects a batch that a new fw wont fix

the only google service I use is youtube

cause well its youtube ;/

but to be fare with all the ad crap youtube is putting out i may have to use one of those alternative youtube services cause ads are annoying

and to be on topic

freebsd is cool

the yubikey vulnerability could be bad, but it depends on who you are plausibly up against

there was a much worse one years ago where keys generated on the device were predictable

i submit a email to the lists from freebsd-multimedia⊙fo and it didn't post to the list/archive.. i just submitted one .. how long should i wait ?

cpet: freetubeapp.io, ymmv on a freebsd desktop though

no account required and no ads with this

...

dstolfa, so let me get this right... these days we usually get "native desktop apps" in form of web based technology wrapped in a heavy stack like electron stuff so you don't need to use a browser. but now we get a desktop app for something that actually should be web based? -__-

yes

jbo: pretty much

i'd be more than happy to just use the web interface, but youtube's web interface is actively user-hostile (:

dstolfa: i really dont ant to download videos

i want to stream

cpet: this isn't downloading videos

it's streaming, it's just an electron thing that allows you to do a bunch of things without an account which yt's web interface doesn't.

but again, it's electron so ymmv on freebsd

ymmv always applies no matter the OS

it's like taking any vehicle and then strapping a 2 ton trailer on it - so the milage varies :p

(I know that's not what you meant - sorry)

okay so we rebuilt world and kernel and installed them, I also rebuilt and installed drm-66-kmod from ports

but now we're getting a black screen

(we used to get kernel panic)

any tips on debugging?

no we can't ping it, we can't SSH to it, and it doesn't respond to Ctrl-Alt-Delete

the device in question is "Meteor Lake-P [Intel Graphics]"

If you can't ping it and can't ssh into it that implies that the kernel though it may not have panic'd that the kernel is wedged up regardless. That's more than the graphics being broken.

Last time I tried suspend was on 12 (I need to do it again on 14, will soon!) the machine resumed, had networking, but had only a black screen, it was the graphics module that was the problem.

Since yours is not pinging I suspect there is more to it. I would remove all listed kld modules to be loaded and then try suspend-resume in as simple of a mode as possible and see if that works.

That is, don't load your newly compiled drm-66-kmod and see if it works without it.

got it! will test all those

I will also try the new 6.8 drivers which are tagged in GH but not in ports yet.

why isn't my message showing in the multimedia mailing list ? this is my second time in 1 week i think

is it permissions ?

oxbar: are you subscribed? are you sending from the same address you're subscribed from?

yep got the welcome email and everything

Welcome to freebsd-multimedia⊙Fo

oxbar, If things don't sort out write to <questions+help⊙fo> and get help from the humans who maintain the list.

(I am not one of those for FreeBSD but I am one of those for other communities and we welcome involvement when there are problems.)

Thanks

hi, would someone kindly post the output of: # su - someuser --help

(to compare with equiv on linux)

joe@freebsd ~> su - joe --help

Illegal option --

thank you

aiui, args after the username should be passed to the shell not parsed by su. i was trying to verify that.

that is correct, which is why 'su user -c /bin/ls' works

right ok, because freebsd su has different behaviour for the -c switch.

you mean the -c option to su(1) itself?

Hmm... I get the same usage output on Rocky, MacOS and FBSD when I try: su - username --help

... from root, anyway.

Well, not the same usage output. But, on all three they report su - user usage.

This is FBSD 14.3, though. Lemme try on a 13.x.

On 13.x, I do get "Illegal option --"

So, something's changed.

where doe the "Illegal option --" come from, su? or the shell?

the shell, because everything after the username is passed to the shell

btw, i chose --help simply because both linux su and bash have this option.

Well, I tried with csh, sh, and zsh on FBSD 13.x and they all report "Illegal option --"

Using zsh or bash on linux, mac, FBSD 14.x, they all work.

Lemme try sh, csh on 14.x.

3!freebsd15 ~# su - ivy --version

zsh 5.9 (amd64-portbld-freebsd15.0)

So, it's likely somehow coming from "su" itself?

no, it's coming from the shell

sh, csh, bash, and zsh all produce the same usage output on 14.3.

how are you testing that? the output i showed just above clearly shows it's being passed to the shell

ivy: Log in as root, run: su - username --help

From the error output (Illegal option --) I would absolutely assume shell.

ek: that shows the output of 'zsh --help'

(or --version)

checked on 14-STABLE, same behaviour, i don't have any 14.2/14.3 systems to check

but this has been the because of Unix su since basically forever

s/because/behaviour

ivy: But, I'm not using zsh?

except on linux we get the su help or version :P

ek: you just said you checked with zsh?

ek: maybe we are talking at cross purposes

ivy: Yes. I did. As well as sh, csh, and bash.

They all produce the same su usage output.

ek: so when you run "su <username> --version" and <username>'s shell is /usr/local/bin/zsh, you don't get the zsh version output?

For example, on 14.3, my root's shell is csh. I log in, "su - user --help" gives me su usage.

ek: can you try: su - user -- --help

ivy: Lemme check. That very well may be the case.

i changed toor's shell to /bin/csh to test:

Or, even better, lemme just create a test user without any special shell.

6!freebsd14 ~# su toor --version

tcsh 6.22.04 (Astron) 2021-04-26 (x86_64-amd-FreeBSD) options wide,nls,dl,al,kan,sm,rh,color,filec

teknix: i would be mildly but not very surprised if Linux breaks this, but like i say, the FreeBSD behaviour is the behaviour of pretty much every other Unix, as far as i'm aware

There we go! I thought I was taking crazy pills!

ivy is correct (as usual.) Eliminating special shells that accept "--help" kicks out the "Illegal option --"

ivy: Thanks!

ek: np, good we cleared that up because i wondered if i was missing something obvious :-)

so the shell was giving you su usage?

teknix: No. I was recieving the shell's usage, not su's.

also, the shell will call itself "-su" when it's invoked via su, which might confuse things:

I was wondering why it kept spitting out shell options in "su's usage". Seemed... strange.

2? 10!freebsd14 ~# su toor -c /nonesuch

su: /nonesuch: not found

this error is from sh, not su

(because argv[0] is set to "su")

Yep. Makes sense.

# su - nobody --version

su from util-linux 2.38.1

that's actually pretty unhelpful and i wonder if we should change it... does anything really compare argv[0] to "su" to discover if it's running under su?

ivy: ^

teknix: i am mildly but not very surprised :-)

teknix: but then how do you do 'su user -c ls'? su user -- -c ls?

ivy: yes, but it kinda doesn't matter afaict

oh, because Linux 'su' has its own -c option?

because parsed and passed is ultimately same behaviour.

i can see this would be confusing if are moving between linux and other platforms

su usename -c .... should be exact same according to man page.

this may actually not be the fault of Linux su but rather glibc's getopt(), which iirc does its non-standard "you can put an option anywhere" parsing by default

e.g. i believe you can do "ls /etc/passwd -l" on Linux

Well, su is iffy all over the place between systems.

yes, i imagine so.

(i don't have a Linux system around to check, but i definitely remember this behaviour)

As is sudo. I need to test more with "doas" which a lot of smart people swear by.

ek: phfft, doas is so last week, you should be using mdo :-P

But, "sudo su -" is handled very differently than "sudo -i" depending on the system.

ivy: Haha.

according to linux man page args after the username should passed to the shell, just as with bsd, but evidently this is not happening.

Be patient with me. I'm from the 1900's!

teknix: yeah, i suspect this is glibc's fault, assuming your Linux uses glibc or something that copies its behaviour. i'm not sure if su itself is able to work around it

perhaps this is why Linux su has the duplicate '-c' option, to make this continue to work

could well be

It does seem like a snafu. Why would simply passing "--help" as a command after 'su' make any sense? It should error.

on a completely unrelated topic, i wonder what this device is: ugen0.4: <Linux 5.4.62 with aspeedvhub SMCI HID KM> at usbus0

--help (get out)

ek: well, it's passed to the shell, so if the shell is zsh or bash (etc) you'd expect it to work

ivy: Sure. If it includes argv[0], right? If it doesn't, wouldn't it be the same as simply typing "--help"?

ek, try this: sh --version

ek: it always includes argv[0], it's just set to "su" or "-su"

And I mean try it on FreeBSD. It will produce "Illegal option --".

Ah, I see!

su always loads up the target user shell, which is configured uniquely per user and could be any of those shells.

you can't emit argv[0] or nothing will work... like if you run "su user -c /bin/ls' then argv[0] = "su", argv[1] = "-c", argv[2] = "/bin/ls"

s/emit/omit

i really dislike this argv[0] = "su" behaviour, i am going to see if we can fix that

On my system I have toor set to bash from ports and leave root set to sh in base. Because I broke ports bash once.

rwp: That makes perfect sense. Thanks!

ivy, That's the traditional behavior since forever though. People don't like change!

rwp: i dislike breaking backward compatibility, but in this case i think the current behaviour has a high confusion potential and almost zero practical utility

rwp: Yep. I've been there. I just call zsh from ~/.(c)shrc or my users. I leave root alone. Been locked out way too many times from botched upgrades or bad /root/.bashrc configs.

No thanks!

someone in another channel suggests this behaviour might be mandated by POSIX :-/

ek, That's why I left root alone by default and modified toor as a local modification. Someone might do it the reverse way though too. But root is the defaut in base and leaving it stock fit my sensibilities.

ivy: Which behavior? The additional -c option or the illegal option?

ek: setting argv[0] to "su"

ivy, Thinking about that it probably is mandated. Because it has always been that way and people do not like change.

ek: i.e. why "su root -c /nonesuch" prints "su: /nonesuch: not found"

argv[0] can be manually set, here at least: su user -c 'echo $0' foo

PSA: Always put a "-" option after the "su" as in "su -" when not executing a command and wanting to get a root shell, so that the root environment is sourced correctly.

It will then set -su as the shell name, and shells that start with "-" are login shells, and login shells source .profile or .login or whatever as appropriate.

teknix: no one is actually going to remember to do that though :-P i want to fix this specific behaviour of "su: /nonesuch: not found" because it really seems like the error is coming from su when it's not

rwp: That's *NIX 101, isn't it?

Been bitten by a simple "su" my first couple days in my teenage years.

If one does "su" *only* then one does not get that and one gets their previous environment in the new user shell. Which when jumping to root is probably not what is wanted. PATH is probably wrong in that case.

Exactly.

ek, It might be Unix 084 but there are a surprising number of people who don't know this and then complain that they are root but can't run any root level utilities. Because... no PATH set for it.

I have privs but no access to non-root path'd applications.

Meanwhile... I have always set the sbin's in my personal PATH (don't mind me, I void warranties) so as a side effect that actually works for me. But it isn't the way to do it.

Well, to be fair, I read Linux articles all the time that suggest: Use "su" to get root access before continuing

Well, to be fair, I read FreeBSD articles all the time that say "reboot" when they mean "shutdown -r now" and that's bad too.

Without actually explaining what they'll need access to. So, people new to *NIX likely have no idea. They're just looking for a quick fix to a problem or driver build/install or something.

rwp: not having /sbin:/usr/sbin in your non-root path is crazy imo. like do those people manually type "/sbin/ping" all the time?

rwp: I will agree with "reboot" being not ideal.

ivy, Right! Mostly I do this exactly for "ping"! :-)

actually, we should probably move ping and traceroute to bin...

I've never liked "reboot". But, I've also never used it because it wasn't an option back in the day. shutdown -r now is just my go-to. Even in Linux.

Regarding "reboot", the other command "poweroff" actually calls "shutdown -p now" making it an exception to the scheme.

ivy: Not a bad idea.

rwp: i hate this

rwp: "halt", "poweroff" and "reboot" should all do the same thing: either call shutdown or don't call shutdown and do it directly

"reboot" is actually hard to replace because reboot -r needs to be handled somehow. A powerful feature that I would not want to be without.

rwp: Yep. But, I still use "shutdown -p". Again, just kinda ingrained in my dumb mind.

we probably can't fix poweroff at this point so i think i support imp's proposal to make halt and reboot call shutdown, like Linux

at least then it's consistent

ivy, I was shocked when I saw that poweroff was not like reboot but actually did call shutdown -p now but meanwhile I had never used it before but always shutdown -p before. (And annoyingly it is "shutdown -hP now" on the Linux sysvinit side of the world.)

And we all definitely like consistency. Otherwise, why would we be using FBSD. :)

rwp: right, it's a POLA violation, because you really don't expect it to work that way

rwp: this also confuses people coming from Linux who are used to "poweroff" doing a proper shutdown and are then surprised that "reboot" doesn't, for example

(because if freebsd poweroff works like linux poweroff then why wouldn't reboot?)

On HP-UX (which shows my history) there was "reboot -q" for quick which did not call shutdown scripts. On Linux it is "reboot -f" for fast to not call shutdown scripts.

<3 HP-UX

i miss swinstall

You were good right up until you mentioned swinstall.

Haha.

i hosted my website for years on an old pa-risc desktop running 11.22 or something

rwp: swinstall still does things pkg doesn't, like subpackages

HP-UX 10.20 was the ultimate version of it. You won't change my mind about that. But swinstall was a huge behemoth. We used an interesting client-server network tool "ninstall" internally.

As far as linux users new coming to bsd now the new linux user will be using "systemctl reboot" and "systemctl poweroff" now. That's the current messaging from the "you will comply" community.

that's a bit of a straw man, i've never met a linux use who says "you must use systemctl reboot" and even if such exists, they are a tiny minority

It's strange to me that everything else about systemd is *you will comply* but they do still support "shutdown -r now" and don't make a fuss about it.

that's because the authors of systemd have never demanded anyone "will comply"?

I hate systemd but I do actually read the documentation and do use it daily and must continue to support it therefore I know it fairly well as a practical matter.

That's not my experience. Not by a lot. As a long time Debian user that community has become very aggressive about systemd now, systemd tomorrow, systemd forever, and everyone else must comply.

so your complaint is with Debian, not systemd

All of the advocates in Debian for systemd are the systemd developers. So... Same people!

But let's not fight over systemd here in #freebsd as that is off topic. Time to move on.

moving to a new build server, i thought i'd do a rebuild from scratch, but so far it's been 5 hours...

ivy: If you need rust, go, node, or anything like that, could be days.

ek: it doesn't help that i build 2 versions of gcc and 3 versions of llvm

(like, on purpose, not as dependencies)

although i really wonder what is depending on graphics/vulkan-loader...

Gotcha'. Even a pretty beefy machine that's gonna take some time.

yeah, it's a Xeon E-2468 which is not particularly fast but surprisingly faster than the Ryzen 2700X in my old builder

ivy: You know, I've often wondered the same thing. I see two vulkan ports being built all the time but "pkg info -r vulkan-\*" produces nothing. I haven't got a clue what requires it.

My first poudriere build for 14.3-RELEASE took over 13:35 hours. The old Dell server had a hard time building gcc, llvm, mysql, node, php, rust in parallel.

Schamschula: Was a RAM limitation issue or just limited on cores?

at least with 128GB of RAM i can enable TMPFS and boost parallel jobs a little, so it's using CPU more efficiently

Cores. The machine has 64GB RAM

I'm also guessing I/O bandwidth had something to do with it.

ivy: Same. My builder, while older, has 48 cores and 128G RAM. Still takes 45-50 minutes for rust alone, though. Still waiting for that ONLY_USE_PACKAGES_FOR_DEPENDENCIES options in Poudriere. :(

That wouldn't help with your multiple versions of llvm or gcc, unfortunately.

Well, unless the latest packages match the latest ports versions (which is rare.)

Schamschula: Ah, yes. I/O definitely plays a part on big builds.

At least you got it done!

On my server rust sometimes takes over three hours. My Mac Studio builds rust in well under 15 minutes, but MacPorts only builds one package at a time and uses all available cores for parallel builds.

\\

\

\kevans

\\\\\

\EFI\BOOT\KEVANS.EFI

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

\

hmm, cat detected?

ivy: thinking the same thing!

Who broke kevans!?

git rm -r bin/cat; git -am 'remove cat'

shit, sorry

that one was actually baby instead of cat, kind of imprssiv

your child is going to be a shell programmer :-/

=D

Which that many escapes, he's gonna love PHP as well.

s/Which/With/