| 11 Feb 2025 |
 Arian | it’s just annoying to have to pass that in explicitly | 12:03:57 |
| Arian | qemu needs to be installed in environment.systemPackages anyway. so might as well expose /etc/qemu/firmware I guess | 12:04:14 |
| Arian |
$ systemd-vmspawn --linux /run/current-system/kernel --tpm no --initrd /run/current-system/initrd
░ Spawning VM nixos-stuff on /mnt/Projects/nixos-stuff.
░ Press Ctrl-] three times within 1s to kill VM.
Couldn't find OVMF firmware blob with Secure Boot support, falling back to OVMF firmware blobs without Secure Boot support.
qemu-kvm: -device vmgenid,guid=cc36b80c-97fa-4233-ad99-c246a2f48443: 'vmgenid' is not a valid device model name
| 12:13:06 |
| Arian | urghh does qemu-kvm-aarch64 not support vmgenid? | 12:13:17 |
 Alyssa Ross | It's ACPI — do aarch64 VMs use ACPI? | 12:16:38 |
 raitobezarius | I think I saw ACPI support for aarch64 in the kernel recently | 13:51:45 |
| Alyssa Ross | Oh yeah I'm not saying you can't do ACPI on aarch64 | 13:58:52 |
 antifuchs | I have a nixos test that tries to assert that a socket unit startup doesn't finish until a certain condition is met. If I do a machine.start() in the test code, the test waits forever until the socket's execstart finishes; is there a way to get backdoor.service not to depend on that socket being fully up? | 15:28:28 |
| antifuchs | * I have a nixos test that tries to assert that a socket unit startup doesn't finish until a certain condition is met. If I do a machine.start() in the test code, the test waits forever until the socket's execstart finishes (which it won't, because the condition for it finishing happens later in the test); is there a way to get backdoor.service not to depend on that socket being fully up? | 15:29:35 |
| antifuchs | trying to do it with the initrdBackdoor, but that feels kinda wonky | 15:33:05 |
| antifuchs | hrm, nope: now switch_root() hangs indefinitely (: | 15:35:14 |
| antifuchs | * I have a nixos test that tries to assert that a socket unit startup doesn't finish until a certain condition is met. If I do a machine.start() in the test code, the test waits forever until the socket's ExecStartPre finishes (which it won't, because the condition for it finishing happens later in the test); is there a way to get backdoor.service not to depend on that socket being fully up? | 16:09:45 |
 aloisw | In reply to @k900:0upti.me
Also IIRC libvirt does something like that already with /run/libvirt/firmware /run/libvirt/nix-ovmf, also /var/lib/qemu/firmware lately (which causes issues). | 18:11:12 |
| aloisw | In reply to @qyliss:fairydust.space
It's ACPI — do aarch64 VMs use ACPI? Depends on who runs the VM I guess, the Hetzner Cloud ones do and they seem to be standard KVM with UEFI. | 18:14:17 |
| Alyssa Ross | You can do UEFI with devicetree though | 18:18:13 |
| Alyssa Ross | and I think that's what QEMU does | 18:18:16 |
 @rosscomputerguy:matrix.org | In reply to @aloisw:julia0815.de
Depends on who runs the VM I guess, the Hetzner Cloud ones do and they seem to be standard KVM with UEFI. Yeah, I think those are Ampere machines. I'm pretty sure mine has ACPI. | 18:29:31 |
| aloisw | I don't think the host hardware matters inside a VM. Unsure whether they use QEMU though. | 18:32:11 |
| Arian | Yeh seems qemu only does acpi for intel | 20:15:01 |
 @elvishjerricco:matrix.org | You could do systemd.services.backdoor.unitConfig.DefaultDependencies = false;. I tried to add that as a general thing one time but a bunch of tests broke so we undid that. But there's no reason the backdoor needs to wait for things like basic.target; those tests that broke just made assumptions about file systems already being mounted and stuff | 20:15:10 |
| Arian | Systemd folks told me vmspawn is basically untested and they never tried it on aarch64 | 20:15:27 |
| Arian | Mkosi qemu wrapper is also broken on aarch64 | 20:15:38 |
| raitobezarius | in true systemd fashion | 20:27:04 |
| antifuchs | oooh, is it basic.target that gets waited on there? I guess that's my culprit | 20:39:46 |
| Arian |
in true systemd fashion
I made the mistake at looking all issues tagged with journal in the systemd issue tracker today
| 21:43:25 |
| Arian | *
in true systemd fashion
I made the mistake at looking all issues tagged with journal in the systemd issue tracker today
| 21:43:32 |
| Arian | I’m convinced it’s physically impossible to logship journal logs without occasional corruption | 21:43:55 |
| 12 Feb 2025 |
|  arcayr joined the room. | 02:50:36 |
 magic_rb | so ive got a weird setup where i've got some disks on my server which are unlocked by me after the rest of the system boots up. therefore for example /mnt/disk1 wont be available until i unlock it. But when I do need the equivalent of machinectl bind uk3s /mnt/disk1/infrastructure/buildbot /data/buildbotto be ran. I'm not sure whats the best way to automate that in systemd. Maybe a service unit depending onmnt-disk1-infrastructure-buildbot.mount`? | 07:49:51 |
 gdamjan | automate what? | 15:58:25 |
