[systemd-devel] Periodically switch volatile to persistent journald and vice versa
Hi, We have custom embedded device using SD Card as the main storage. I think there are some concerns regarding how journald write the logs, that may cause massive write amplification and that's bad for a standard SD Card. Journald has Storage= option, I could use Storage=volatile and ForwardToSyslog=yes then the disk writes seems acceptable. I could still do systemctl status and journalctl, but the logs won't be available the next reboot. Journalctl has --flush command, to flush any log data stored in /run/log/journal/ into /var/log/journal/. It also has --relinquish-var command, to do the reverse operation of --flush. Correct me if I'm wrong, if I do journalctl --flush, journald will write in bulk, isn't it? So the write amplification has less effect. If it's true, then I think periodically switching journald storage may help. 1. First, I set Storage=volatile 2. After a while, I change it to Storage=persistent or Storage=auto, then journalctl --flush (is restarting systemd-journald necessary?) 3. Then, I change it again to Storage=volatile and journalctl --relinquish-var (again, is restarting systemd-journald required?). So, is this a good approach? Or is my assumption is wrong. Please kindly advise. If it isn't wrong, the next question is when should I switch from /run to /var? The /run is using tmpfs, so it's in memory. I need to do the switch before the journal log size in /run up to 50 MB for example. How to do that? Thank you.
Re: [systemd-devel] Fedora 38 and signed PCR binding
On Mon, Sep 11, 2023 at 2:57 PM Lennart Poettering wrote: > > On Mo, 11.09.23 14:48, Aleksandar Kostadinov (akost...@redhat.com) wrote: > > > Hi again. I tried to boot from UKI to no avail. > > > > First created a "db" certificate > > > openssl req -newkey rsa:2048 -nodes -keyout db_arch.key -new -x509 > > > -sha256 -days 3650 -subj "/CN=My DB cert/" -out db.pem > > > openssl x509 -outform DER -in db.pem -out db.crt > > > > Then uploaded it to secure boot trust VIA USB drive and the UEFI seup. > > > > Then created UKI: > > > /usr/lib/systemd/ukify \ > > > /lib/modules/6.4.12-200.fc38.x86_64/vmlinuz \ > > > /boot/initramfs-6.4.12-200.fc38.x86_64.img \ > > > --pcr-private-key=/etc/systemd/tpm2-pcr-private-key.pem \ > > > --pcr-public-key=/etc/systemd/tpm2-pcr-public-key.pem \ > > > --phases='enter-initrd' \ > > > --pcr-banks=sha1,sha256 \ > > > --secureboot-private-key=/etc/secure_boot/db.key \ > > > --secureboot-certificate=/etc/secure_boot/db.pem \ > > > --sign-kernel \ > > > --cmdline='ro rhgb' > > > > Then added a boot entry: > > > efibootmgr -c -d /dev/sda -p 1 -l /EFI/FEDORA/UKI/VMLINUZ612.EFI -L > > > "Fedora UKI" > > > > Unfortunately when trying to boot this I get: > > > Bad kernel image: Load Error > > That suggests the kernel you picked does not carry a correct PE/MZ > signature. i.e. we generate that error typically if we can#t jump into > it because it doesn't come with the right PE headers. This is just a standard kernel coming with Fedora 38. I didn't modify it. Also initrd as generated by dracut. > $ hexdump -C -n4 < /lib/modules/6.4.12-200.fc38.x86_64/vmlinuz > 4d 5a ea 07 |MZ..| > $ file /lib/modules/6.4.12-200.fc38.x86_64/vmlinuz > /lib/modules/6.4.12-200.fc38.x86_64/vmlinuz: Linux kernel x86 boot executable > bzImage, version 6.4.12-200.fc38.x86_64 > (mockbuild@30894952d3244f1ab967aeda9ed417f6) #1 SMP PREEMPT_DYNAMIC Wed Aug > 23 17:46:49 UTC 2023, RO-rootFS, swap_dev 0XD, Normal VGA Any suggestions on how to fix it? If it matters -- ukify 253 (253.7-1.fc38)
Re: [systemd-devel] [PATCH 0/1] x86/kexec: UKI support
On Mon, Sep 11, 2023 at 7:15 PM Jarkko Sakkinen wrote: > > On Sat Sep 9, 2023 at 7:18 PM EEST, Jan Hendrik Farr wrote: > > Hello, > > > > this patch implements UKI support for kexec_file_load. It will require > > support > > in the kexec-tools userspace utility. For testing purposes the following > > can be used: > > https://github.com/Cydox/kexec-test/ > > > > There has been discussion on this topic in an issue on GitHub that is > > linked below > > for reference. > > > > > > Some links: > > - Related discussion: https://github.com/systemd/systemd/issues/28538 > > - Documentation of UKIs: > > https://uapi-group.org/specifications/specs/unified_kernel_image/ > > > > Jan Hendrik Farr (1): > > x86/kexec: UKI support > > > > arch/x86/include/asm/kexec-uki.h | 7 ++ > > arch/x86/include/asm/parse_pefile.h| 32 +++ > > arch/x86/kernel/Makefile | 2 + > > arch/x86/kernel/kexec-uki.c| 113 + > > arch/x86/kernel/machine_kexec_64.c | 2 + > > arch/x86/kernel/parse_pefile.c | 110 > > crypto/asymmetric_keys/mscode_parser.c | 2 +- > > crypto/asymmetric_keys/verify_pefile.c | 110 +++- > > crypto/asymmetric_keys/verify_pefile.h | 16 > > 9 files changed, 278 insertions(+), 116 deletions(-) > > create mode 100644 arch/x86/include/asm/kexec-uki.h > > create mode 100644 arch/x86/include/asm/parse_pefile.h > > create mode 100644 arch/x86/kernel/kexec-uki.c > > create mode 100644 arch/x86/kernel/parse_pefile.c > > > > -- > > 2.40.1 > > What the heck is UKI? Unified Kernel Images. More details available here: https://uapi-group.org/specifications/specs/unified_kernel_image/ It's a way of creating initramfs-style images as fully generic, reproducible images that can be built server-side. It is a requirement for creating locked down Linux devices for appliances that can be tamper-resistant too. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [systemd-devel] [PATCH 0/1] x86/kexec: UKI support
On Sat Sep 9, 2023 at 7:18 PM EEST, Jan Hendrik Farr wrote: > Hello, > > this patch implements UKI support for kexec_file_load. It will require support > in the kexec-tools userspace utility. For testing purposes the following can > be used: > https://github.com/Cydox/kexec-test/ > > There has been discussion on this topic in an issue on GitHub that is linked > below > for reference. > > > Some links: > - Related discussion: https://github.com/systemd/systemd/issues/28538 > - Documentation of UKIs: > https://uapi-group.org/specifications/specs/unified_kernel_image/ > > Jan Hendrik Farr (1): > x86/kexec: UKI support > > arch/x86/include/asm/kexec-uki.h | 7 ++ > arch/x86/include/asm/parse_pefile.h| 32 +++ > arch/x86/kernel/Makefile | 2 + > arch/x86/kernel/kexec-uki.c| 113 + > arch/x86/kernel/machine_kexec_64.c | 2 + > arch/x86/kernel/parse_pefile.c | 110 > crypto/asymmetric_keys/mscode_parser.c | 2 +- > crypto/asymmetric_keys/verify_pefile.c | 110 +++- > crypto/asymmetric_keys/verify_pefile.h | 16 > 9 files changed, 278 insertions(+), 116 deletions(-) > create mode 100644 arch/x86/include/asm/kexec-uki.h > create mode 100644 arch/x86/include/asm/parse_pefile.h > create mode 100644 arch/x86/kernel/kexec-uki.c > create mode 100644 arch/x86/kernel/parse_pefile.c > > -- > 2.40.1 What the heck is UKI? BR, Jarkko
Re: [systemd-devel] systemd-repart /etc automount via discoverable partition specification
On Mon, Sep 11, 2023 at 11:49 AM Lennart Poettering wrote: > > On Mo, 11.09.23 11:39, Nils Kattenbeck (nilskem...@gmail.com) wrote: > > > On Mon, Sep 11, 2023, 10:54 Lennart Poettering > > wrote: > > > > > The discoverable partition scheme has no concept of /etc/ discovery. It > > > focusses on three basic setups: > > > > > > 1. writable root fs that contains /etc/, /var/ and /usr/ directly. > > > 2. writable root fs that contains /etc/ and /var/ and gets an > > >immutable /usr/ mounted in > > > 3. immutable root fs that contains /etc/ and /usr/ directly and gets a > > >writable /var/ mounted in. (the latter possibly as tmpfs, for truly > > >stateless systems) > > > > There is also 4. with a writeable root which only contains /etc, an > > immutable /usr and a temporary /var. Though I guess that can be covered > > with the existing DPS...? > > That's pretty much the same as 2, except that /var is overmounted with > a tmpfs. i.e. you would simply place /etc/fstab in there, that says > /var is tmpfs. Yeah I figured as much, thanks for confirming. > > My use case is basically 2, /etc has to be writeable to persist the > > machine-id across reboots, /var also has to be writeable and /usr can be > > immutable. > > > > The problem I am then likely facing is that I create the partitions wrong. > > I am using mkosi and tried several different repart.d configuration with > > type=root+type=usr, type=root+type=var+type=use, and different CopyFiles= > > and Exclude(Target)Files= but none of them seemed to have worked. > > if your /var/ is supposed to be a tmpfs, then don't mention it to > mkosi/repart, just put an /etc/fstab into place that dicates /var is > mounted as tmpfs. > > Other than that you should just be able to use Type=root and Type=usr then. > > > Are there special requirements for what the respective partitions must or > > shall not contain when using several auto-discovered partitions? Or should > > I ask on the mkosi issue tracker? > > If you have just root + usr then this should be a pretty common > situation for mkosi, it's not special and should just work. > > Lennart Do I have to write the usr/ partition in the fstab then if it is supposed to be discovered automatically? When booting the image (without an fstab) I get dropped into the emergency target as initrd-switch-root failed. It fails because /etc/os-release is symlinked into usr/ and usr/ is not mounted under /sysroot/. I have read the bootup man page to maybe find units whose output might help me troubleshoot this better but apart from affirming that a sysroot-usr.mount unit did *not* exist I have not been able to troubleshoot this any further. My repart.d files are as follows: # 10-root.conf [Partition] Type=root Format=ext4 SizeMaxBytes=5G CopyFiles=/etc CopyFiles=/var Minimize=guess # 20-usr.conf # Format= and Minimize= would be erofs/best once everything is final [Partition] Type=usr Format=ext4 SizeMaxBytes=3G CopyFiles=/usr:/ Minimize=guess Nils
Re: [systemd-devel] Fedora 38 and signed PCR binding
On Mo, 11.09.23 14:48, Aleksandar Kostadinov (akost...@redhat.com) wrote: > Hi again. I tried to boot from UKI to no avail. > > First created a "db" certificate > > openssl req -newkey rsa:2048 -nodes -keyout db_arch.key -new -x509 -sha256 > > -days 3650 -subj "/CN=My DB cert/" -out db.pem > > openssl x509 -outform DER -in db.pem -out db.crt > > Then uploaded it to secure boot trust VIA USB drive and the UEFI seup. > > Then created UKI: > > /usr/lib/systemd/ukify \ > > /lib/modules/6.4.12-200.fc38.x86_64/vmlinuz \ > > /boot/initramfs-6.4.12-200.fc38.x86_64.img \ > > --pcr-private-key=/etc/systemd/tpm2-pcr-private-key.pem \ > > --pcr-public-key=/etc/systemd/tpm2-pcr-public-key.pem \ > > --phases='enter-initrd' \ > > --pcr-banks=sha1,sha256 \ > > --secureboot-private-key=/etc/secure_boot/db.key \ > > --secureboot-certificate=/etc/secure_boot/db.pem \ > > --sign-kernel \ > > --cmdline='ro rhgb' > > Then added a boot entry: > > efibootmgr -c -d /dev/sda -p 1 -l /EFI/FEDORA/UKI/VMLINUZ612.EFI -L "Fedora > > UKI" > > Unfortunately when trying to boot this I get: > > Bad kernel image: Load Error That suggests the kernel you picked does not carry a correct PE/MZ signature. i.e. we generate that error typically if we can#t jump into it because it doesn't come with the right PE headers. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Fedora 38 and signed PCR binding
Hi again. I tried to boot from UKI to no avail. First created a "db" certificate > openssl req -newkey rsa:2048 -nodes -keyout db_arch.key -new -x509 -sha256 > -days 3650 -subj "/CN=My DB cert/" -out db.pem > openssl x509 -outform DER -in db.pem -out db.crt Then uploaded it to secure boot trust VIA USB drive and the UEFI seup. Then created UKI: > /usr/lib/systemd/ukify \ > /lib/modules/6.4.12-200.fc38.x86_64/vmlinuz \ > /boot/initramfs-6.4.12-200.fc38.x86_64.img \ > --pcr-private-key=/etc/systemd/tpm2-pcr-private-key.pem \ > --pcr-public-key=/etc/systemd/tpm2-pcr-public-key.pem \ > --phases='enter-initrd' \ > --pcr-banks=sha1,sha256 \ > --secureboot-private-key=/etc/secure_boot/db.key \ > --secureboot-certificate=/etc/secure_boot/db.pem \ > --sign-kernel \ > --cmdline='ro rhgb' Then added a boot entry: > efibootmgr -c -d /dev/sda -p 1 -l /EFI/FEDORA/UKI/VMLINUZ612.EFI -L "Fedora > UKI" Unfortunately when trying to boot this I get: > Bad kernel image: Load Error It seems like trying to boot because momentarily I see a mouse cursor and then terminal resets back and I see the error message. Actually I see it twice before the grub bootloader entry gets picked up. Any ideas what I might be doing wrong? This is on Fedora 38. On Tue, Sep 5, 2023 at 1:20 PM Lennart Poettering wrote: > > On Sa, 02.09.23 22:22, Aleksandar Kostadinov (akost...@redhat.com) wrote: > > > Looking at the PR [1] it looks like I need to do a lot of things at > > each update manually. Is the thing in the comment the only thing I > > need to do or are there other things as well? > > There's nowadays "ukify" that does all of this for you in one > relatively easy step, it's our recommended approach to building UKIs > these days. > > Lennart > > -- > Lennart Poettering, Berlin >
Re: [systemd-devel] systemd-repart /etc automount via discoverable partition specification
On Mo, 11.09.23 11:39, Nils Kattenbeck (nilskem...@gmail.com) wrote: > On Mon, Sep 11, 2023, 10:54 Lennart Poettering > wrote: > > > On So, 10.09.23 00:33, Nils Kattenbeck (nilskem...@gmail.com) wrote: > > > > > Hello, I am currently trying to build a linux image with discoverable > > > partitions in an A/B+etc+var scheme. > > > > The discoverable partition scheme has no concept of /etc/ discovery. It > > focusses on three basic setups: > > > > 1. writable root fs that contains /etc/, /var/ and /usr/ directly. > > 2. writable root fs that contains /etc/ and /var/ and gets an > >immutable /usr/ mounted in > > 3. immutable root fs that contains /etc/ and /usr/ directly and gets a > >writable /var/ mounted in. (the latter possibly as tmpfs, for truly > >stateless systems) > > There is also 4. with a writeable root which only contains /etc, an > immutable /usr and a temporary /var. Though I guess that can be covered > with the existing DPS...? That's pretty much the same as 2, except that /var is overmounted with a tmpfs. i.e. you would simply place /etc/fstab in there, that says /var is tmpfs. > > It was our assumption that these three cases should cover most > > intended behaviours nicely, i.e. systems with modifiable config, code > > and state. systems with modifiable config and state, but immutable > > code. And finally systems with immutable config and code, but > > modifiable state. > > > > A system where /etc/ was separate from the root fs is not covered by > > the above, because it is not clear what that would get us. if you want > > it immutable, why not stick it on an immutable root fs. And if you > > want it writable, why not stick it on a writable root fs directly? > > My use case is basically 2, /etc has to be writeable to persist the > machine-id across reboots, /var also has to be writeable and /usr can be > immutable. > > The problem I am then likely facing is that I create the partitions wrong. > I am using mkosi and tried several different repart.d configuration with > type=root+type=usr, type=root+type=var+type=use, and different CopyFiles= > and Exclude(Target)Files= but none of them seemed to have worked. if your /var/ is supposed to be a tmpfs, then don't mention it to mkosi/repart, just put an /etc/fstab into place that dicates /var is mounted as tmpfs. Other than that you should just be able to use Type=root and Type=usr then. > Are there special requirements for what the respective partitions must or > shall not contain when using several auto-discovered partitions? Or should > I ask on the mkosi issue tracker? If you have just root + usr then this should be a pretty common situation for mkosi, it's not special and should just work. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] systemd-repart /etc automount via discoverable partition specification
On Mon, Sep 11, 2023, 10:54 Lennart Poettering wrote: > On So, 10.09.23 00:33, Nils Kattenbeck (nilskem...@gmail.com) wrote: > > > Hello, I am currently trying to build a linux image with discoverable > > partitions in an A/B+etc+var scheme. > > The discoverable partition scheme has no concept of /etc/ discovery. It > focusses on three basic setups: > > 1. writable root fs that contains /etc/, /var/ and /usr/ directly. > 2. writable root fs that contains /etc/ and /var/ and gets an >immutable /usr/ mounted in > 3. immutable root fs that contains /etc/ and /usr/ directly and gets a >writable /var/ mounted in. (the latter possibly as tmpfs, for truly >stateless systems) There is also 4. with a writeable root which only contains /etc, an immutable /usr and a temporary /var. Though I guess that can be covered with the existing DPS...? It was out assumption that these three cases should cover most > intended behaviours nicely, i.e. systems with modifiable config, code > and state. systems with modifiable config and state, but immutable > code. And finally systems with immutable config and code, but > modifiable state. > > A system where /etc/ was separate from the root fs is not covered by > the above, because it is not clear what that would get us. if you want > it immutable, why not stick it on an immutable root fs. And if you > want it writable, why not stick it on a writable root fs directly? My use case is basically 2, /etc has to be writeable to persist the machine-id across reboots, /var also has to be writeable and /usr can be immutable. The problem I am then likely facing is that I create the partitions wrong. I am using mkosi and tried several different repart.d configuration with type=root+type=usr, type=root+type=var+type=use, and different CopyFiles= and Exclude(Target)Files= but none of them seemed to have worked. Are there special requirements for what the respective partitions must or shall not contain when using several auto-discovered partitions? Or should I ask on the mkosi issue tracker? Kind regards, Nils >
[systemd-devel] Stopping a PAMName=login graphical session cleanly
Hi all, Roughly following the setup recommended here: https://wayland.pages.freedesktop.org/weston/toc/running-weston.html#running-weston-from-a-systemd-service I'm building a solution for a default, always running user session. It works well, with one exception - how do I stop it cleanly? A trivial example: ```ini # /etc/systemd/system/user-session.service [Service] User=ubuntu PAMName=login TTYPath=/dev/tty1 ExecStart=/usr/bin/systemctl --user start --wait mysession.target ``` ```ini # /etc/systemd/user/mysession.target [Unit] BindsTo=graphical-session.target ``` Stopping user-session.service will just terminate the `systemctl` process and the login session - but not the components of the graphical session. I thought of stopping the `graphical-session.target` instead but that's missing environment: ```ini ExecStop=/usr/bin/systemctl --user stop graphical-session.target ``` ``` Sep 08 07:44:50 ubuntu systemctl[1738]: Failed to connect to bus: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=@.host --user to connect to bus of other user) ``` I can hack XDG_RUNTIME_DIR in (though that sounds wrong), but that still doesn't cover the "this should be synchronous" part - it doesn't wait for the target (or its binds) to actually stop. What am I missing? Thanks! -- Michał (Saviq) Sawicz
Re: [systemd-devel] systemd-repart /etc automount via discoverable partition specification
On So, 10.09.23 00:33, Nils Kattenbeck (nilskem...@gmail.com) wrote: > Hello, I am currently trying to build a linux image with discoverable > partitions in an A/B+etc+var scheme. The discoverable partition scheme has no concept of /etc/ discovery. It focusses on three basic setups: 1. writable root fs that contains /etc/, /var/ and /usr/ directly. 2. writable root fs that contains /etc/ and /var/ and gets an immutable /usr/ mounted in 3. immutable root fs that contains /etc/ and /usr/ directly and gets a writable /var/ mounted in. (the latter possibly as tmpfs, for truly stateless systems) It was out assumption that these three cases should cover most intended behaviours nicely, i.e. systems with modifiable config, code and state. systems with modifiable config and state, but immutable code. And finally systems with immutable config and code, but modifiable state. A system where /etc/ was separate from the root fs is not covered by the above, because it is not clear what that would get us. if you want it immutable, why not stick it on an immutable root fs. And if you want it writable, why not stick it on a writable root fs directly? The design of saying "/etc/ is always part of the rootfs" is also reflecting the fact that /etc/fstab is the map of secondary file systems to mount, i.e. it generally contains references to other file systems that take precedence over the discoverable partition spec, and hence it is crucial that we place it on the first item in the chain so that we can take it into account before looking for other items in the chain. > I know that /usr and /var have a > corresponding partition UUID for automatically mounting them as per > DPS. However, I am not sure how to mount the /etc partition? Do I have > to specify it as the root partition and exclude /usr and /var in it? > Any help would be appreciated. If you want /etc/ split off, then the discoverable partition spec won't help you: you have to mount it explicitly from your initrd. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Documentation question about sd-device
On So, 10.09.23 11:45, CARLOS VILLANUEVA Y SIMON (carvi...@gmail.com) wrote: > Hello all, > > Recently, while updating a code that was using libudev to a more modern > API, sd-device, I could not find some of the functions that are defined at > sd-device.h ( > https://github.com/systemd/systemd/blob/main/src/systemd/sd-device.h) at > the man pages ( > https://www.freedesktop.org/software/systemd/man/sd-device.html), e.g. > functions related with sd_device_monitor among others. > > May I be right or am I missing something? Yeah, the documentation is not entirely complete yet. Sorry! It's such a thankless job! But it's definitely on our TODO list. If you can't guess how things work from the header, let us know, we can provide you here with the necessary info to get things off the ground. Lennart -- Lennart Poettering, Berlin
