[systemd-devel] machined container console?
Hi, nspawn containers in machined wire /dev/console to the journal. That means systemd starts a getty on /dev/console that cannot be used. Also, uninitialized images start systemd-firstboot on /dev/console which doesn't make much sense either :-) Are there any plans to make it possible to attach to the console of a container by means of machinectl? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Ivo Totev HRB 36809 (AG Nürnberg)
Re: [systemd-devel] the need for a discoverable sub-volumes specification
Chris Murphy wrote: > On Tue, Nov 9, 2021 at 8:48 AM Ludwig Nussel wrote: >> Lennart Poettering wrote: >>> Or to say this explicitly: we could define the spec to say that if >>> we encounter: >>> >>>/@auto/root-x86-64:fedora_36.0+3-0 >>> >>> on first boot attempt we'd rename it: >>> >>>/@auto/root-x86-64:fedora_36.0+2-1 >>> >>> and so on. Until boot succeeds in which case we'd rename it: >>> >>>/@auto/root-x86-64:fedora_36.0 >>> >>> i.e. we'd drop the counting suffix. >> >> Thanks for the explanation and pointer! >> >> Need to think aloud a bit :-) >> >> That method basically works for systems with read-only root. Ie where >> the next OS to boot is in a separate snapshot, eg MicroOS. >> A traditional system with rw / on btrfs would stay on the same subvolume >> though. Ie the "root-x86-64:fedora_36.0" volume in the example. In >> openSUSE package installation automatically leads to ro snapshot >> creation. In order to fit in I suppose those could then be named eg. >> "root-x86-64:fedora_36.N+0" with increasing N. Due to the +0 the >> subvolume would never be booted. > > Yeah the N+0 subvolumes could be read-only snapshots, their purpose is > only to be used as an immutable checkpoint from which to produce > derivatives, read-write subvolumes. But what about the case of being > in a preboot environment, and have no way (yet) to rename or create a > new snapshot to boot, and you need to boot one of these read-only > snapshots? What if the bootloader was smart enough to add the proper > volatile overlay arrangement anytime an N+0 subvolume is chosen for > boot? Is that plausible and useful? The initrd would have to make those arrangements. AFAICT so far openSUSE systems just boot into such a RO environment without any preparations. So fully read-only, just enough to run snapper to create a usable snapshot again. >> Anyway, let's assume the ro case and both efi partition and btrfs volume >> use this scheme. That means each time some packages are updated we get a >> new subvolume. After reboot the initrd in the efi partition would try to >> boot that new subvolume. If it reaches systemd-bless-boot.service the >> new subvolume becomes the default for the future. >> >> So far so good. What if I discover later that something went wrong >> though? Some convenience tooling to mark the current version bad again >> would be needed. >> >> But then having Tumbleweed in mind it needs some capability to boot any >> old snapshot anyway. I guess the solution here would be to just always >> generate a bootloader entry, independent of whether a kernel was >> included in an update. Each entry would then have to specify kernel, >> initrd and the root subvolume to use. > > The part I'm having a hard time separating is the implicit case (use > some logic to assemble the correct objects), versus explicit (the > bootloader snippet points to a root and the root contains an fstab - > nothing about assembly is assumed). And should both paradigms exist > concurrently in an installed system, and how to deconflict? Not sure there is a conflict. The discovery logic is well defined after all. Also I assume normal operation wouldn't mix the two. Package management or whatever installs updates would automatically do the right thing suitable for the system at hand. > Further, (open)SUSE tends to define the root to boot via `btrfs > subvolume set-default` which is information in the file system itself, > neither in the bootloader snipper nor in the naming convention. It's > neat, but also not discoverable. If users are trying to The way btrfs is used in openSUSE is based on systems from ten years ago. A lot has changed since then. Now with the idea to have /usr on a separate read-only subvolume the current model doesn't really work very well anymore IMO. So I think there's a window of opportunity to change the way openSUSE does things :-) cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Ivo Totev HRB 36809 (AG Nürnberg)
[systemd-devel] throw routes are getting removed when networkd is restarted
Hi, I'm running on Debian Bullseye, systemd 247. StrongSwan 5.9.1 (an IPsec implementation) establishes throw routes in table 220 when activating the bypass-lan plugin. Basically that means: you have a VPN tunnel giving you a prioritized default route through the VPN gateway but you can still reach systems in local networks. It looks like this: # ip a ... 2: ens18: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 ... inet 192.168.1.160/24 brd 192.168.1.255 scope global dynamic ens18 inet 172.29.254.11/32 scope global ens18 3: ens19: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 ... inet 192.168.180.2/24 brd 192.168.180.255 scope global ens19 4: vmbr1: mtu 1500 qdisc noqueue state UP group default qlen 1000 inet 10.10.10.1/24 brd 10.10.10.255 scope global vmbr1 ... # ip rule 0: from all lookup local 220:from all lookup 220 32766: from all lookup main 32767: from all lookup default # ip route sh table 220 default via 192.168.1.1 dev ens18 proto static src 172.29.254.11 throw 10.10.10.0/24 proto static throw 192.168.1.0/24 proto static throw 192.168.180.0/24 proto static Any outgoing traffic goes through table 220 where the default route points to the VPN tunnel. Without the throw routes traffic for local networks would be sent through the VPN tunnel too. Now the problem: when I restart networkd, the throw routes get removed: # systemctl restart systemd-networkd # ip route sh table 220 default via 192.168.1.1 dev ens18 proto static src 172.29.254.11 Of course now I can no longer reach the local networks. I run networkd with "Environment=SYSTEMD_LOG_LEVEL=debug", so I get this in the log: # grep throw /var/log/syslog | cut -d " " -f 6- | grep -v lo: \ | sed 's!src: n/a, gw: n/a, prefsrc: n/a, scope: global, !!' Remembering route: dst: 192.168.180.0/24, table: 220, proto: static, type: throw Remembering route: dst: 192.168.1.0/24, table: 220, proto: static, type: throw Remembering route: dst: 10.10.10.0/24, table: 220, proto: static, type: throw Removing route: dst: 192.168.180.0/24, table: 220, proto: static, type: throw Removing route: dst: 10.10.10.0/24, table: 220, proto: static, type: throw Removing route: dst: 192.168.1.0/24, table: 220, proto: static, type: throw Removing route: dst: 192.168.180.0/24, table: 220, proto: static, type: throw Removing route: dst: 10.10.10.0/24, table: 220, proto: static, type: throw Removing route: dst: 192.168.1.0/24, table: 220, proto: static, type: throw Removing route: dst: 192.168.180.0/24, table: 220, proto: static, type: throw Removing route: dst: 10.10.10.0/24, table: 220, proto: static, type: throw Removing route: dst: 192.168.1.0/24, table: 220, proto: static, type: throw Forgetting route: dst: 192.168.180.0/24, table: 220, proto: static, type: throw Forgetting route: dst: 10.10.10.0/24, table: 220, proto: static, type: throw Forgetting route: dst: 192.168.1.0/24, table: 220, proto: static, type: throw At first, networkd remembers the throw routes, then it removes and forgets them. Why is that and how can I prevent it from doing so? (Actually, the problem is a bit more complex and has to do with disappearing throw routes when interfaces come up "late", i.e. WIFI interfaces. I tried to show the behavior in a simple test case.) Regards, Robert
