Anyone having trouble with this site? wiki.freebsd.org/CoverityPrevent

Dimonax: i assume you're just getting varnish errors, too?

Dimonax: wayback machine on archive.org likely has a working snapshot of that page. worked for the UEFI page on the wiki a couple hours back. :P

phryk: Yup.

I'm assuming someone is working on it.

I'm honestly not so sure. If memory serves the wiki is kinda-sorta deprecated, but I don't recall the specifics…

phryk: Is there another place I should be reading besides the wiki?

phryk: #comments on same line should be fine

Dimonax: i have no idea what CoverityPrevent is. usually it's a matter of figuring out what the right man page to read is…

kevans: okay, they never did for me, and having 'tmpfs_load="YES" # comment here' in my loader.conf made it act as if the line wasn't in the file at all…

interesting, I'll have to fix that

^^

sorry to heap the trouble onto you :D

I'm just looking through the packages list to see what's available for static code analysis.

phryk: where does the tmpfs come into play in this setup, exactly?

kevans: it's defined in my /etc/fstab

"tmpfs /tmp tmpfs rw,mode=777 0 0"

I'm honestly not sure if mode=777 is a good idea, but that's beside the current problem^^

ah, ok, so the geli issues in this dmesg were just to get it rebiited

kevans: geli issues? you mean all the ada ones? i assigned the geli keys to gpt labels and there's no option to just ask for passphrase for devices that are actually configured in loader.conf…

it's super annoying and also the reason why loader.conf disables kern.geom.label.gptid.enable because those would come before the text-based gpt labels, making the whole thing even longer. :F

ahh, ok

(i want the setup to just keep running if i shuffle drives around)

yeah, so tmpfs is in the kernel, MOD_LOAD fails because of that but then we run sysuninits and actually kill parts of the in+kernel tmpfs, presumably

kevans: huh, i actually looked into kern.conftxt and it doesn't mention tmpfs…

phryk: did you look for tmpfs or TMPFS?

it does mention aesni tho, which is why i commented that out – but that option also didn't create any trouble with the current kernel when it was still active

kevans: oooooooooooooooooooooooooooh :D

yeah, fs are options rwther than devices

good to know^^

this still shouldn't happen, I'll take a look at it, too

mhh, I've run into a different wall with my update tho… all certificate validation fails. i assumed it was because ca_root_nss is so outdated, so i copied over the cert.pem from my laptop running 13.0 (device i'm writing from) – but that doesn't fix the issue and I'm not at all sure why…

can't even update my pkg because of that… can't get a current version of ports for poudriere either…

put the cert at the same location pkg query says ca_root_nss puts it and md5 /etc/ssl/cert.pem gives the same result on my laptop and the server… still, cert validation works on my laptop but not the server

how's time look?

time or date?

both

time being shorthand for rtc =p

ntp is active, my laptop is actually a couple seconds behind because i don't have ntp[date] active on it…

csn you remove ca_root_nss?

yes, but then i won't be able to reinstall, will i? a bit skittish as cert.pem doesn't seem to be all there is to it…

base has root ca bundle installed

ca_root_nss has net negative value these days

uh, that will also remove poudriere, qemu, git, gpg and a bunch of other things…

(userland is still on 11.2, that's the thing i'm currently trying to rectify)

ahh

nevermind, carry on

kernel base is on 13.1, tho.

guess I'll just pkg query -a %n >> some_file and later pkg install `cat some_file`…

for a long while I considered running 13.1 userland with dev kernel normally for stability, but I do enough one-off userland replacements that it doesn't make sense

kevans: the reason i started with poudriere is a mix of ideology plus the musicpd package from official sources (at least way back when) not supporting sqlite out of the box… nowadays it's mostly a thing of keeping things just in case of an apocalypse :P

mhh, so first pkg complained about the mismatch of the new .cert file i overwrote the old one with and said it wouldn't remove the package, but then pkg query didn't show it installed anymore and pkg remove says it's not installed either – cert validation still fails…

i think i might just be confused about pkg-static – i thought that was a guaranteed-to-work version of pkg within the base system… but pkg-static is in /usr/local/sbin while pkg is in /usr/sbin…

that pkg is a fraud

it just invokes the pkg binary in /usr/local/sbin

then what's the point of pkg-static and why is it recommended to use it after doing major upgrades?

because it's statically linked, if any of your

critical .so are hosed you lose dynamic pkg

ah. alright.

anyhow, pkg[-static] fails with "FreeBSD.meta has wrong version 2" – there's a pkg2ng executable which I surmise might be what I'm looking for, but no man page or --help for it…

ah no, apparently pkg bootstrap -f, and cert validation actually works for that…

worked. :)

hah, and poudriere immediately pulls in ca_root_nss again^^

phryk: I can't seem to reproduce the loader comment... I've tried both foo_load="YES"\t# comment and foo="yes" # comment

issue

kevans: huh, weird… well, at least we know it's not an issue on every system then…

oh, I have an idea

this was an 11.x world

kenv script.lang from userland?

I wonder if forthloader didn't actually handle inline comments

"lua"

11.x? this is on a server without X11 or other GUI thing if that's your thought.

oh wait, 11.x as in freebsd 11.x :'D

yeah

is it running an updated kernel *and* loader?

yes. i just replaced the old-style gpart bootcode thing with efi today.

hmm, funky

with loader.efi that i had in /boot after the upgrade

I don't think there's been any real changes to lualoader since 13 branched, but I'll take a gander again

good luck, sounds like it might be hard to find^^

phryk: thanks mang!

Does inetd starts a copy of each command as it's own process for every inbound connection? meaning I don't need to worry making sure my script has to handle multiple connections and forking each one?

tuaris: i *think* that depends on the wait/nowait entry

tuaris, correct, inetd forks for you. that is also the behavior of UCSPI tcpserver. inetd also allows starting the command once and letting it do the accepting in the future - tcpserver does not support this.

bad and resource heavy scenario

but in unix world threads has no such use like in windows/(probably linux kernel)

why, i dont know

"tcpserver".. hmm, never knew about that one

trading entire process to connection versus 1024k stack space

dvl: launching a jail is easy, but I think technically, even a chroot env would do. Ultimately, you just need two sets of binaries

hm, is the form down?

"Page could not be loaded"

*forum

I'm so confused! I'm trying to track down a kernel problem that prevents 13.1 release from booting on my board. I've found to commits one that works and one that doesn't so I'm trying to use git bisect to figure out where the issue was introduced. I've done git bisect start ; git bisect good foo; git bisect bad bar and then tried building the kernel but the build fails as Makefile is missing in my /usr/usrc

That's my first problem

then I try to look at the commit using git hub that gets checked out by git bisect. The commit is 3e5300e0ed3c4b49e3b0dab7daded1e3bfaaded7 which git find in my local repo but not in the git hub repo

I'm lost and dazed and confused and not sure how to proceed

crb, To start do you have the full repository (not the "shallow" kind)? As for the missing commit, I see that in my local copy of the repository ("Support Debian DKMS builds" of 2018)

parv, yes I have a full repo

yes that's what my local git shows, but I don't see when searching on git hub

I'm probably just doing something wrong

I see that at "cgit": cgit.freebsd.org/src/commit/?id=3e5…0e0ed3c4b49e3b0dab7daded1e3bfaaded7

Title: src - FreeBSD source tree

crb, By "build fails as Makefile is missing in my /usr/usrc", do you mean "/usr/src/Makefile" or some other Makefile elsewhere under the tree gone missing?

yes /usr/src/Makefile

Ok

So I was going to go to git hub and look at the failing commit and start trying to see why Makefile was missing, or indeed if it's missing in git hub, maybe it's something wrong with my local usage of git bisect

this is my first time try to git bisect

Wish I could help you with "git-bisect" :-( but have yet to use it

parv no problem, but thank you for trying

Hey, I've got a usb dj mixer I want to use with mixxx, how can I configure it in FreeBSD?

This is the dmesg output for the device dpaste.com/7MUEG8BJ8.txt

jeffpc: i created this: alpha.pkgbase.live but I'm currently back to working on adding better BSD support to cloud-init and don't have much time to work on PkgBase. that being said, it's constantly evolved in CURRENT and stable fixes and features are merged to STABLE

Title: Unofficial FreeBSD pkgbase repository

anyone?

when I click on controllers in mixxx it can't see anything

so I need to make freebsd turn it on

CCFL_Man: yw :)

Plasmoduck: did you check device permissions?

how?

it should be in /dev and your user probably needs permissions for it (might be a group)

I cannot really think of anything else at the moment :\

ok what am I looking for in /dev?

I found a thread forums.freebsd.org/threads/usb-midi…roller-not-recognized-by-daws.59560

Title: Solved - USB MIDI controller not recognized by DAWs | The FreeBSD Forums

weird

oh, you might need that jackd thing

umidi0.0

it seems like mixxx supports JACK

you may want to try adding it between your controller and mixxx

so I need jack_umidi-1.1.1_1 ?

I have no idea, sorry, never tried anything MIDI with FreeBSD

but the forum post should give some pointers

Plasmoduck: if you are running mixxx with jack, yes, you need jack_umidi and then run it with jack_umidi -d /dev/umidi0.0

If it uses alsa, then you probably want alsa-seq-server

yep so I jack working

but mixxx still doesn't show my mixer/scratcher

do I need to add myself to some group?

I never used mixxx so I can't help

ls -l /dev/umidi0.0 and post the output

I think 13.1 got patch to fix permissions

im not on 13

crw-r--r-- 1 root operator 0x29b 24 Sep 21:57 /dev/umidi0.0

Ah, that makes sense

Wait I had config for that, too, let me try and find it

Plasmoduck: bsd.to/ZAsx is from /etc/devfs.rules

Title: dpaste/ZAsx (Plain Text)

You will probably have to restart devfs service

ok I added that in /etc/devfs.rules and done 'service devd restart' but 'ls -l /dev/umidi0.0' still shows 'crw-r--r-- 1 root operator 0x29b 24 Sep 22:14 /dev/umidi0.0'

do I need to reboot?

not devd, devfs

oh oops

okay, restarted devfs and same thing crw-r--r-- 1 root operator 0x29b 24 Sep 22:17 /dev/umidi0.0

oh yeah, sorry, there is something in rc.conf

devfs_system_ruleset="5"

ah, wait, wrong again devfs_system_ruleset="localrules"

ok now what?

restart devfs again and see if permissions are OK

same thing

Plasmoduck: I remembered I have it written down: meka.rs/blog/2017/06/17/freebsd-usb-midi

Title: meka - Goran Mekic - hacker and a musician

Sorry for being slow, dealing with hangover here

all good

it says to reboot

brb

back, still same crw-rw-rw- 1 root operator 0x281 24 Sep 22:30 /dev/umidi0.0

but rw-rw-rw- is exactly what you need

ok

cool

I don't know what mixxx requires, but you can check midi works

You can use reviews.freebsd.org/D36195 for that

Title: ⚙ D36195 The simplest OSS MIDI example

it will just print note/controller data to console

or even simpler, cat /dev/umidi0.0 should spew out garbage when you change your controls

If you have MIDI hardware connected to your computer's MIDI out, you can "cat /dev/umidi0.0 >/dev/umidi0.0" to see if you can read and write to the device

it's still now working though, like on macos all the lights are on the mixer when it's connected. On FreeBSD, it only lights up when I plug it in for a second.

yeah its not working, cat /dev/umidi0.0

oh actually, it only shows stuff for one button, the cross fader

meena: very cool; thanks for working on this

if it isn't clear, I look forward to pkgbase being the way to manage the base

:)

pkgbase is gonna be nice if you have a laptop and a buildserver.

Plasmoduck: it means you can read whatever is coming from the controler, but I guess it's about figuring out why controler is not sending everything

Building just what you need without clang et al is gonna keep FreeBSD nice and swelte.

IMO just having one way to update the whole system is going to be sweet

Plasmoduck: can you "ls -l /dev/umidi1.0"

instead of freebsd-update multi-step process followed by pkg update/upgrade

No such file or directory

its /dev/umidi0.0

Sometimes hardware expose multiple MIDI devices so I'm just checking

No idea at this point, honestly

ok

yeah, I think maybe it's just not supported

I give up

You definetely needed those umidi permissions set, but I don't know what you could try next

jeffpc: the only issue is, it's kind of a violation of the whole idea that the BSDs have with a base system and third-party packages being separate, and I don't think it means freebsd-update is going away any time soon.

right, it is a bit of a shift in perspective; we'll see what it actually looks like when it hits a release

It certainly has its uses, there's absolutely no doubt about that - but there's also places where it doesn't make a whole lot of difference.

Like I hinted before, the best use-case for it if you've got a combination of a less-powerful system and a very powerful system.

Since I only have a laptop, it looks like pkgbase isn't for me.

actually, speaking of freebsd-update, recently I upgraded from 13.0 to 13.1, and some of my jails look funny afterward; some of the libs (e.g., /lib/libedit.so) look old but freebsd-update says that I'm up to 13.1-p2

The buildserver can build FreeBSD in.. minutes, especially if you strip out things by using WITHOUT_ in make.conf(5).

V_PauAmma_V: unless you can find someone who you trust and who'd be interested in building things for you.

jeffpc: might've been missed in ObsoleteFiles.inc

debdrup: but other jails on the same box upgraded fine

Huh.

debdrup, I found that someone already. It's releng and the infra people. :-)

V_PauAmma_V: :)

If you're happy with -RELEASE, there's absolutely no reason to use anything else.

Once 14 hits -RELEASE, I might go back to it, we'll see.

I like not being any more of a sysadmin than I strictly have to.

pkgbase also makes it easier to build ones own releases of FreeBSD that're minified the same way I mentioned earlier.

V_PauAmma_V: that makes sense.

if I change my hostname in rc.conf can it mess anything up? Like existing config files or programs functioning?

I don't think I do more than I strictly have to, so I guess I feel the same way, it's just a question of degree.

debdrup: in a way, I don't care - the jails work, but it does look like things aren't upgrading properly (likely because I screwed something up)

FWIW: bsd.to/Kwnj

Title: dpaste/Kwnj (Plain Text)

:)

If it ain't broke, et al.

yeah, at some point I'll probably reinstall the jails from scratch, so I don't care much :)

Well, that sentence can go two ways; either "don't mess with it", or "tweak it until it breaks" ;)

:)

They're dynamically loaded libraries, so if you were the paranoid kind you could always try renaming them, with the knowledge that you might have to boot to /rescue/init using a kernel environment variable in the loader environment if anything breaks. :P

it's actually more than just libedit.so; the nightly security email from one of the jails lists only 2 setuid files changing during the upgrade (which is wrong given that other jails listed a ton of files)

Plasmoduck: it is a good idea to make sure the hostname you set in rc.conf resolves (via /etc/hosts for example)

forget about rules you have rc.local! (touch /etc/rc.local && chmod a+x /etc/rc.local && echo "fortune" >> /etc/rc.local)

oopts

#!/bin/sh al so

oh no I just accidently deleted my /etc/devfs.conf

how can I get it back

find /usr/src -name devfs.conf and copy it over

thanks

If you use periodic snapshots, there's also .zfs

debdrup: I need to learn all that

I'm going to order the FreeBSD ZFS book

alterantive is you could pop a vm and just keep prototype trying stuff to find out what works :)

true

plus you get to cock about with bhyve

which is always fun

I need to get some more Thinkpads, one for FreeBSD 13* and one for OpenBSD.

mhmmm

I mean on the note of bhyve

you could just run a thin hypervisor and do both

or simply dualboot

as old school as that is

I took to installing all my bsd's and linux's on usb pens, so my carbon x1 runs windozer 11 normally

but I can boot into whatever

256G of space on a usb pen x-x insane

whats more if you want to be extra spicy, you can reduce the space the windows install uses, and use the usb pens as roots only

i.e. bootkey only

mount a slab of space on the internal nvme's

and you won't cock the bootloader up that way

I have an X1 Carbon also, Gen 4

ah mines a gen 6 I think

im not actually sure x-x

wonder if it says on the back

X1 carbon Gen 1 here :-D

yep it says it on transparent writing on the black back of the case

thanks lenovo

6th gen

lol

nice

I want to upgrade to that model

apparently a 20KH-007BUK 18/11

in a weird way its not even mine I gave it to the mrs

she started a job at the same company I work for (I know weird right)

and I know what laptops they give to employees (horrible asus bricks)

its always mystified me why companies give such cheap crap hardware out to employees

the difference between something decent being so small and all

but eh not my department -_-

daemon: I used an Asus laptop from 2007 to 2014 and gave it away to an acquaintance, and they are still using it

everything works, from the DVD-RW to all USB ports and wifi etc.

(tbh your definition of cheap scares me, I paid €1900 for that machine)

Plasmoduck: if memory serves, i had to install some obscure package and run it manually in my terminal for a midi keyboard to be recognized, but i just read through my complete package list and didn't recognize the name… :F

also, not sure if jack had to be running as it was needed for ardour anyways. i see in my rc.conf that i have jackd_user="phryk" in my rc.conf which IIRC was needed so programs run by my user could actually use jack.

mhh, the obscure package might be jack_umidi but it's been at least half a year since I fiddled with the midi keyboard…^^

github.com/hselasky/jack_umidi this sure is tiny and nice

Title: GitHub - hselasky/jack_umidi: Raw MIDI to JACK daemon

The whole sshd needing to be reset for upgrades to 13.1 has been fixed in the upgrade/installer right?

er ok.. still needed in 13.1 userland install

skered, Lurker here. What do you mean by "sshd reset"? As I was about to upgrade a system from 12.3 to 13.1 today...

rwp: bugs.freebsd.org/bugzilla/show_bug.cgi?id=263489 freebsd.org/releases/13.1R/relnotes look at Upgrading from Previous Releases of FreeBSD

Title: 263489 – sshd does not work after reboot to 13.1-RC4

Just reboot or restart sshd after userland install.

Even though I think that service sshd restart isn't correct.

Thanks for the heads up about it. sshd not accepting new connections feels very odd!

Check the release notes. I think 13.1 has a different OpenSSH version.

Reading through bug 263489 has more details. Looks like it is something between OpenSSH <8.2 to >8.2.

263489 – sshd does not work after reboot to 13.1-RC4 bugs.freebsd.org/bugzilla/show_bug.cgi?id=263489

And FreeBSD 12.3 has 7.9 and 13.1 has 8.8 so that definitely crosses that threshold of OpenSSH versions.

rwp: Ok nm.. I confirmed it's all good. And restart after userland restores sshd.

Thanks skered. I reviewed the OpenSSH notes but don't see the root cause in the 8.x series.

The machine today I have physical access to so no problem in any case. But I will look to see what if any errors are logged.

In the meantime I got distracted by working on other problems!

yeah, ok... one of the jails is very messed up and not fully upgraded:

ld-elf.so.1: /lib/libc.so.7: version FBSD_1.7 required by /usr/local/lib/libpython3.9.so.1.0 not found

libc.so.7 has only up to FBSD_1.6

but when I run freebsd-update -j $jail fetch, I get:

No updates needed to update system to 13.1-RELEASE-p2.

is there a way to force freebsd-update to replace files instead of whatever optimization it is doing?

rwp: It's this openssh/openssh-portable c2bd7f7

Title: upstream: Add a sshd_config "Include" directive to allow inclusion · openssh/openssh-portable@c2bd7f7 · GitHub

As long as you're not exiting the session that does the userland install or you reboot it's fine.