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, dharm...@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?

Attachment: OpenPGP_0x20257A7131FFF28B.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

Reply via email to