Since the last few updates I’ve noticed that systemctl reports a degraded status owing to firewalld failing to start. It’s set to enabled. I’m not sure what’s changed. Running sudo systemctl restart firewalld.service successfully launches firewalld without error.
I don’t have this problem on my desktop installation. It only seems to affect the headless install on my RPi5.
output of journalctl -eu firewalld:
Feb 27 07:34:52 Paarthurnax systemd[1]: Starting firewalld - dynamic firewall daemon...
Feb 27 07:34:52 Paarthurnax systemd[1]: firewalld.service: Main process exited, code=exited, status=1/FAILURE
Feb 27 07:34:52 Paarthurnax systemd[1]: firewalld.service: Failed with result 'exit-code'.
Feb 27 07:34:52 Paarthurnax systemd[1]: Failed to start firewalld - dynamic firewall daemon.
firewalld started with no problems. Run systemctl status firewalld immediately after boot up while firewalld is is still not ative, and you should get the above results. Namely “enabled” listed above in green letters, “active (running)” listed above in green letters
As far as I know, if firewalld is installed and firewalld is enabled AS ROOT, then
firewalld should self start on the next boot.
$ su (enter your root passwd)
# systemctl enable --now firewalld
I’ve never used a Raspberry Pi, but I’ll take a look. As suspected, the $FIREWALLD_ARGS is probably not doing anything as the default environment file that’s being sourced is empty by default. @dalto’s should be enough to give a better description of the error.
Speaking of the error message, a search found this common with python version mismatches. Are you running something like conda or pyenv?
(Sorry, could not figure out how to change the reply-to)
Once the kernel is up and running, software running on an ARM device (aarch64) is exactly like x86_64. Which is what makes RPi 5 so handy for DE hopping, testing new apps, etc. Or just doing your normal daily routines on an extremely power efficient device.
It’s still a different ISA though, it isn’t common but still easy to catch a runtime stray bullet in a package, esp. since Arch on Arm is mostly an hobby and not widely deployed or tested.
Just a guess but in the past when I have run into this situation when a service does not load on boot and after boot I can get it loaded it is caused by some condition under [Unit] is not being met when it tries to activate in the .system file. You could try adding under here in the file to make it try a few more times and check after a little while after boot a few times to see if it activates. If it does then try to see what is really happening more closely under the [Unit] section.
Tried this after adding the --debug=10 option, but the output looks the same:
Mar 09 20:28:20 [SYSTEMNAME] systemd[1]: Starting firewalld - dynamic firewall daemon...
Mar 09 20:28:21 [SYSTEMNAME] systemd[1]: firewalld.service: Main process exited, code=exited, status=1/FAILURE
Mar 09 20:28:21 [SYSTEMNAME] systemd[1]: firewalld.service: Failed with result 'exit-code'.
Mar 09 20:28:21 [SYSTEMNAME] systemd[1]: Failed to start firewalld - dynamic firewall daemon.