00:02:59 Anyone having trouble with this site? https://wiki.freebsd.org/CoverityPrevent 00:03:23 Dimonax: i assume you're just getting varnish errors, too? 00:04:10 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 00:04:13 phryk: Yup. 00:04:46 I'm assuming someone is working on it. 00:05:15 I'm honestly not so sure. If memory serves the wiki is kinda-sorta deprecated, but I don't recall the specifics… 00:06:17 phryk: Is there another place I should be reading besides the wiki? 00:06:45 phryk: #comments on same line should be fine 00:06:59 Dimonax: i have no idea what CoverityPrevent is. usually it's a matter of figuring out what the right man page to read is… 00:07:29 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… 00:07:52 interesting, I'll have to fix that 00:08:05 ^^ 00:08:14 sorry to heap the trouble onto you :D 00:08:21 I'm just looking through the packages list to see what's available for static code analysis. 00:09:21 phryk: where does the tmpfs come into play in this setup, exactly? 00:09:34 kevans: it's defined in my /etc/fstab 00:09:54 "tmpfs /tmp tmpfs rw,mode=777 0 0" 00:10:20 I'm honestly not sure if mode=777 is a good idea, but that's beside the current problem^^ 00:10:24 ah, ok, so the geli issues in this dmesg were just to get it rebiited 00:11:08 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… 00:12:28 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 00:12:52 ahh, ok 00:12:55 (i want the setup to just keep running if i shuffle drives around) 00:14:01 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 00:16:30 kevans: huh, i actually looked into kern.conftxt and it doesn't mention tmpfs… 00:17:00 phryk: did you look for tmpfs or TMPFS? 00:17:01 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 00:17:14 kevans: oooooooooooooooooooooooooooh :D 00:17:49 yeah, fs are options rwther than devices 00:18:12 good to know^^ 00:18:13 this still shouldn't happen, I'll take a look at it, too 00:19:25 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… 00:19:47 can't even update my pkg because of that… can't get a current version of ports for poudriere either… 00:20:42 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 00:20:42 how's time look? 00:21:05 time or date? 00:21:10 both 00:21:26 time being shorthand for rtc =p 00:22:11 ntp is active, my laptop is actually a couple seconds behind because i don't have ntp[date] active on it… 00:22:35 csn you remove ca_root_nss? 00:23:08 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… 00:23:21 base has root ca bundle installed 00:23:46 ca_root_nss has net negative value these days 00:24:10 uh, that will also remove poudriere, qemu, git, gpg and a bunch of other things… 00:24:36 (userland is still on 11.2, that's the thing i'm currently trying to rectify) 00:24:45 ahh 00:24:52 nevermind, carry on 00:25:12 kernel base is on 13.1, tho. 00:26:12 guess I'll just pkg query -a %n >> some_file and later pkg install `cat some_file`… 00:27:15 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 00:28:45 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 00:31:35 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… 00:39:11 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… 00:39:26 that pkg is a fraud 00:39:42 it just invokes the pkg binary in /usr/local/sbin 00:40:08 then what's the point of pkg-static and why is it recommended to use it after doing major upgrades? 00:41:16 because it's statically linked, if any of your 00:41:26 critical .so are hosed you lose dynamic pkg 00:41:34 ah. alright. 00:43:02 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… 00:46:04 ah no, apparently pkg bootstrap -f, and cert validation actually works for that… 00:46:27 worked. :) 00:46:51 hah, and poudriere immediately pulls in ca_root_nss again^^ 01:23:41 phryk: I can't seem to reproduce the loader comment... I've tried both foo_load="YES"\t# comment and foo="yes" # comment 01:23:44 issue 01:27:02 kevans: huh, weird… well, at least we know it's not an issue on every system then… 01:27:23 oh, I have an idea 01:27:30 this was an 11.x world 01:27:42 kenv script.lang from userland? 01:28:04 I wonder if forthloader didn't actually handle inline comments 01:28:24 "lua" 01:28:51 11.x? this is on a server without X11 or other GUI thing if that's your thought. 01:29:02 oh wait, 11.x as in freebsd 11.x :'D 01:29:15 yeah 01:29:21 is it running an updated kernel *and* loader? 01:29:52 yes. i just replaced the old-style gpart bootcode thing with efi today. 01:30:03 hmm, funky 01:30:12 with loader.efi that i had in /boot after the upgrade 01:30:25 I don't think there's been any real changes to lualoader since 13 branched, but I'll take a gander again 01:39:55 good luck, sounds like it might be hard to find^^ 03:58:05 phryk: thanks mang! 05:58:55 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? 06:03:48 tuaris: i *think* that depends on the wait/nowait entry 06:11:32 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. 06:22:04 bad and resource heavy scenario 06:24:19 but in unix world threads has no such use like in windows/(probably linux kernel) 06:24:30 why, i dont know 06:24:43 "tcpserver".. hmm, never knew about that one 06:24:47 trading entire process to connection versus 1024k stack space 06:32:47 dvl: launching a jail is easy, but I think technically, even a chroot env would do. Ultimately, you just need two sets of binaries 06:56:36 hm, is the form down? 06:56:49 "Page could not be loaded" 06:57:02 *forum 07:01:47 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 07:01:55 That's my first problem 07:02:41 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 07:02:58 I'm lost and dazed and confused and not sure how to proceed 07:21:03 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) 07:21:21 parv, yes I have a full repo 07:21:41 yes that's what my local git shows, but I don't see when searching on git hub 07:21:59 I'm probably just doing something wrong 07:23:01 I see that at "cgit": https://cgit.freebsd.org/src/commit/?id=3e5300e0ed3c4b49e3b0dab7daded1e3bfaaded7 07:23:02 Title: src - FreeBSD source tree 07:26:38 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? 07:27:19 yes /usr/src/Makefile 07:28:24 Ok 07:29:54 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 07:30:00 this is my first time try to git bisect 07:37:31 Wish I could help you with "git-bisect" :-( but have yet to use it 07:41:27 parv no problem, but thank you for trying 07:55:49 Hey, I've got a usb dj mixer I want to use with mixxx, how can I configure it in FreeBSD? 07:56:57 This is the dmesg output for the device https://dpaste.com/7MUEG8BJ8.txt 08:33:22 jeffpc: i created this: https://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 08:33:23 Title: Unofficial FreeBSD pkgbase repository 08:37:32 anyone? 08:37:47 when I click on controllers in mixxx it can't see anything 08:37:58 so I need to make freebsd turn it on 09:58:46 CCFL_Man: yw :) 11:48:11 Plasmoduck: did you check device permissions? 11:48:55 how? 11:49:27 it should be in /dev and your user probably needs permissions for it (might be a group) 11:49:55 I cannot really think of anything else at the moment :\ 11:51:10 ok what am I looking for in /dev? 11:51:23 I found a thread https://forums.freebsd.org/threads/usb-midi-controller-not-recognized-by-daws.59560/ 11:51:25 Title: Solved - USB MIDI controller not recognized by DAWs | The FreeBSD Forums 11:51:40 weird 11:52:08 oh, you might need that jackd thing 11:52:43 umidi0.0 11:53:38 it seems like mixxx supports JACK 11:53:54 you may want to try adding it between your controller and mixxx 11:53:55 so I need jack_umidi-1.1.1_1 ? 11:54:14 I have no idea, sorry, never tried anything MIDI with FreeBSD 11:54:24 but the forum post should give some pointers 12:01:49 Plasmoduck: if you are running mixxx with jack, yes, you need jack_umidi and then run it with jack_umidi -d /dev/umidi0.0 12:02:26 If it uses alsa, then you probably want alsa-seq-server 12:02:43 yep so I jack working 12:02:59 but mixxx still doesn't show my mixer/scratcher 12:03:23 do I need to add myself to some group? 12:03:29 I never used mixxx so I can't help 12:03:42 ls -l /dev/umidi0.0 and post the output 12:04:08 I think 13.1 got patch to fix permissions 12:10:01 im not on 13 12:10:22 crw-r--r-- 1 root operator 0x29b 24 Sep 21:57 /dev/umidi0.0 12:10:32 Ah, that makes sense 12:10:46 Wait I had config for that, too, let me try and find it 12:12:44 Plasmoduck: https://bsd.to/ZAsx is from /etc/devfs.rules 12:12:45 Title: dpaste/ZAsx (Plain Text) 12:13:02 You will probably have to restart devfs service 12:15:54 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' 12:15:59 do I need to reboot? 12:16:57 not devd, devfs 12:17:26 oh oops 12:18:08 okay, restarted devfs and same thing crw-r--r-- 1 root operator 0x29b 24 Sep 22:17 /dev/umidi0.0 12:18:28 oh yeah, sorry, there is something in rc.conf 12:20:05 devfs_system_ruleset="5" 12:20:40 ah, wait, wrong again devfs_system_ruleset="localrules" 12:25:21 ok now what? 12:25:36 restart devfs again and see if permissions are OK 12:25:43 same thing 12:26:35 Plasmoduck: I remembered I have it written down: https://meka.rs/blog/2017/06/17/freebsd-usb-midi/ 12:26:37 Title: meka - Goran Mekic - hacker and a musician 12:26:48 Sorry for being slow, dealing with hangover here 12:27:03 all good 12:27:54 it says to reboot 12:27:57 brb 12:31:25 back, still same crw-rw-rw- 1 root operator 0x281 24 Sep 22:30 /dev/umidi0.0 12:32:14 but rw-rw-rw- is exactly what you need 12:32:33 ok 12:32:46 cool 12:33:14 I don't know what mixxx requires, but you can check midi works 12:33:38 You can use https://reviews.freebsd.org/D36195 for that 12:33:39 Title: ⚙ D36195 The simplest OSS MIDI example 12:34:16 it will just print note/controller data to console 12:34:44 or even simpler, cat /dev/umidi0.0 should spew out garbage when you change your controls 12:35:38 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 12:35:55 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. 12:36:33 yeah its not working, cat /dev/umidi0.0 12:37:29 oh actually, it only shows stuff for one button, the cross fader 12:38:49 meena: very cool; thanks for working on this 12:39:23 if it isn't clear, I look forward to pkgbase being the way to manage the base 12:39:25 :) 12:40:16 pkgbase is gonna be nice if you have a laptop and a buildserver. 12:40:18 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 12:40:33 Building just what you need without clang et al is gonna keep FreeBSD nice and swelte. 12:41:32 IMO just having one way to update the whole system is going to be sweet 12:41:52 Plasmoduck: can you "ls -l /dev/umidi1.0" 12:41:59 instead of freebsd-update multi-step process followed by pkg update/upgrade 12:42:36 No such file or directory 12:43:00 its /dev/umidi0.0 12:43:43 Sometimes hardware expose multiple MIDI devices so I'm just checking 12:43:49 No idea at this point, honestly 12:43:50 ok 12:44:08 yeah, I think maybe it's just not supported 12:44:13 I give up 12:44:29 You definetely needed those umidi permissions set, but I don't know what you could try next 12:44:45 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. 12:46:52 right, it is a bit of a shift in perspective; we'll see what it actually looks like when it hits a release 12:48:32 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. 12:49:13 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. 12:49:26 Since I only have a laptop, it looks like pkgbase isn't for me. 12:49:46 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 12:49:47 The buildserver can build FreeBSD in.. minutes, especially if you strip out things by using WITHOUT_ in make.conf(5). 12:50:05 V_PauAmma_V: unless you can find someone who you trust and who'd be interested in building things for you. 12:50:38 jeffpc: might've been missed in ObsoleteFiles.inc 12:50:54 debdrup: but other jails on the same box upgraded fine 12:51:00 Huh. 12:51:05 * debdrup shrugs 12:51:15 debdrup, I found that someone already. It's releng and the infra people. :-) 12:51:21 V_PauAmma_V: :) 12:51:35 If you're happy with -RELEASE, there's absolutely no reason to use anything else. 12:51:51 Once 14 hits -RELEASE, I might go back to it, we'll see. 12:52:20 I like not being any more of a sysadmin than I strictly have to. 12:52:24 pkgbase also makes it easier to build ones own releases of FreeBSD that're minified the same way I mentioned earlier. 12:52:36 V_PauAmma_V: that makes sense. 12:52:40 if I change my hostname in rc.conf can it mess anything up? Like existing config files or programs functioning? 12:52:59 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. 12:53:06 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) 12:53:10 FWIW: https://bsd.to/Kwnj 12:53:11 Title: dpaste/Kwnj (Plain Text) 12:53:29 * debdrup shrugs 12:53:34 :) 12:53:37 If it ain't broke, et al. 12:54:18 yeah, at some point I'll probably reinstall the jails from scratch, so I don't care much :) 12:54:48 Well, that sentence can go two ways; either "don't mess with it", or "tweak it until it breaks" ;) 12:55:02 :) 12:55:51 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 13:00:12 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) 13:27:26 Plasmoduck: it is a good idea to make sure the hostname you set in rc.conf resolves (via /etc/hosts for example) 13:28:13 forget about rules you have rc.local! (touch /etc/rc.local && chmod a+x /etc/rc.local && echo "fortune" >> /etc/rc.local) 13:28:23 oopts 13:28:28 #!/bin/sh al so 13:35:10 oh no I just accidently deleted my /etc/devfs.conf 13:35:15 how can I get it back 13:36:16 find /usr/src -name devfs.conf and copy it over 13:38:00 thanks 13:45:28 If you use periodic snapshots, there's also .zfs 13:48:53 debdrup: I need to learn all that 13:49:10 I'm going to order the FreeBSD ZFS book 13:49:47 alterantive is you could pop a vm and just keep prototype trying stuff to find out what works :) 13:53:38 true 13:54:06 plus you get to cock about with bhyve 13:54:10 which is always fun 13:55:47 I need to get some more Thinkpads, one for FreeBSD 13* and one for OpenBSD. 13:55:59 mhmmm 13:56:03 I mean on the note of bhyve 13:56:13 you could just run a thin hypervisor and do both 13:56:17 or simply dualboot 13:56:20 as old school as that is 13:56:50 I took to installing all my bsd's and linux's on usb pens, so my carbon x1 runs windozer 11 normally 13:56:55 but I can boot into whatever 13:57:23 256G of space on a usb pen x-x insane 13:58:28 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 13:58:31 i.e. bootkey only 13:58:42 mount a slab of space on the internal nvme's 13:58:49 and you won't cock the bootloader up that way 14:02:06 I have an X1 Carbon also, Gen 4 14:02:29 ah mines a gen 6 I think 14:02:40 im not actually sure x-x 14:02:53 wonder if it says on the back 14:03:25 X1 carbon Gen 1 here :-D 14:04:44 yep it says it on transparent writing on the black back of the case 14:04:46 thanks lenovo 14:04:48 6th gen 14:04:49 lol 14:05:07 nice 14:05:15 I want to upgrade to that model 14:05:31 apparently a 20KH-007BUK 18/11 14:05:40 in a weird way its not even mine I gave it to the mrs 14:05:57 she started a job at the same company I work for (I know weird right) 14:06:10 and I know what laptops they give to employees (horrible asus bricks) 14:07:24 its always mystified me why companies give such cheap crap hardware out to employees 14:07:56 the difference between something decent being so small and all 14:08:08 but eh not my department -_- 15:23:38 daemon: I used an Asus laptop from 2007 to 2014 and gave it away to an acquaintance, and they are still using it 15:24:04 everything works, from the DVD-RW to all USB ports and wifi etc. 15:25:53 (tbh your definition of cheap scares me, I paid €1900 for that machine) 16:18:28 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 16:21:09 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. 16:22:12 mhh, the obscure package might be jack_umidi but it's been at least half a year since I fiddled with the midi keyboard…^^ 17:09:32 https://github.com/hselasky/jack_umidi this sure is tiny and nice 17:09:33 Title: GitHub - hselasky/jack_umidi: Raw MIDI to JACK daemon 21:12:51 The whole sshd needing to be reset for upgrades to 13.1 has been fixed in the upgrade/installer right? 21:16:36 er ok.. still needed in 13.1 userland install 21:22:21 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... 21:23:22 rwp: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263489 https://www.freebsd.org/releases/13.1R/relnotes/ look at Upgrading from Previous Releases of FreeBSD 21:23:24 Title: 263489 – sshd does not work after reboot to 13.1-RC4 21:23:45 Just reboot or restart sshd after userland install. 21:25:10 Even though I think that service sshd restart isn't correct. 21:25:11 Thanks for the heads up about it. sshd not accepting new connections feels very odd! 21:28:34 Check the release notes. I think 13.1 has a different OpenSSH version. 21:29:40 Reading through bug 263489 has more details. Looks like it is something between OpenSSH <8.2 to >8.2. 21:29:41 263489 – sshd does not work after reboot to 13.1-RC4 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263489 21:30:05 And FreeBSD 12.3 has 7.9 and 13.1 has 8.8 so that definitely crosses that threshold of OpenSSH versions. 21:52:58 rwp: Ok nm.. I confirmed it's all good. And restart after userland restores sshd. 21:57:21 Thanks skered. I reviewed the OpenSSH notes but don't see the root cause in the 8.x series. 21:58:17 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. 21:58:34 In the meantime I got distracted by working on other problems! 22:19:31 yeah, ok... one of the jails is very messed up and not fully upgraded: 22:19:33 ld-elf.so.1: /lib/libc.so.7: version FBSD_1.7 required by /usr/local/lib/libpython3.9.so.1.0 not found 22:21:39 libc.so.7 has only up to FBSD_1.6 22:21:53 but when I run freebsd-update -j $jail fetch, I get: 22:21:54 No updates needed to update system to 13.1-RELEASE-p2. 22:22:30 is there a way to force freebsd-update to replace files instead of whatever optimization it is doing? 22:22:54 rwp: It's this https://github.com/openssh/openssh-portable/commit/c2bd7f74b0e0f3a3ee9d19ac549e6ba89013abaf 22:22:55 Title: upstream: Add a sshd_config "Include" directive to allow inclusion · openssh/openssh-portable@c2bd7f7 · GitHub 22:23:29 As long as you're not exiting the session that does the userland install or you reboot it's fine.