🟩 WANTED: 🔧 SYSTEMD-INITED & ENABLED CONTAINER

[silent-sixth-cargo]

🔮 Feature Request

A systemd enabled CachyOS container stand alone.
Keep the already build container as is as non systemd standard container,
and please do a new full-fledged systemd enabled stand alone container with necessary components like journalctl, dbus etc.

📌 Context
Currently, there is no official CachyOS container image with systemd support, which limits its use in scenarios requiring PID 1 to be systemd (e.g., Docker-in-LXC environments, testing of system services containerized, orchestrating services inside container etc).

A systemd-capable container would be beneficial for those wanting to run or test full system services using the CachyOS userland containerized.

👉A new stand alone one with systemd init / pid 1.
Would be very much appreciated, Thanks .

The fewer external requirements needed to run it stably, the better
— ideally without requiring --privileged mode, cgroup mounting hacks,
or similar workarounds.

🤝Thanks
Appreciate the amazing work on CachyOS. This addition could significantly extend its usability beyond bare metal and VMs.

redhat already has one: ubi8-init
;registry.access.redhat.com/ubi8/ubi-init:lateststrong

[leleobhz]

2 cents here: Its healther use bootc (Eg. https://github.com/M1cha/bootc-archlinux and https://github.com/frap129/arch-bootc ) that just put a Init on container.

Reason for this is bootc container is able to "boot systemd" in container and its also capable to behave as immutable bare-metal system in the same package.

Also, considering already has some effort to bring bootc to Arch, the path maybe easier than just put systemd on container.

[silent-sixth-cargo]

hurry up ptr & cachy team !!!
Still counting days!

[vnepogodin]

Very low priority. If you want to send PR, welcome for the contributions

[leleobhz]

Hello @vnepogodin

About the arch-bootc repos I brought on this ticket, do you have any opinion about their approaches?

[silent-sixth-cargo]

you can do bootc as long as requirements are met approach could be flexible ;

and its highly valuable for developers

[leleobhz]

you can do bootc as long as requirements are met approach could be flexible ;

and its highly valuable for developers

Take a look at some bootc implementations like https://docs.fedoraproject.org/en-US/bootc/building-containers/ and https://almalinux.org/blog/2024-09-02-bootc-almalinux-heliumos/ (More likely to be what you asking for). bootc containers are regular oci containers but their fs are bootable and the bootloader can handle the OCI image. And works the same way: Immutable, upgradable by downloading new oci image and everything is inside oci image - very likelly previous atomic distros like Fedora Silverblue.

RHEL and RHEL based AlmaLinux/RockyLinux adopted, arch does have community Dockerfiles. Take a look at existent images and use it to run systemd. Example:

❯ podman run -it --rm --name almabootc quay.io/almalinuxorg/almalinux-bootc:9.4
systemd 252-32.el9_4.7.alma.1 running in system mode (+PAM +AUDIT +SELINUX -APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS -FIDO2 +IDN2 -IDN -IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT -QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK +XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified)
Detected virtualization podman.
Detected architecture x86-64.

Welcome to AlmaLinux 9.20241112.0.4 (Seafoam Ocelot)!

Initializing machine ID from container UUID.
Queued start job for default target Graphical Interface.
[  OK  ] Created slice Slice /system/getty.
[  OK  ] Created slice Slice /system/modprobe.
[  OK  ] Created slice Slice /system/sshd-keygen.
[  OK  ] Created slice User and Session Slice.
[  OK  ] Started Dispatch Password Requests to Console Directory Watch.
[  OK  ] Started Forward Password Requests to Wall Directory Watch.
[  OK  ] Reached target Local Encrypted Volumes.
[  OK  ] Reached target Local Integrity Protected Volumes.
[  OK  ] Reached target Path Units.
[  OK  ] Reached target Remote Encrypted Volumes.
[  OK  ] Reached target Remote File Systems.
[  OK  ] Reached target Slice Units.
[  OK  ] Reached target Swaps.
[  OK  ] Reached target Local Verity Protected Volumes.
[  OK  ] Listening on Device-mapper event daemon FIFOs.
[  OK  ] Listening on LVM2 poll daemon socket.
[  OK  ] Listening on RPCbind Server Activation Socket.
[  OK  ] Reached target RPC Port Mapper.
[  OK  ] Listening on Process Core Dump Socket.
[  OK  ] Listening on initctl Compatibility Named Pipe.
[  OK  ] Listening on Journal Socket (/dev/log).
[  OK  ] Listening on Journal Socket.
         Starting Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling...
         Starting Journal Service...
         Starting Generate network units from Kernel command line...
         Starting Remount Root and Kernel File Systems...
[  OK  ] Finished Remount Root and Kernel File Systems.
[  OK  ] Finished Generate network units from Kernel command line.
[  OK  ] Reached target Preparation for Network.
         Starting Rebuild Hardware Database...
         Starting Create System Users...
[  OK  ] Started Journal Service.
         Starting Flush Journal to Persistent Storage...
[  OK  ] Finished Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling.
[  OK  ] Finished Create System Users.
         Starting Create Static Device Nodes in /dev...
[  OK  ] Finished Flush Journal to Persistent Storage.
[  OK  ] Finished Create Static Device Nodes in /dev.
[  OK  ] Finished Rebuild Hardware Database.
[  OK  ] Reached target Preparation for Local File Systems.
[  OK  ] Reached target Local File Systems.
         Starting Rebuild Dynamic Linker Cache...
         Starting Mark the need to relabel after reboot...
         Starting Automatic Boot Loader Update...
         Starting Create Volatile Files and Directories...
[  OK  ] Finished Mark the need to relabel after reboot.
[  OK  ] Finished Automatic Boot Loader Update.
[  OK  ] Finished Rebuild Dynamic Linker Cache.
[  OK  ] Finished Create Volatile Files and Directories.
         Starting RPC Bind...
         Starting Rebuild Journal Catalog...
         Starting Record System Boot/Shutdown in UTMP...
[  OK  ] Finished Record System Boot/Shutdown in UTMP.
[  OK  ] Finished Rebuild Journal Catalog.
         Starting Update is Completed...
[  OK  ] Started RPC Bind.
[  OK  ] Finished Update is Completed.
[  OK  ] Reached target System Initialization.
[  OK  ] Started dnf makecache --timer.
[  OK  ] Started Daily rotation of log files.
[  OK  ] Started Daily Cleanup of Temporary Directories.
[  OK  ] Reached target Timer Units.
[  OK  ] Listening on bootupd.socket.
[  OK  ] Listening on D-Bus System Message Bus Socket.
[  OK  ] Reached target Socket Units.
         Starting D-Bus System Message Bus...
[  OK  ] Started D-Bus System Message Bus.
[  OK  ] Reached target Basic System.
         Starting Network Manager...
         Starting Restore /run/initramfs on shutdown...
         Starting OpenSSH ecdsa Server Key Generation...
         Starting OpenSSH ed25519 Server Key Generation...
         Starting OpenSSH rsa Server Key Generation...
[  OK  ] Reached target User and Group Name Lookups.
         Starting User Login Management...
         Starting Disk Manager...
[  OK  ] Finished Restore /run/initramfs on shutdown.
[  OK  ] Finished OpenSSH ecdsa Server Key Generation.
         Starting Authorization Manager...
         Starting Hostname Service...
[  OK  ] Started User Login Management.
[  OK  ] Finished OpenSSH ed25519 Server Key Generation.
[  OK  ] Started Hostname Service.
         Starting Network Manager Script Dispatcher Service...
[  OK  ] Started Authorization Manager.
[  OK  ] Started Network Manager.
[  OK  ] Started Disk Manager.
[  OK  ] Reached target Network.
         Starting Network Manager Wait Online...
         Starting Enable periodic update of entitlement certificates....
         Starting Permit User Sessions...
[  OK  ] Started Enable periodic update of entitlement certificates..
[  OK  ] Started Network Manager Script Dispatcher Service.
[  OK  ] Finished Permit User Sessions.
[  OK  ] Started Console Getty.
[  OK  ] Reached target Login Prompts.
[  OK  ] Finished Network Manager Wait Online.
[  OK  ] Reached target Network is Online.
[  OK  ] Finished OpenSSH rsa Server Key Generation.
[  OK  ] Reached target sshd-keygen.target.
         Starting OpenSSH server daemon...
[  OK  ] Started OpenSSH server daemon.
[  OK  ] Reached target Multi-User System.
[  OK  ] Reached target Graphical Interface.
         Starting Record Runlevel Change in UTMP...
[  OK  ] Finished Record Runlevel Change in UTMP.

AlmaLinux 9.20241112.0.4 (Seafoam Ocelot)
Kernel 6.16.3-2-cachyos on an x86_64

ea06cca48ab9 login:

[silent-sixth-cargo]

its more like booting a iso containerized , which is not efficient & resource wasteful , causes delay .

just enabling systemd inside container minimally , more like what redhat did, is far more useful & efficient .

[silent-sixth-cargo]

not fond of bootc in the context of enabling systemd, its more like vm administration but containerized ,
thats not what the thread is for

bootc produces bootable containerized image << systemd enabled container has just systemd enabled inside container with its components.

[leleobhz]

its more like booting a iso containerized , which is not efficient & resource wasteful , causes delay .

just enabling systemd inside container minimally , more like what redhat did, is far more useful & efficient .

No, is not and my example just proved it. All tree are the same as a bootable rootfs. There is NO RELATION WITH ISO OR IMAGING inside container. Just metatags that allows to boot and everything on container is a prepared rootfs with proper /lib/modules.

This work is more general, standarized and open than just create a way just to run systemd. If you want just this, proper Dockerfile are able to do this job. Sugestion to use bootc can lead very quickly to a CachyOS immutable stack and containers with just one job, optimizing development.

[leleobhz]

not fond of bootc in the context of enabling systemd, its more like vm administration but containerized , thats not what the thread is for

bootc produces bootable containerized image << systemd enabled container has just systemd enabled inside container with its components.

No is not. bootc and ostree ARE NOT raw images and does not relate to VM.

[silent-sixth-cargo]

watch the log you have pasted clearly
'''
[ OK ] Started Authorization Manager.
[ OK ] Started Network Manager.
[ OK ] Started Disk Manager.
[ OK ] Reached target Network.
Starting Network Manager Wait Online...
'''

it does not need to behave 100% like iso , 10% is more than enough to reject.

[leleobhz]

watch the log you have pasted clearly ''' [ OK ] Started Authorization Manager. [ OK ] Started Network Manager. [ OK ] Started Disk Manager. [ OK ] Reached target Network. Starting Network Manager Wait Online... '''

it does not need to behave 100% like iso , 10% is more than enough to reject.

Read the documents for bootc. You can enable/disable at Dockerfile the systemd units you want or not. All systemd does behave like this because systemd behaves like this, since it's a init system.

[leleobhz]

Also, does not make any sense do a image that just have systemd. You can do this using Dockerfiles and does not bring it self any benefit to cachyos. Bootc in comparison bring cachyos a immutable capacity and also provides what systemd users want by changing the behaviour in Dockerfile. I see no point to spend dev times to create something that will attend just one use case when there is a more general approach for same issue.