[systemd-devel] Regarding systemd-boot counting.
Hello Everyone, I am exploring systemd-boot counting for HLOS roll back. I am new to systemd-boot. As part of boot counting systemd-boot will decrement the "tries-left" counter of the selected configuration and tries to boot with that. *For example **4.14.11-300.fc27.x86_64+2-1.conf*. When the device successfully boots up, systemd-bless-boot.service is expected to mark this entry as good. *For example 4.14.11-300.fc27.x86_64.conf.* But if for some reason, the HLOS boot up fails, is it expected to reboot the device manually so that the next retry happens? Or is there a service similar to systemd-bless-boot.service which reboots the device when the boot up fails? Thanks Srinivas
Re: [systemd-devel] Regarding systemd-boot counting.
Thanks Lennart. Will analyze these options and get back to you. On Mon, Sep 9, 2024 at 9:54 PM Lennart Poettering wrote: > On Mo, 09.09.24 20:15, Srinivas Naik (nivasn...@gmail.com) wrote: > > > Hello Everyone, > > I am exploring systemd-boot counting for HLOS roll back. I am new to > > systemd-boot. As part of boot counting systemd-boot will decrement the > > "tries-left" counter of the selected configuration and tries to boot with > > that. > > *For example **4.14.11-300.fc27.x86_64+2-1.conf*. > > When the device successfully boots up, systemd-bless-boot.service is > > expected to mark this entry as good. > > *For example 4.14.11-300.fc27.x86_64.conf.* > > But if for some reason, the HLOS boot up fails, is it expected to reboot > > the device manually so that the next retry happens? Or is there a service > > similar to systemd-bless-boot.service which reboots the device when the > > boot up fails? > > Well, what reboots the machine on failure really depends on the > subsystem you want to cover. > > Many freezes cannot be caught at all. Kernel crashes might be > something you can catch via panic=5 (or similar) on the kernel > cmdline. If you want to put a timeout on the boot process, then add > something like this to > /etc/systemd/system/multi-user.target.d/50-job-timeout.conf: > > [Unit] > JobTimeoutSec=5min > JobTimeoutAction=reboot-force > > And then there is the hw watchdog you can use via RuntimeWatchdogSec= > in /etc/systemd/system.conf, which can catch some more failures. > > If you do all three you should have quite OK coverage. > > Lennart > > -- > Lennart Poettering, Berlin >
Re: [systemd-devel] Passing Kernel Params from systemd-boot for Secure Boot UKI
Hi All, I have a question on this, when secure boot is enabled, addons file also must be signed? On devices which use OSTree for OTA, there is a need to update the command line parameter at run time with the latest SHA deployment. How to do this on secure boot enabled devices since command line parameters mentioned in the config file will not be picked. Thanks Srinivas On Thu, Oct 10, 2024 at 4:13 AM Mah, Yock Gen wrote: > It's works, really appreciate your help, Lennart! > > -Original Message- > From: Lennart Poettering > Sent: Tuesday, October 8, 2024 9:39 PM > To: Mah, Yock Gen > Cc: systemd-devel@lists.freedesktop.org > Subject: Re: [systemd-devel] Passing Kernel Params from systemd-boot for > Secure Boot UKI > > On Di, 08.10.24 12:37, Mah, Yock Gen (yock.gen@intel.com) wrote: > > > Really appreciate! I tried to create an PE "addon" using below: > > > > echo "yockgen=b" > cmdline.txt > > > > objcopy --input binary --output efi-app-x86_64 cmdline.txt > > bootdm_b.addon.efi > > This doesn't look right. You must insert the cmdline in the ".cmdline" > PE section, of course. As mentioned, addons follow the same structure as > UKIs after all. > > We generally recommend using ukify for generating UKIs and PE addons. > > The man page even has an example doing exactly what you need to do: > > https://github.com/systemd/systemd/blob/main/man/ukify.xml#L674 > > Lennart > > -- > Lennart Poettering, Berlin >
Re: [systemd-devel] Passing Kernel Params from systemd-boot for Secure Boot UKI
Thanks a lot for the details. Will go through them and get back to you. Thanks Srinivas On Tue, Oct 15, 2024 at 4:27 PM Luca Boccassi wrote: > Yes addons have to be signed, otherwise it would defeat their purpose. > OSTree should to switch to other mechanisms, like credentials stored > in the ESP ( https://systemd.io/CREDENTIALS/ ), instead of using the > kernel command line. > > On Tue, 15 Oct 2024 at 11:45, Srinivas Naik wrote: > > > > Hi All, > > I have a question on this, when secure boot is enabled, addons file also > must be signed? > > On devices which use OSTree for OTA, there is a need to update the > command line parameter at run time with the latest SHA deployment. > > How to do this on secure boot enabled devices since command line > parameters mentioned in the config file will not be picked. > > > > Thanks > > Srinivas > > > > On Thu, Oct 10, 2024 at 4:13 AM Mah, Yock Gen > wrote: > >> > >> It's works, really appreciate your help, Lennart! > >> > >> -Original Message- > >> From: Lennart Poettering > >> Sent: Tuesday, October 8, 2024 9:39 PM > >> To: Mah, Yock Gen > >> Cc: systemd-devel@lists.freedesktop.org > >> Subject: Re: [systemd-devel] Passing Kernel Params from systemd-boot > for Secure Boot UKI > >> > >> On Di, 08.10.24 12:37, Mah, Yock Gen (yock.gen@intel.com) wrote: > >> > >> > Really appreciate! I tried to create an PE "addon" using below: > >> > > >> > echo "yockgen=b" > cmdline.txt > >> > > >> > objcopy --input binary --output efi-app-x86_64 cmdline.txt > >> > bootdm_b.addon.efi > >> > >> This doesn't look right. You must insert the cmdline in the ".cmdline" > >> PE section, of course. As mentioned, addons follow the same structure > as UKIs after all. > >> > >> We generally recommend using ukify for generating UKIs and PE addons. > >> > >> The man page even has an example doing exactly what you need to do: > >> > >> https://github.com/systemd/systemd/blob/main/man/ukify.xml#L674 > >> > >> Lennart > >> > >> -- > >> Lennart Poettering, Berlin >
