[systemd-devel] How to show cylon animation on purpose?
Hi list, Is it possible to create a startup service which triggers cylon animation? I see that the animation is related to running jobs. Sometimes I see it when shutting down. I'm curious if it can be triggered on purpose. Thanks.
Re: How to correctly setup the partition table for systemd-sysupdate?
Hi, thank you for the answer. I use the linux-generic partition to put raw images as the [Source] for systemd-sysupdate. For now, I don't want to spawn a http server for this. So you mean I need to have this kind of partition table? +-+--+++--+ | esp | root | empty root | empty root | linux-generic for put raw images | +-+--+++--+ On Mon, Jan 8, 2024 at 8:33 PM Adrian Vovk wrote: > You shouldn't be using a linux-generic partition for updates. You need (at > least) two of the same kind of partition to switch between whenever there's > an update > > On Mon, Jan 8, 2024, 06:46 Renjaya Raga Zenta wrote: > >> Hi, >> >> I've been experimenting with systemd-sysupdate, trying to understand how >> it works. >> >> I created a Fedora 39 image¹ with mkosi from the GitHub repo. It has 3 >> partitions: >> 1) esp >> 2) root >> 3) linux-generic (to put updates) >> >> The root and third partition will be expanded on firstboot via >> systemd-growfs². I also configured the third partition to be automounted >> with udev rules. >> >> I created a configuration file in /usr/lib/sysupdate.d: 10-root.conf >> [Transfer] >> ProtectVersion=%A >> >> [Source] >> Type=regular-file >> Path=/run/media/system/UPDATES >> MatchPattern=de...@v.root-x86-64.raw >> >> [Target] >> Type=partition >> Path=auto >> MatchPartitionType=root >> >> Let's say, first, I created version 0.1.0: demo_0.1.0.raw, then I created >> version 0.1.1 with SplitArtifacts=yes in mkosi.conf. So I had >> demo_0.1.1.esp.raw and demo_0.1.1.root-x86-64.raw. I put >> demo_0.1.1.root-x86-x64.raw to /run/media/system/UPDATES. >> >> I ran /usr/lib/systemd/systemd-sysupdate list, it correctly showed the >> available update candidate. But then I ran >> /usr/lib/systemd/systemd-sysupdate update, it showed an error about the >> partition table. >> >> "Partition table has less than two partition slots of the right type >> 4f68bce3---truncated (root-x86-64), refusing." >> >> I've tried adding more 2 root partition slots, but still got the same >> error. I've also tried adding PaddingMinBytes/PaddingMaxBytes in >> /usr/lib/repart.d/. >> >> Maybe I missed something here. How to correctly setup the partition table >> for systemd-sysupdate? >> >> Thanks. >> >> [1] I'm working on Debian stable based image, but unfortunately >> systemd-sysupdate is not available (not compiled). So I tried Fedora >> instead. >> [2] Before systemd 255, the GrowFileSystem flag did not work as expected, >> but there is a workaround. Hopefully the patches will be backported. >> >
How to correctly setup the partition table for systemd-sysupdate?
Hi, I've been experimenting with systemd-sysupdate, trying to understand how it works. I created a Fedora 39 image¹ with mkosi from the GitHub repo. It has 3 partitions: 1) esp 2) root 3) linux-generic (to put updates) The root and third partition will be expanded on firstboot via systemd-growfs². I also configured the third partition to be automounted with udev rules. I created a configuration file in /usr/lib/sysupdate.d: 10-root.conf [Transfer] ProtectVersion=%A [Source] Type=regular-file Path=/run/media/system/UPDATES MatchPattern=de...@v.root-x86-64.raw [Target] Type=partition Path=auto MatchPartitionType=root Let's say, first, I created version 0.1.0: demo_0.1.0.raw, then I created version 0.1.1 with SplitArtifacts=yes in mkosi.conf. So I had demo_0.1.1.esp.raw and demo_0.1.1.root-x86-64.raw. I put demo_0.1.1.root-x86-x64.raw to /run/media/system/UPDATES. I ran /usr/lib/systemd/systemd-sysupdate list, it correctly showed the available update candidate. But then I ran /usr/lib/systemd/systemd-sysupdate update, it showed an error about the partition table. "Partition table has less than two partition slots of the right type 4f68bce3---truncated (root-x86-64), refusing." I've tried adding more 2 root partition slots, but still got the same error. I've also tried adding PaddingMinBytes/PaddingMaxBytes in /usr/lib/repart.d/. Maybe I missed something here. How to correctly setup the partition table for systemd-sysupdate? Thanks. [1] I'm working on Debian stable based image, but unfortunately systemd-sysupdate is not available (not compiled). So I tried Fedora instead. [2] Before systemd 255, the GrowFileSystem flag did not work as expected, but there is a workaround. Hopefully the patches will be backported.
Re: [systemd-devel] How to debug systemd-pcrphase-initrd.service failure
Yes, I think now I understand that mkosi will build default initrd image without tpm2-tss libraries. Perhaps because the package names are different for each distro. I need to build the initrd image separately at first, then use it to build OS image with --initrd flag. Thanks. On Wed, Dec 6, 2023 at 8:02 PM Lennart Poettering wrote: > On Mi, 06.12.23 18:28, Renjaya Raga Zenta (ragaze...@gmail.com) wrote: > > > Hi, > > > > I am exploring OS image building with mkosi. It works great until I add > TPM > > 2.0 in qemu. > > > > I found that the systemd-pcrphase-initrd.service failed. There are 3 > > pcrphase service: > > > > 1. systemd-pcrphase-initrd.service (failed) > > 2. systemd-pcrphase.service (ok) > > 3. systemd-pcrphase-sysinit.service (ok) > > So the latter two run from the host fs, the first one from the initrd fs. > > > Related journal log: > > systemd[1]: Failed to start systemd-pcrphase-initrd.service - TPM2 PCR > > Barrier (initrd). > > ... > > systemd-pcrphase[130]: Failed to load TPM2 libraries: Operation not > > supported > > ... > > It appears you are lacking the tpm2-tss libraries in your initrd image. > > Lennart > > -- > Lennart Poettering, Berlin > -- Renjaya Raga Zenta Mobile: +62 811 572 4400
[systemd-devel] How to debug systemd-pcrphase-initrd.service failure
Hi, I am exploring OS image building with mkosi. It works great until I add TPM 2.0 in qemu. I found that the systemd-pcrphase-initrd.service failed. There are 3 pcrphase service: 1. systemd-pcrphase-initrd.service (failed) 2. systemd-pcrphase.service (ok) 3. systemd-pcrphase-sysinit.service (ok) Related journal log: systemd[1]: Failed to start systemd-pcrphase-initrd.service - TPM2 PCR Barrier (initrd). ... systemd-pcrphase[130]: Failed to load TPM2 libraries: Operation not supported ... My mkosi.conf: [Distribution] Distribution=debian Repositories=contrib,non-free,non-free-firmware Release=bookworm [Output] Format=disk ImageId=test ImageVersion=0.1.0 [Content] Bootable=yes Locale=en_US.UTF-8 LocaleMessages=en_US.UTF-8 Keymap=us Timezone=Asia/Jakarta Hostname=test KernelCommandLine= console=ttyS0 console=tty1 loglevel=4 Packages= amd64-microcode apt apt-transport-https bash-completion ca-certificates coreutils curl dbus-broker debian-archive-keyring dosfstools e2fsprogs efibootmgr file gdisk intel-microcode jq less libtss2-dev linux-image-amd64 locales man-db openssh-client parted systemd systemd-boot systemd-resolved systemd-sysv systemd-timesyncd tzdata udev usbutils zstd [Validation] SecureBoot=yes Bookworm still uses systemd 252, is that related? Previously without the libtss2-dev package installed, all 3 services above failed. So perhaps the initrd doesn't have libtss2-dev installed. How to include it then? Thanks
[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.
[systemd-devel] Create a tmpfile with content from output of executing a command
Hi list, I'd like to create a temporary file using systemd-tmpfiles. The file will contain merge of multiple text files. Can the argument field in tmpfiles.d be a path to an executable? So I can create a script to print the content of those multiple files. Or maybe there is another way to do this? Thank you.
Re: [systemd-devel] Periodically switch volatile to persistent journald and vice versa
Hi, was my email not coming through? Regards. On Tue, Sep 12, 2023 at 12:06 PM Renjaya Raga Zenta < renjaya.ze...@formulatrix.com> wrote: > 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. > >
[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.
