Re: [systemd-devel] What condition(s) do .device units wait for?
On 16.09.2023 07:53, Philip Couling wrote: I'm trying to understand what a system is timing out waiting for a device in /etc/fstab when a simple "mount -av" will succeed. To reach systemd, initramfs has already mounted the device as the base layer to an overlay mount used as the root file system, so it's definitely ready to use in the Linux kernel. In /etc/fstab, fsck is set to 0. What condition does systemd wait for that could be timing out on a device that's already mounted? It waits for the device to become known to udev, to be announced to systemd (tag "systemd") and not having SYSTEMD_READY=0 property.
Re: [systemd-devel] What condition(s) do .device units wait for?
.device units wait for *udev* to broadcast the uevent about that device
being added, which happens after udev has 1. received the initial kernel
uevent (either real or produced by systemd-udev-trigger.service) and 2.
finished processing all its .rules for that device (which means everything
that rules launched from RUN= must have exited, etc).
Only devices that udev rules have tagged with TAG+="systemd" will produce
.device units; generally 99-systemd.rules will add that to disk devices.
If any of the rules have marked the device with ENV{SYSTEMD_READY}="0", the
.device unit will keep waiting until another event removes that.
On Sat, Sep 16, 2023, 07:54 Philip Couling wrote:
> I'm trying to understand what a system is timing out waiting for a device
> in /etc/fstab when a simple "mount -av" will succeed.
>
> To reach systemd, initramfs has already mounted the device as the base
> layer to an overlay mount used as the root file system, so it's definitely
> ready to use in the Linux kernel. In /etc/fstab, fsck is set to 0.
>
> What condition does systemd wait for that could be timing out on a device
> that's already mounted?
>
>
[systemd-devel] What condition(s) do .device units wait for?
I'm trying to understand what a system is timing out waiting for a device in /etc/fstab when a simple "mount -av" will succeed. To reach systemd, initramfs has already mounted the device as the base layer to an overlay mount used as the root file system, so it's definitely ready to use in the Linux kernel. In /etc/fstab, fsck is set to 0. What condition does systemd wait for that could be timing out on a device that's already mounted?
Re: [systemd-devel] How can I prevent systemd.network from auto-deleting my manually-assigned static IPv4 addresses?
Ian Pilcher https://mailto:arequip...@gmail.com>> wrote: > Why are you running systemd-networkd at all? That’s a really good question — the decision wasn’t made by me. I think the people in charge of updating the device’s Linux distribution were just thinking along general principles that systemd is the way things are done now, and networkd is part of systemd, so. In any case, I resolved the conflict by updating my code to write out config files into /run/systemd/network (and then restarting networkd) instead of modifying the Linux state directly. That way my code is working with networkd rather than fighting with it, and it seems to be working well. Jeremy NOTICE: This email may contain confidential information. Please see https://meyersound.com/legal/#email-policy for our complete policy.
Re: [systemd-devel] Fedora 38 and signed PCR binding
Will appreciate any pointers about debugging and fixing this! On Tue, Sep 12, 2023 at 2:55 AM Aleksandar Kostadinov wrote: > > 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)
