Try to make booted containers work with GitHub's arm64 runners

[ethanjli]

GitHub has just launched their public preview of hosted arm64 runners. As of 6cb562b they break functionality for booted nspawn containers - for some reason, they cause the nspawn action's generated systemd service to stop (as part of some sort of spontaneous triggering of system shutdown) once the OS reaches the login prompt, even though the nspawn action's generated systemd service is still running. This PR attempts to fix or work around that problem.

[ethanjli]

PlanktoScope/PlanktoScope#520 appears to be able to run the OS setup scripts in an unbooted nspawn container, and the weird behavior this PR attempts to fix is probably some kind of bug. Since arm64 runners are still a public beta and I don't currently need a workaround to the weirdness, I'm going to put this PR on the back-burner so I can focus on higher-priority tasks.

[ethanjli]

It would be good to see if we can rule out any weirdness with RPi OS's first-boot behaviors which may trigger a reboot upon reaching multi-user.target on the first boot.

For example, /usr/lib/raspi-config/init-resize.sh ends by invoking its reboot_pi function, which does cause a reboot. If /boot/firmware/cmdline.txt includes init=/usr/lib/raspi-config/init_resize.sh during first boot, that might cause a reboot. But /boot/firmware/cmdline.txt should be ignored by systemd-nspawn, so we should check if something else might be causing a reboot. Note that /etc/init.d/resize2fs_once does not appear have any code which would trigger a reboot. But there is an rc.local script which performs disk resizing, and after it finishes running then systemd appears initiate a reboot.

Perhaps we could check whether only the first boot triggers a spontaneous shutdown, or whether subsequent boots also trigger a spontaneous shutdown.