08:48:59 Hi, is this the right channel to ask about S3? 09:53:03 Greetings. Looks like I am forced to use a cluster of Raspberry Pis instead of a couple of normal machines for a home DC. But, obviously, I prefer FreeBSD as the server OS. But also my experience with FreeBSD raises some questions. For now, I assume a topology with 1-2 'controller' nodes and 4-8 'worker' nodes, and clustered applications can be storage (like Ceph) or microservice (like Docker, jails/CBSD or 09:53:04 'manual static orchestration'). First, can U-Boot, which is used in Pi images, be ran via PXE to make entire μSDs of 'worker' nodes be, for example, Ceph OSDs? Second, how much GNU/Linux and FreeBSD clustering stack differs (for examples, is Ceph even compatible with FreeBSD, and are there Pacemaker/Corosync, which are used at our office)? 09:55:29 I used to run all my apps on a single node with an USB HDD connected, but U-Boot had troubles with unattended boot 'cause, as my OS&DE teacher assumes, it tries to boot from the HDD but isn't aware of the HDD spin-up delay and just hangs... 10:30:11 i prefer freebsd because the logo is cool 10:33:36 mkf: what's the context? 10:34:49 alex1216: there's a few people in here who use podman to deploy applications in jails, orchestrated by nomad 10:35:08 images are built by buildah then 10:36:49 meena: do you know any in the source code team? 10:48:44 meena: ACPI 10:52:08 mictty: depends on which part of the source, but yea, I've been around long enough that I know some devs 10:52:51 mkf: ah, yeah, ask away, i thought you meant the other S3, the cloud thing 10:53:11 alright, thanks :) 10:53:42 i have a hp elitedesk 800 G2, with ghostbsd i can suspend system without any issues. 10:54:10 however with vanilla freebsd i can't restore from suspend. 10:54:32 are there any kernel mods or related things to configure? 10:56:03 ISTR that to restore from suspend you need to have the KMS for your GPU loaded. 11:26:55 meena: i moved the conversation to freebsd-social, since the topic may not so fit in freebsd 11:39:47 alex1216: as for raspberry pi booting sequence: https://raspberrypi.stackexchange.com/questions/10442/what-is-the-boot-sequence/10595#10595 https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#raspberry-pi-4-boot-flow - you need sd card to load uboot (first part is hardcoded in chip), then uboot can load kernel via tftpd from network (along with anything else) 11:39:48 Title: What is the boot sequence? - Raspberry Pi Stack Exchange 11:40:21 alex1216: there is no pxe on raspbery - but uboot can act something like it 15:46:27 __xor: have you seen https://github.com/rosorio/pkg-provides/issues/7 ? 15:46:28 Title: How to provide a provides DB for a PkgBase repo · Issue #7 · rosorio/pkg-provides · GitHub 16:23:44 is there a way to keep a kernel module from loading? module_blacklist="zfs" does not seem to 16:28:33 or a different approach, does blacklisting puppet facts prevent running the commands to get those facts, or just hide them from the output 16:33:24 rtprio: you can do it in loader.conf, too 16:36:52 i put that in loader.conf and it still loads 16:37:03 unless i misunderstand its function 17:40:55 i think it's blOcklist now? 17:49:16 I'ts just blocklistd 17:49:54 There's an update in the works which'll bring in the name. 17:50:58 A daemon that maintains a list of things that should be blocked being named blocklistd makes the most amount of sense possible. 18:00:12 rtprio: it's tricky with the naming of the modules 18:07:27 sometimes it needs .ko, sometimes it doesn't, and does and i never remember which file wants it which way 18:07:35 might be good to document that, huh? 18:13:14 rc.conf(5) says kld_list takes it without .ko, but doesn't mention what format devmatch_blocklist/devmatch_blacklist take 18:13:39 rtprio: if you block modules in loader, you should also block them in rc.conf 20:20:23 ok 20:29:02 rtprio: as for facter, I don't remember how to suppress specific facts 23:14:27 rmacklem@ has been making interesting jail+NFS related changes, recently. 23:24:40 yeah, I hope they land, but I also hope the current discussions re vnet shutdown goes somewhere fruitful