01:52:18 <nmz> Is there a way to get brasero working on freebsd or any GUI burner?
04:13:56 <voy4g3r2> okay, i think i am going crazy - when i execute this command: find . -name "@eaDir" -type d -prune -exec rm -rf {} \; i get an error find:17:command not found: ;
04:14:11 <voy4g3r2> for the life of me, i see no issue wit this command..
04:48:12 <_xor> RhodiumToad: You use ipfw, no?
04:49:22 <rwp> voy4g3r2, If using -prune I think it never makes any sense to follow it with a logical AND -exec, instead when using -prune I think it should always be followed by a logical OR with -o
04:51:51 <rwp> But that sidesteps your question about command not found.  That makes no sense either because rm would certainly exist.  Was it a strange character next to "find" that is causing find not to be found?
04:54:29 <rwp> voy4g3r2, I retract my statement now that I look more closely and see what you are trying to do.  Logical AND is what you wanted.  Sorry.  But then is there a bad character next to "find" causing find not to be found?
04:57:13 <voy4g3r2> not that i can see, but i retyped the command and got this error: find: rm: unknown primary or operator
04:57:28 <voy4g3r2> this synology device crash still haunts me
04:57:44 <voy4g3r2> i got tons of @eaDir throughout everywhere
04:58:01 <_xor> Which shell are you using?
04:59:10 <voy4g3r2> zsh
05:00:18 <rwp> Let me suggest using echo in front of the rm to see what commands it would run without actualling running it.  find . -name @eaDir -type d -prune -exec echo rm -rf {} \;
05:00:50 <voy4g3r2> ahhh
05:00:55 <voy4g3r2> i had a damn typo
05:00:55 <voy4g3r2> errr
05:01:25 <rwp> Every time you make a typo, the errorists win.
05:01:57 <voy4g3r2> haha, that is quite jarring as i have roger waters amused to death playing in background
05:02:01 <voy4g3r2> just the theme.. went dark
05:02:16 <voy4g3r2> but much cleaner now
05:03:02 <_xor> I thought you were talking about John Waters for a second.
05:05:25 <voy4g3r2> i was never a fan of his movies.. hairspray was okay
05:10:22 <voy4g3r2> that is if you are referring to the writer/director, this guy: https://en.wikipedia.org/wiki/John_Waters
05:10:24 <VimDiesel> Title: John Waters - Wikipedia
06:15:44 <mane> i need an openvpn mirracle man
06:58:08 <nerozero> mane have u tried transport UDP protocol ?
06:58:23 <mane> what you mean?
06:58:27 <nerozero> if it is set to tcp
06:58:38 <mane> i tried tcp, works much worse
06:58:39 <nerozero> proto tcp -> proto udp
06:59:09 <nerozero> yes with udp it works better
06:59:19 <mane> x))
06:59:20 <nerozero> out of options
06:59:39 <mane> XDDD
07:00:07 <nerozero> https://winaero.com/speed-up-openvpn-and-get-faster-speed-over-its-channel/
07:00:10 <VimDiesel> Title: Speed up OpenVPN and get faster speed over its channel
07:00:21 <nerozero> have u red this article ?
07:00:35 <mane> bookmarking
07:00:35 <mane> <33
07:04:56 <nerozero> also follow the comments
09:28:24 <moviuro> Hi all, what's the best way to move to EFI on a system that only has a 4 drive raidz1 ATM? (and free USB slots) gpart(8): https://x0.at/-jBt.txt
09:44:14 <dch> mane you will likely get slightly better perf with wireguards if thats an option
09:45:18 <dch> moviuro: 90% of the disk space needed for UEFI boot is /boot/loader.efi, a single file thats written to a FAT12 or FAT32 partition, of "EFI" type.
09:45:22 <CDiMa> hi! I'm having troubles on my 14.0-RELEASE-p3 system,
09:45:59 <dch> moviuro: so in principle you could add an EFI partition into /adaX/**** the 492K bit
09:46:34 <dch> moviuro: format it appropriately, and copy loader.efi in as .../EFI/BOOT/BOOT64.EFI and this will work
09:47:03 <dch> moviuro: you will also need to check & adjust partition info in /etc/fstab like swap if anything else changes
09:47:43 <moviuro> 617K    /boot/loader.efi --- 7814035456        1672        - free -  (836K) talk about "fits like a glove"
09:48:21 <moviuro> doesn't the kernel also need to be on the ESP?
09:48:40 <dch> the other option is to remove the swap partition, re-add a larger 492K+headroom partition, and then re-create the swap partition, aligned and a bit smaller
09:48:50 <dch> woops I looked on the wrong system!
09:49:17 <dch> mine here is 644K. I have an additional custom boot loader in the efi partition...
09:49:29 <CDiMa> I tried today to fetch and install updates to p4 for the openssh advisory but I get errors regarding the stat command not being found... any suggestion?
09:49:33 <dch> moviuro: so yes you need option 2, carve up swap, and fix it
09:49:55 <moviuro> how much trouble would "no more swap" be?
09:50:17 <dch> moviuro: you'll still have swap, it will be 1.98G for example.
09:50:32 <moviuro> that sounds *really* tight for an ESP
09:50:32 <dch> CDiMa: first I'd use `freebsd-update IDS` mode to see what is missing, and then deal with that.
09:51:59 <dch> moviuro: 200M is fine. how many EFI boot loaders and tools do you plan to install? mine is 1G here and I'm using 14M total, and I have 21 additional EFI versions and boot loader tools.
09:52:11 <dch> the kernel lives as usual in zroot/ROOT/default or whatever boot env you have
09:52:58 <dch> moviuro: alternatively, add it at the *end* of the disk, that 836K spot is just enough. Not sure if firmware is smart enough to use that, probably but its not my thing.
09:53:05 <moviuro> good to know, thanks dch . On Linux I have 248MB used on /boot (which includes kernel, and efi loaders)
09:53:21 <dch> aah yes linux has extra stuff
09:54:20 <dch> CDiMa: basically you can unpack base.txz from source, which will have all components in it, but it may also overwrite some customised files.
09:54:29 <dch> CDiMa: some of https://people.freebsd.org/~dch/posts/2021-02-23-sideloading-freebsd.html may be useful for you.
09:54:30 <VimDiesel> Title: Side-loading FreeBSD versions using Boot Environments - Random Musings
09:55:01 <moviuro> it makes sense that the fbsd efi loader can read ZFS :)
09:55:13 <dch> it would be very awkward if it didn't ;-)
09:55:17 <CDiMa> dch: what puzzles me i s what may have removed stat from the system
09:55:28 <dch> CDiMa: is this system quite a small one?
09:55:39 <CDiMa> not really
09:55:59 <CDiMa> 60Gb of disk space
09:56:02 <dch> hmm during BETAs I saw a few small systems run out of memory, lose some of the update files, and get borked
09:56:11 <dch> CDiMa: more on the cpu/ram side I meant
09:56:27 <dch> but zfs rollback and re-run they had no issues
09:56:37 <dch> didnt see it in release upgrades
09:57:12 <moviuro> dch: I'm using stub loading on my everyday linux machine, with the EFI loading the linux kernel directly. 27M     /boot/EFI/Linux/archlinux-linux-lts.efi -- and systemd-boot can't read encrypted btrfs 100K    /boot/EFI/systemd/systemd-bootx64.efi. I'll dig into carving up swap space for the ESP, though that will probably have to wait until January
09:57:29 <CDiMa> 4Gb ram and 2 CPU
09:57:49 <dch> CDiMa: the ones I saw this on are 1G RAM + 1 shared vCPU.
09:58:26 <dch> anyway, `freebsd-update IDS` will tell you what's missing, and you can add it back from base.txz as required. Just make sure you run freebsd-update after.
09:58:44 <CDiMa> dch: well, 2 vCPU for that matter, but of a largish server
09:58:59 <dch> TBH I am not sure if freebsd-update will put stuff back if it's missing, but I don't expect it will run well without stat(1)
09:59:43 <CDiMa> dch freebsd-update IDS has the same behaviour: Inspecting system... /usr/sbin/freebsd-update: stat: not found
10:00:08 <CDiMa> dch: and than lots of stat not found lines
10:00:23 <dch> CDiMa: its amazing it even boots... welp, what else is missing?? then keep copying missing bits from a working system until at least IDS works
10:01:01 <dch> CDiMa: for info did this box go from 13.x -> 14.x directly, or did you try one of the betas or release candidates in between?
10:01:15 <CDiMa> directly
10:01:22 <dch> huh thats not good
10:01:57 <CDiMa> I had 14-RELEASE working
10:02:18 <CDiMa> a couple of days ago I fetched and installed p3
10:02:46 <CDiMa> uptime tells a week ago
10:03:15 <CDiMa> today I did a freebsd-update fetch and started getting that error
10:05:10 <CDiMa> dch: btw this system started from 10 or 11 and I upgraded it regularly
10:05:44 <CDiMa> dch: I always used fetch and install without any troubles
10:06:05 <CDiMa> dch: what was the correct way supposed to be?
10:08:54 <CDiMa> dch: anyway I can think of rollbacking it
10:09:30 <dch> CDiMa: your way sounds correct. I'd not rollback, just copy stat(1) and whatever else is missing from another system, and use `freebsd-update IDS` to clean up.
10:09:36 <dch> that seems like less work
10:10:04 <CDiMa> ok, I just have to catch a 14-RELEASE system
10:11:10 <CDiMa> I see from the snapshots that I jumped from 13.1-RELEASE-p9 to 14-RELEASE
10:11:12 <Remilia> dch: 4 GB RAM is plenty btw
10:11:32 <Remilia> my apu4d4 has 4 GB RAM and a quad core Jaguar and it has never had issues with updating/upgrading
10:11:53 <dch> yes, I run many 1G systems without issue, with zfs.
10:12:44 <CDiMa> zfs can be quite a bit hungry if there's lots of disk I/O
10:12:49 <Remilia> also I think `freebsd-update fetch install` might theoretically recover missing files
10:13:13 <Remilia> zfs ARC is disabled on systems with 4 GB or less RAM anyway
10:13:19 <CDiMa> Remilia: trouble is that the fetch already fails
10:13:29 <Remilia> huh
10:14:03 <Remilia> maybe you could just get the matching base.txz and extract that
10:14:14 <Remilia> the one from 14-RELEASE
10:16:14 <dch> Remilia: yes, but there is a risk that you end up with some important lib that is from p0 and some other tool from p3 and stuff doesn't work.
10:17:55 <CDiMa> hmmm
10:18:43 <CDiMa> dch: /usr/bin/stat is reported 0bytes in the txz I just downloades
10:18:52 <CDiMa> d
10:24:55 <Remilia> dch: that sounds impossible, tbh
10:25:17 <Remilia> plus you can always freebsd-update right after
10:25:48 <Remilia> if you extract base.txz you are replacing the entire base system tree
10:26:08 <Remilia> and old base will always work with new kernel
10:26:22 <Remilia> (well, within a single release)
10:28:07 <Remilia> [10:18:43] <CDiMa> dch: /usr/bin/stat is reported 0bytes in the txz I just downloades <- check the size of readlink
10:28:27 <Remilia> because stat is a hard link of readlink
10:28:55 <Remilia> $ ls -i /usr/bin/readlink /usr/bin/stat \\ 104951 /usr/bin/readlink        104951 /usr/bin/stat
10:32:50 <CDiMa> thanks Remilia
10:34:19 <CDiMa> Remilia: I simply made a hard link in place to readlink that was present on the system, this should take care of dch's worries (if nothing else is missing of course)
10:41:29 <Remilia> `freebsd-update IDS` will tell you about missing/altered files
10:42:21 <CDiMa> running now and taking ages in the "Inspecting system..." state... looks like stat il present and working
10:42:24 <CDiMa> is
10:43:22 <dch> \o/
10:44:17 <Remilia> it may complain about passwd and some other similar files
11:15:10 <Demosthenex> hrm, so i keep getting an error about dbus unable to bind socket to /tmp/XXXX, i've lowered the security level, allowed raw sockets, etc. what else could keep a jail from starting a dbus socket?
11:31:31 <dch> Demosthenex: probably boring permissions?
11:31:47 <dch> su to user expected to create socket, cd /tmp/; mkdir XXXX; see if that works?
11:34:14 <Demosthenex> dch: i've tried changing the dir and other things, it doesn't appear to be anything simple, and it looks like a jail issue
11:34:33 <Demosthenex> i moved tmp off and on ramdisk (tmpfs) and checked perms already
11:36:07 <Demosthenex> i was checking the jail.conf for allow.raw_sockets and allow.socket_af, but those didn't help either
11:36:16 <dch> Demosthenex: are you trying e.g. to run firefox in a jail, or similar?
11:36:22 <dch> I assume dbus etc are all inside the jail
11:36:34 <Demosthenex> i'm trying to run signal-cli (java wrapper to cli signal messenger) in an ubuntu jail
11:36:41 <Demosthenex> headless, no X
11:37:10 <dch> aah
11:37:23 <dch> see https://vermaden.wordpress.com/2021/12/15/secure-containerized-browser/ its for firefox but has a couple hints for dbus related stuff in there
11:37:24 <VimDiesel> Title: Secure Containerized Browser | 𝚟𝚎𝚛𝚖𝚊𝚍𝚎𝚗
11:37:31 <Demosthenex> and for some reason, it uses dbus. but even with dbus-run-session i can't get it going
11:38:10 <Demosthenex> i also allowed sysvipc
11:38:46 <dch> and antranigv did a few extra dbus-related steps too https://weblog.antranigv.am/posts/2020/11/freebsd-signal-cli-scli/
11:38:50 <VimDiesel> Title: Signal-cli with scli on FreeBSD | Antranig Vartanian
11:38:52 <dch> I bookmark all the things all the time
11:39:45 <Demosthenex> unfortunatly the scli and signal-cli ports are so far behind, they no longer function at all
11:39:56 <Demosthenex> which is why i tried an ubuntu jail
11:48:43 <Demosthenex> omfg, dbus may be trying to update linux capabilities?
11:49:34 <CDiMa> dch: freebsd-update IDS reported lots of file permission mismatches
11:49:54 <CDiMa> dch: how came it got all messed up?
11:50:03 <parv> Demosthenex, Could try "truss" to check on "dbus"
11:50:22 <Demosthenex> parv: i was stracing earlier, it provided no insight
11:50:30 <parv> Demosthenex, Ak
11:51:04 <Demosthenex> i was trying to run dbus as a user session, now i'm trying to start the system one, it failed silent
11:51:22 <Demosthenex> so i run the command from the init script manually, and get an failure to drop capability, operation not permitted
11:51:33 <dch> CDiMa: no idea, I only saw missing files in beta, and that was because I ran out of ram during upgrade. I trawled bugzilla but didn't see anything relevant. Would be worth logging a bug if you're in a position to compare (e.g. zfs snapshots pre & post to compare)
11:52:06 <CDiMa> dch: and how can I fix that? a fetch and install cycle would fix that?
11:53:13 <dch> CDiMa: see my sideloading page above if you have zfs. For ufs, you can just do the untar of base to fix it, as root this will also (re)set permissions.
11:53:29 <dch> but you don't have the nice snapshot/rollback support, so its a bit more fiddly
11:54:13 <CDiMa> I surely have a few snapshots both of 13.1 and 14.0
11:59:14 <dch> CDiMa: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261329 may be relevant, also if you do upgrades with a custom umask, maybe that changes things?
11:59:16 <VimDiesel> Title: 261329 – freebsd-update IDS has nonsensical output when link permissions are wrong
12:01:17 <parv> There is "mtree" to fix the issue of permissions (& create missing files). On forums?.freebsd.org, one posted a mini guide
12:01:54 <dch> aah yeah thats a good way to fix permissions etc, but will it fetch missing files if they're not just hardlinks?
12:02:19 <parv> Don't know
12:02:27 <dch> I don't think so
12:07:21 <CDiMa> with mtree I should create a specification from a fresh installation and then apply it to my system?
12:08:40 <parv> Yes. Also see /etc/mtree/
12:09:20 <parv> s/Yes/Perhaps/
12:12:05 <Demosthenex> there should be a law against starting more messaging platforms :P
12:12:19 <dch> ;-)
12:12:38 <Demosthenex> so scli/signal-cli is out of date and doesn't work, linux jail sucks. bitlbee with libpurple doesn't have the signal libpurple lib...
12:12:39 <dch> CDiMa: hey can you share your output of `freebsd-update IDS` somewhere please, ideally as PR in bugzilla?
12:12:49 <Demosthenex> how's a civilized human supposed to use this stupid messenger
12:13:05 <dch> only on a proprietary closed-source smartphone ?
12:13:17 <Demosthenex> dch: can't type there
12:13:46 <Demosthenex> even if i didn't care about the cesspool of cell phones, they lack keyboards
12:13:49 <dch> ditto
12:15:08 <Demosthenex> i despise the progressive war against power users in the software world
12:15:18 <Demosthenex> more than the proprietary crap
12:15:56 <Demosthenex> webapps don't even have hotkeys, and browsers won't let you set your hotkeys anymore. "what's good enough for crayon eating icon clickers is good enough for you citizen"
12:20:01 <CDiMa> dch: do you mind if I give you a pastebin link?
12:20:12 <dch> CDiMa: a good start, yes!
12:20:17 <CDiMa> https://pastebin.com/3KkPAaSS
12:20:19 <VimDiesel> Title: freebsd-update IDS - Pastebin.com
12:22:24 <CDiMa> dch if I skip the /usr/src stuff there shouldn't be that much to fix
12:22:26 <dch> CDiMa: other than stat(1) were any other files missing?
12:22:37 <CDiMa> not that I'm aware of
12:22:46 <dch> yeah, the SHA256 stuff all looks like legit changes
12:59:08 <Remilia> [12:15:56] <Demosthenex> webapps don't even have hotkeys <- it is not even about hotkeys, even the basic UI interactions that have been there for 40 years are missing
12:59:41 <Remilia> for example the click-and-drag menu usage pattern
13:10:20 <Remilia> CDiMa: persimmons aside, everything seems fine
13:10:45 <Remilia> you can ignore etcupdate stuff, that is freebsd-update merging /etc stuff
13:42:29 <dkeav> mmmhhhh persimmon pudding
13:43:57 <signalblue> <Remilia> [12:15:56] <Demosthenex> webapps don't even have hotkeys <- it is not even about hotkeys, even the basic UI interactions that have been there for 40 years are missing
13:44:02 <signalblue> I agree 100%
13:44:27 <signalblue> because it's hard for browsers and web apps to emulate that experience and make it seem authentic
13:44:53 <Remilia> it is almost impossible for menus because drag over text is selection
13:45:18 <signalblue> why would you drag over text in a non-webapp?
13:45:24 <Remilia> like, at some point in my life I stopped using clicks to select menus/submenus
13:45:33 <Remilia> because it requires more presses than dragging
13:45:47 <Remilia> signalblue: menus are arguably text
13:45:58 <signalblue> so how do you select menus/submenus?
13:46:09 <signalblue> using the keyboard? that's what I do
13:47:02 <CDiMa> ok, thanks to dch and Remilia, i fixed permissions and updatet do 14-RELEASE-p4, all seems fine...
13:47:04 <CDiMa> cya
13:47:06 <Remilia> if you are using the mouse for that (for keyboard, it is faster to use associated keys) which I do relatively often, you can press the mouse button on the item in the menu bar and drag it, without releasing, to open submenus
13:47:13 <Remilia> releasing activates the selected item
13:47:53 <Remilia> dragging while holding the button activates submenus without requiring a click to switch
13:48:11 <Remilia> lemme maybe record it
13:48:15 <signalblue> oh I see
13:48:26 <signalblue> just slick and hold something
13:48:37 <Remilia> yes
13:48:38 <signalblue> then move the mouse to whatever
13:48:44 <signalblue> click not slick
13:48:48 <Remilia> and when you release the item activates
13:49:00 <Remilia> it is a *lot* faster than single clicking items
13:49:09 <signalblue> yes that's not an option with webapps
13:49:40 <Remilia> and you cannot do this with drop-down menus in web apps (because text selection prevails) AND in custom-drawn interfaces (hello Firefox)
13:49:58 <Remilia> I think the interaction I described works even in Motif
13:50:08 <Remilia> pretty sure I used it in CDE and IID
13:50:38 <signalblue> I wonder if anyone still uses CDE as a daily desktop these days
13:50:53 <Remilia> Solaris users maybe do?
13:51:00 <Remilia> oh it also worked in OS/2 Warp 3
13:51:31 <Remilia> and in Turbo/Borland Pascal/C++ 7 for DOS too iirc
13:52:18 <signalblue> yes but Solaris is dead and Oracle has no interest in reviving it
13:52:28 <Remilia> signalblue: essentially electron/react ignore and obliterate 40 years of UI/UX development and design
13:52:36 <signalblue> yep I agree
13:53:06 <signalblue> and newish Solaris installs do not have CDE
13:54:34 <nimaje> someone ported and maintains cde in the ports tree, so maybe someone uses it as daily driver on freebsd
13:56:29 <Remilia> what is especially annoying about this 'cross platform' menace is that not only it is bad for power users, it is also terrible for accessibility
13:58:47 <Remilia> also note how just about nearly every messenger app looks the same and almost none of them, including Matrix's Element, support multiple windows
14:00:04 <Remilia> everything runs with the smartphone/tablet screen paradigm, almost everything is spaced to hell 'for touch interfaces'
16:00:46 <longword> Is it possible to run a FreeBSD 13 kernel on 64MB RAM? Can't seem to load the kernel with less than 80MB.
16:05:39 <nimaje> how much tuning did you already try? if you just tried -GENERIC then probably by compiling your own kernel and removing all kernel modules you don't need
16:06:52 <longword> Quite a bit of tuning. I've had a system running on 11.4 for a long time. I have the kernel file down to 4.5MBytes and I think that's as low as I can go.
16:09:30 <longword> I'm using nanobsd and targeting an ancient Soekris Net4501 with 64MB but testing with a VM. At 80MB RAM I have a working system I can login to.
16:10:36 <longword> At 76MB RAM the boot loader fails with elf32_loadimage: read failed. At 64MB I get no messages at all.
16:35:58 <antranigv> Demosthenex that's pretty sad. I should have a look at the port.
16:36:07 <antranigv> Demosthenex where did you get at?
16:41:59 <Demosthenex> antranigv: sorry?
16:42:33 <tsoome_> longword you will need some hacking.
16:43:16 <Demosthenex> antranigv: the scli port is 0.7.1, current is 0.7.3, and signal-cli port is 0.9.0 and the current is 0.12.7. versions of signal-cli before 0.11 don't work at all with scli
16:43:19 <tsoome_> longword for generic use case, the loader heap is configured to use 64MB and you still need memory for actual kernel and modules.
16:47:20 <Demosthenex> antranigv: i should have considered just trying to update the port myself, even locally. duh. ;]
16:53:22 <longword> tsoome_: I was thinking it might be something like that. Any pointers as to where one might nudge that loader heap in the right direction?
16:54:11 <tsoome_> longword bios version? boot/i386/loader/main.c
16:54:25 <longword> Much obliged
16:55:19 <tsoome_> + you most likely want to strip as much as you can....  maybe even to the point to load kernel directly not with loader but with second stage
16:56:20 <longword> I'm moderately sure I'll be fine once I can get the kernel loaded. Booting with 80MB there seems to be plenty of memory free for userspace.
16:57:31 <longword> stand/i386/loader/main.c seems to be the thing
17:38:35 <trench> https://freebsdfoundation.org/blog/2024-freebsd-community-survey-is-here/
17:38:36 <VimDiesel> Title: 2024 FreeBSD Community Survey is Here – FreeBSD Foundation
19:15:09 <longword> Victory! My enemy was in stand/i386/libi386/biosmem.c - #define HEAP_MIN (64 * 1024 * 1024)
19:15:58 <longword> With that slapped back down to 16MB I can boot the kernel and login to a super minimal system with just 40MBytes RAM.
19:16:54 <longword> Thank you to nimaje and tsoome_ for the assistance
19:21:36 <thumbs> Very nice.
19:33:42 <pstef> it feels that should be somehow settable