[systemd-devel] Where to install UKI cmdline addons in the root partition
Hello everyone, Sorry for the back-to-back emails, but I realized I could use this mailing list to bring up another topic related to UKI addons. This is the same as I wrote in https://github.com/systemd/systemd/issues/29372 : I think we need some agreement to decide that if distros want to ship rpms containing default signed UKI addons, they should all go in the same place in the root partition. By putting them there, we offer the user the possibility to keep the ESP clean and lightweight (as there is not much space available in there IIRC), and the user can simply cp the addons from the root partition into the desired ESP to install the addon, and rm to remove them. But I still think it is important to have some agreement, and document it somewhere. What do you think? Thank you, Emanuele
[systemd-devel] how to use systemd-sysext addons and systemd-stub to extend an UKI initrd
Hello everyone, As the title suggests, I am trying to extend an UKI initrd via systemd-sysext addons/extensions. I contributed to the systemd-stub UKI addons to extend the kernel command line, so I know how they works and planning to give a talk about them soon. However, I would like to get the full picture by using the same mechanism but with systemd-sysext addons to extend also initrd. As I understood, a systemd-sysext addon in /boot/efi/EFI/Linux/.efi.extra.d will be put in /.extra/sysext by systemd-stub, and then will be picked up by systemd-sysext to be added into the initrd. I am using Fedora, I created my UKI devel.efi, and made sure (just for safety) that the initrd contains the systemd-sysext module, as I generated it with dracut. The UKI is created with freshly compiled systemd-stub from commit 5808300c44. Kernel is 6.6.0-0.rc1.20230915git9fdfb15a3dbf.17.fc40.x86_64 Then, I created a super dumb extension and put it in the right location: mkdir extension cd extension/ vi ciao.txt mkdir usr cp ciao.txt usr/ciao2.txt cat /etc/os-release mkdir -p usr/lib/extension-release.d/ echo ID=fedora > usr/lib/extension-release.d/extension-release.extension echo VERSION_ID=40 >> usr/lib/extension-release.d/extension-release.extension cat usr/lib/extension-release.d/extension-release.extension cd .. mksquashfs extension extension.raw mv extension.raw /boot/efi/EFI/Linux/devel.efi.extra.d/ At this point, I set the UKI to be used at next boot and rebooted. However, as you can imagine, this is not enough to make it work. Upon inspecting systemd-sysext status, I see # systemctl status systemd-sysext --no-pager -l × systemd-sysext.service - Merge System Extension Images into /usr/ and /opt/ Loaded: loaded (/usr/lib/systemd/system/systemd-sysext.service; disabled; preset: disabled) Drop-In: /usr/lib/systemd/system/service.d └─10-timeout-abort.conf Active: failed (Result: exit-code) since Mon 2023-12-04 11:02:15 EST; 30min ago Condition: start condition unmet at Mon 2023-12-04 11:16:55 EST; 15min ago ├─ ConditionDirectoryNotEmpty=|/etc/extensions was not met ├─ ConditionDirectoryNotEmpty=|/run/extensions was not met ├─ ConditionDirectoryNotEmpty=|/var/lib/extensions was not met └─ ConditionDirectoryNotEmpty=|/.extra/sysext was not met Docs: man:systemd-sysext.service(8) Main PID: 479 (code=exited, status=1/FAILURE) CPU: 11ms Dec 04 11:02:15 localhost systemd-sysext[479]: Failed to read metadata for image extension: No such device Dec 04 11:02:15 localhost systemd[1]: systemd-sysext.service: Main process exited, code=exited, status=1/FAILURE Dec 04 11:02:15 localhost systemd[1]: systemd-sysext.service: Failed with result 'exit-code'. Dec 04 11:02:15 localhost systemd[1]: Failed to start systemd-sysext.service - Merge System Extension Images into /usr/ and /opt/. Dec 04 11:16:55 ibm-p8-kvm-03-guest-02.virt.pnr.lab.eng.rdu2.redhat.com systemd[1]: systemd-sysext.service - Merge System Extension Images into /usr/ and /opt/ was skipped because no trigger condition checks were met. So question number 1: what went wrong here? How do I debug it? --- Next question is (and probably next problem too), how to actually sign an extension? According to the --image-policy doc, I see When run in the initrd and operating on a system extension image stored in the /.extra/sysext/ directory a slightly stricter policy is used by default: "root=signed+absent:usr=signed+absent" Which means this .raw (assuming I built it correctly) needs to be signed. How can I sign a disk image? I tried looking for dm-verify but I don't understand how to do that, nor if there is a systemd tool that can do it. I am hoping to find something like ukify to create and sign sysext addons very easily. --- Supposing I manage to do all of the above, my next question would be how/if to override the /lib folder instead of the traditional /usr or /opt, as for example I might want to add another kernel module into the UKI. --- Last but not least is where is the documentation for this. I couldn't find anything at all about systemd-sysext, and therefore I would be very very happy to write (other than presenting it) some doc to make the life easier to anyone like me that is looking forward to using these new features. Thank you in advance and sorry for the wall of text, Emanuele
Re: [systemd-devel] Configure netdev RPS using systemd-networkd
On Mon, Dec 4, 2023 at 5:01 AM Renjaya Raga Zenta wrote: > Hi, > > We want to implement our networking using systemd-networkd. We think > systemd is stable enough right now, so we want to try more "systemd-only" > solution. > > In our environment, we use RPS (Receive Packet Steering) for load balancing > and scaling. It's a kernel feature implemented a long time ago. You could > visit the documentation at > https://www.kernel.org/doc/html/latest/networking/scaling.html. > > Currently, we manually do this after network interface is configured: > > echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus > > where f is bitmap mask , it means to utilize 4 cpus. > > Will this use case be implemented in systemd-networkd? Or should we use a > third party solution such as networkd-broker or networkd-dispatcher? > > Thanks. > It is kinda sad the kernel never choose other default than disabled.. If you post a patchset it would be nice if it also cover the other scaling features and to have an "auto" or "yes" mode that sets it up magically for you.
Re: [systemd-devel] Fixup-support for kernel command line provided from UKI in systemd-stub
HI @Aleksandar Kostadinov User space doesn't have that information to fetch. Thanks & Regards, Venkat Thogaru -Original Message- From: Aleksandar Kostadinov Sent: Monday, December 4, 2023 3:40 PM To: VENKAT Nagaraj THOGARU (QUIC) Cc: Luca Boccassi ; SystemD Devel Subject: Re: [systemd-devel] Fixup-support for kernel command line provided from UKI in systemd-stub On Mon, Dec 4, 2023 at 7:24 AM VENKAT Nagaraj THOGARU (QUIC) wrote: ... > We have an application in Linux which need this information. While not a direct answer to your question, why not have the application read this data like `dmidecode` can do?
Re: [systemd-devel] Fixup-support for kernel command line provided from UKI in systemd-stub
Applications can use credentials: https://systemd.io/CREDENTIALS/ On Mon, 4 Dec 2023 at 05:22, VENKAT Nagaraj THOGARU (QUIC) wrote: > > HI @Luca Boccassi, > > > > We have an application in Linux which need this information. > > > > Thanks & Regards, > > Thogaru Venkat > > > > From: Luca Boccassi > Sent: Friday, December 1, 2023 3:31 PM > To: VENKAT Nagaraj THOGARU (QUIC) > Cc: SystemD Devel > Subject: Re: [systemd-devel] Fixup-support for kernel command line provided > from UKI in systemd-stub > > > > Why does the kernel need to know all that? > > On Fri, 1 Dec 2023, 06:43 VENKAT Nagaraj THOGARU (QUIC), > wrote: > > HI @Luca Boccassi, > > Looks like this addons is to append additional cmd-line parameters with > static data. > Our requirement is to append additional cmd-line parameters with dynamic > device specific data like, serial number read from the device during runtime. > > Thanks & Regards, > Venkat Thogaru > > -Original Message- > From: Luca Boccassi > Sent: Tuesday, November 28, 2023 4:34 PM > To: VENKAT Nagaraj THOGARU (QUIC) > Cc: systemd-devel@lists.freedesktop.org > Subject: Re: [systemd-devel] Fixup-support for kernel command line provided > from UKI in systemd-stub > > On Tue, 28 Nov 2023 at 10:30, VENKAT Nagaraj THOGARU (QUIC) > wrote: > > > > Hi @systemd-devel@lists.freedesktop.org, > > > > > > > > We have a query on Fixup-support for kernel command line provided from UKI > > in system-stub. > > > > > > > > Just like we have the Fixup support for DTB provided from UKI in > > systemd-stub[via EFI_DT_FIXUP_PROTOCOL], do we have any similar fixup > > support for Kernel command line provided from UKI ? If not, is there any > > ongoing effort to support this? > > > > > > > > Our requirement is to dynamically append the additional command line > > parameters to the command line provided from UKI. > > Check the addons section: > > https://www.freedesktop.org/software/systemd/man/latest/systemd-stub.html#Companion%20Files
Re: [systemd-devel] Fixup-support for kernel command line provided from UKI in systemd-stub
On Mon, Dec 4, 2023 at 7:24 AM VENKAT Nagaraj THOGARU (QUIC) wrote: ... > We have an application in Linux which need this information. While not a direct answer to your question, why not have the application read this data like `dmidecode` can do?
Re: [systemd-devel] Configure netdev RPS using systemd-networkd
On Mo, 04.12.23 14:59, Renjaya Raga Zenta (ragaze...@gmail.com) wrote: > Hi, > > We want to implement our networking using systemd-networkd. We think > systemd is stable enough right now, so we want to try more "systemd-only" > solution. > > In our environment, we use RPS (Receive Packet Steering) for load balancing > and scaling. It's a kernel feature implemented a long time ago. You could > visit the documentation at > https://www.kernel.org/doc/html/latest/networking/scaling.html. > > Currently, we manually do this after network interface is configured: > > echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus > > where f is bitmap mask , it means to utilize 4 cpus. > > Will this use case be implemented in systemd-networkd? Or should we use a > third party solution such as networkd-broker or networkd-dispatcher? I see no reason why we wouldn't add a high-level option for this to .link files. We are happy to review/merge a patch. Please submit via GitHub. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] systemd: questions about dbus dependency service
On Mo, 04.12.23 13:01, Pintu Agarwal (pintu.p...@gmail.com) wrote: > Hi, > Any comments or suggestions on the below ? I already replied. https://lists.freedesktop.org/archives/systemd-devel/2023-November/049706.html Lennart -- Lennart Poettering, Berlin
[systemd-devel] Configure netdev RPS using systemd-networkd
Hi, We want to implement our networking using systemd-networkd. We think systemd is stable enough right now, so we want to try more "systemd-only" solution. In our environment, we use RPS (Receive Packet Steering) for load balancing and scaling. It's a kernel feature implemented a long time ago. You could visit the documentation at https://www.kernel.org/doc/html/latest/networking/scaling.html. Currently, we manually do this after network interface is configured: echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus where f is bitmap mask , it means to utilize 4 cpus. Will this use case be implemented in systemd-networkd? Or should we use a third party solution such as networkd-broker or networkd-dispatcher? Thanks.
