[systemd-devel] Exploring Minimal Systemd in Initramfs for Faster Boot

serenissi serenissi at inventati.org
Wed Sep 25 15:19:17 UTC 2024


If you want to keep the egt service running from early initramfs into 
the new roootfs then see https://systemd.io/ROOT_STORAGE_DAEMONS

 > Since systemd v255, alternatively the SurviveFinalKillSignal=yes unit 
option can be set

If the egt service can work very early in main rootfs then you can as 
well put it in basic.target so it relaunches as soon as possible after 
switch root.

However

 > only the core binaries would reside in it, while the larger 
dependencies, including libraries for egt, would remain in the root 
filesystem.

which means you won't be able to run egt in initfamfs until main rootfs 
is mounted anyways? Or are the libraries like plugins to be loaded 
later? Am I missing something here?

In theory you can use RootImage to point to /sysroot and start egt after 
rootfs is mounted in initramfs. That way you won't even need the binary 
inside initramfs. This will give a very small amount of time advantage 
of launching systemd in rootfs and running basic.target. Not sure if 
that is what you are looking for.

On 9/25/24 06:07, Dharma.B at microchip.com wrote:
> Hi Serenissi,
>
> On 24/09/24 2:58 pm, serenissi wrote:
>> du -sh /usr/lib/systemd/
>> 13M     /usr/lib/systemd/
>>
>> du -sh /usr/lib64/systemd
>> 6.4M    /usr/lib64/systemd
>>
>> i.e. about 20M with most stuffs of systemd package installed. Is it too
>> large for initrd? Idk about your setup, might be embedded flash..
> The objective is to accelerate the launch of the egt-launcher by
> incorporating a minimal version of systemd within the initramfs. The
> idea is to have systemd initiate essential services, specifically the
> egt-launcher, as early as possible. Given the size constraints of the
> initramfs, only the core binaries would reside in it, while the larger
> dependencies, including libraries for egt, would remain in the root
> filesystem.
>
> I’m considering whether this minimal systemd could track these services
> and continue managing them seamlessly after transitioning to the main
> rootfs. Is this approach feasible within the current systemd framework,
> or are there alternative strategies we could pursue for this use case?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20240925/57de811c/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x20257A7131FFF28B.asc
Type: application/pgp-keys
Size: 652 bytes
Desc: OpenPGP public key
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20240925/57de811c/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20240925/57de811c/attachment.sig>


More information about the systemd-devel mailing list