When booting a fully configured and earlier rebooted Rocky linux 8.5 machine, I end up in the recovery/emergency mode (not a default boot). I chosed the option normal boot (ctlr-D) and it booted normally. When analyzing journal file, I notice an issue with the firstboot.service:
[root@server ~]# systemctl status systemd-firstboot
● systemd-firstboot.service - First Boot Wizard
Loaded: loaded (/usr/lib/systemd/system/systemd-firstboot.service; static; vendor preset: disabled)
Active: failed (Result: start-limit-hit)
Condition: start condition failed at Thu 2022-03-31 17:46:38 CEST; 18h ago
└─ ConditionFirstBoot=yes was not met
Docs: man:systemd-firstboot(1)
mar 31 17:46:25 server.hartings.se systemd[1]: systemd-firstboot.service: Start request repeated too quickly.
mar 31 17:46:25 server.hartings.se systemd[1]: systemd-firstboot.service: Failed with result ‘start-limit-hit’.
mar 31 17:46:25 server.hartings.se systemd[1]: Failed to start First Boot Wizard.
[root@server ~]# more /etc/machine-id
3a298bd8904748bfa466558cda04f570
[root@server ~]#
What is the real problem? Can I just disable the service, so it doesn’t want to start upon booting?
Any other recommendations?
After the checking above, I rebooted the machine again (no changes made!) and it booted normally…
Again checking the status:
[root@server ~]# systemctl status systemd-firstboot
● systemd-firstboot.service - First Boot Wizard
Loaded: loaded (/usr/lib/systemd/system/systemd-firstboot.service; static; vendor preset: disabled)
Active: inactive (dead)
Condition: start condition failed at Fri 2022-04-01 12:45:15 CEST; 2min 10s ago
└─ ConditionFirstBoot=yes was not met
Docs: man:systemd-firstboot(1)
[root@server ~]#
So now the firstboot.service was not started (and it shouldn’t!), and I suppose, this is how it should look like, when you reboot a fully configured machine. But why did it not boot correctly as shown in the first example? I need to rely on that my server will auto-reboot (BIOS settings are OK) when a power-loss / power-on situation occurs and I need to be sure it really boots up properly withou anyone being present at the machine!
I think this is more a symptom of what caused the dump into rescue mode. I think the “firstboot.service” is run on every boot to check if this “is” the first boot of the system and then exits.
I would speculate that some script did not complete prior to the subject reboot and left the system in an unstable condition or this was a one in a million hiccup on boot. I would try rebooting a few times in a row to see if it repeats.
[quote=“jbkt23, post:2, topic:5741”]I think the “firstboot.service” is run on every boot to check if this “is” the first boot of the system and then exits.
[/quote]
Yes it is. man systed-firstboot writes:
systemd-firstboot initializes the most basic system settings interactively on the first boot, or optionally non-interactively when a system image is created. The service is started if ConditionFirstBoot=yes is satisfied.
man systemd.unit writes:
ConditionFirstBoot= takes a boolean argument. This condition may be used to conditionalize units on whether the system is booting up with an unpopulated /etc directory (specifically: an /etc with no /etc/machine-id). This may be used to populate /etc on the first boot after factory reset, or when a new system instance boots up for the first time.
That is, the systemd would run this oneshot service, if there were no /etc/machine-id already.
The systemctl status shows “State: failed” if units have failed. The “I did not do it because there was no need” is not a failure.
This was a more genuine failure. Looks like systemd did start firstboot, but it failed for some reason and systemd did try again (how many times?). All that very very quickly. Rather than retrying forever, systemd gives up. (That is better than X11 of mine that did crash with a core dump and did so until / was full …)
However, something got done here and /etc/machine-id was generated.
Either it’s a unlikely error, which doesn’t give me much confidence, or it could be due to a change in the Bios i made to enable an on power-loss reboot. Or can such a change in the bios not cause this?
That is, when standby-power is restored to motherboard, the motherboard/EFI (does anything have real legacy BIOS any more?) will automatically send ‘power on’ signal to PSU. Such a low-level action should not care whether any OS is installed.
I thought that perhaps any change in Bios/EFI settings would trigger the “firstboot” parameter on the OS. But this may be the case as you suggest.
Den 1 apr. 2022, kI 22:31, jlehtone via Rocky Linux Forum <notifications@rockylinux.discoursemail.com> skrev:
