Re: [systemd-devel] sysext verity+signed with EFI FW keys
> The kernel needs to be built with some non-default kconfigs, so if > it's a custom build or distro check that those are all enabled, they > are listed here: > > https://github.com/systemd/systemd/blob/main/README#L131 Just for posterity, here is the permalink: https://github.com/systemd/systemd/blob/60a20eff8007105c4a09ab34ebe318d5970e629a/README#L131
Re: [systemd-devel] confusion with systemd-repart
> Am I supposed to create file for PrimaryRootfs also, even > if it does already exist, so that repart understand SecondaryRootfs has > to be created? What, exactly, am I doing incorrectly, because I'm sure > it is me not using the tool properly here, and no actual bug... Yes, repartd tries to match your definitions with existing partitions first. The intended solution is to create simple files which match the existing partitions. From the man page of repart.d: > Partition files are generally matched against any partitions already existing > on disk [...]. Any left-over partition files that have no matching existing > partition are assumed to define new partition that shall be created.
Re: [systemd-devel] repart.d: Root partition not grown
This was not properly implemented until the current version: https://github.com/systemd/systemd/pull/30030 On Sun, May 5, 2024 at 10:15 PM Paul Menzel wrote: > > Dear systemd folks, > > > On Ubuntu 22.04 with *systemd-repart* 249.11-0ubuntu3.12, the root > partition in a qcow2 image, resized with > > qemu-img resize ubuntu-jammy.qcow2 +100G > > is not grown: > > $ lsblk > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS > sr0 11:01 1024M 0 rom > vda254:00 101.5G 0 disk > |-vda1 254:10 512M 0 part > |-vda2 254:20 1M 0 part > `-vda3 254:30 989.1M 0 part / > > $ more /etc/repart.d/*.conf > :: > /etc/repart.d/00-esp.conf > :: > [Partition] > Type=esp > Format=vfat > CopyFiles=/boot:/ > CopyFiles=/efi:/ > SizeMinBytes=512M > SizeMaxBytes=512M > :: > /etc/repart.d/05-bios.conf > :: > [Partition] > # UUID of the grub BIOS boot partition which grubs needs on GPT to > # embed itself into. > Type=21686148-6449-6e6f-744e-656564454649 > SizeMinBytes=1M > SizeMaxBytes=1M > :: > /etc/repart.d/10-root.conf > :: > [Partition] > Type=root > Format=ext4 > CopyFiles=/ > Minimize=guess > > $ sudo systemd-repart > /etc/repart.d/10-root.conf:5: Unknown key name 'Minimize' in > section 'Partition', ignoring. > TYPE LABEL UUID >FILE NODE SIZE PADDING > esp esp > 8c1fa117-5470-40fb-ae88-706406a7e115 00-esp.conf /dev/vda1 512.0M 0B > 21686148-6449-6e6f-744e-656564454649 linux > 13d7f959-ea58-4560-9a51-956603dccdbd 05-bios.conf /dev/vda2 1.0M 0B > root-x86-64 root-x86-64 > 9e46548d-16e7-4b79-aa05-bf9d8e4bff48 10-root.conf /dev/vda3 989.0M 0B > > Σ = 1.4G Σ = 0B > > > ▓ > ├─ 10-root.conf > ├─ 05-bios.conf > └─ 00-esp.conf > > No changes. > > Reading the manual I’d assume, that type *root* would automatically be > grown. Before creating an issue, can you see, if something is wrong with > the configuration files? > > > Kind regards, > > Paul
Re: [systemd-devel] repart: How to use CopyBocks= with usr-verity?
Hi Daan, accepting more verity arguments might help but I am not even sure what one would specify there. The recreation of the verity partition was also only something I tried as a workaround which would not be necessary if CopyBlocks= could correctly pick up the existing verity partition. I have now created an issue for this and linked reproducer: https://github.com/systemd/systemd/issues/32029 Best regards, Nils On Sun, Mar 31, 2024 at 12:30 PM Daan De Meyer wrote: > > Hi Nils, > > Pretty sure nobody ever tried this. The root hash might be changing > because we format the verity hash partition with different parameters > than it was originally formatted with in your case. I assume the > roothash will only stay the same if the verity format arguments are > exactly the same. We'd probably accept PRs to allow configuring more > verity arguments to support this use case. > > Cheers, > > Daan > > On Fri, 29 Mar 2024 at 19:55, Nils Kattenbeck wrote: > > > > Hello everyone, > > > > I am having trouble with getting CopyBlocks= to work with a verify enabled > > usr partition. The documentations says that it should automatically work > > automatically but it does not describe which properties have to be set for > > which partition, i.e. repart.d file. > > So far I have tried several variations of Verity=/VerityMatchKey=, settings > > it only on one partition, both etc., setting CopyBlocks= on only usr or usr > > and usr-verity. Setting CopyBlocks= on both does not work and > > systemd-repart fails with the message that it was unable to find the > > correct partition for usr-verity. The other approach was setting > > CopyBlocks= only on the usr partition but regardless of what I try with > > Verity= the root hash changes (and thus also the partition UUIDs). Or more > > specifically the usr partition retains the correct/original PARTUUID > > whereas the PARTUUID of the usr-verity partition changes. > > > > Maybe someone has an idea what might cause this or better yet already has a > > similar working solution which they could share. > > > > Kind regards, > > Nils > >
[systemd-devel] repart: How to use CopyBocks= with usr-verity?
Hello everyone, I am having trouble with getting CopyBlocks= to work with a verify enabled usr partition. The documentations says that it should automatically work automatically but it does not describe which properties have to be set for which partition, i.e. repart.d file. So far I have tried several variations of Verity=/VerityMatchKey=, settings it only on one partition, both etc., setting CopyBlocks= on only usr or usr and usr-verity. Setting CopyBlocks= on both does not work and systemd-repart fails with the message that it was unable to find the correct partition for usr-verity. The other approach was setting CopyBlocks= only on the usr partition but regardless of what I try with Verity= the root hash changes (and thus also the partition UUIDs). Or more specifically the usr partition retains the correct/original PARTUUID whereas the PARTUUID of the usr-verity partition changes. Maybe someone has an idea what might cause this or better yet already has a similar working solution which they could share. Kind regards, Nils
Re: [systemd-devel] systemctl inaccessible when enabling DynamicUser=true
On Fri, Mar 29, 2024 at 7:04 AM Mantas Mikulėnas wrote: > > It's probably a difference between dbus-daemon and dbus-broker, I suspect. Hi, that was indeed the problem. Installing dbus-broker on one of the machines did in fact fix this. Any idea why that might be? I do not know the differences between the two so I am not completely comfortable with replacing dbus-daemon with dbus-broker just to fix this small issue. This issue at least confirms to me that they are not drop-in compatible. Kind regards, Nils
Re: [systemd-devel] systemctl inaccessible when enabling DynamicUser=true
On Thu, Mar 28, 2024 at 3:08 PM Luca Boccassi wrote: > > Works just fine here in Debian with 252: Hm, weird. With logging enabled I get the following output: $ sudo systemd-run -t --collect -p DynamicUser=true -E SYSTEMD_LOG_LEVEL=debug systemctl --failed Running as unit: run-u1497.service Press ^] three times within 1s to disconnect TTY. Cannot stat /proc/1/root: Permission denied running_in_chroot(): Permission denied Bus n/a: changing state UNSET → OPENING sd-bus: starting bus by connecting to /run/dbus/system_bus_socket... Bus n/a: changing state OPENING → AUTHENTICATING Successfully forked off '(pager)' as PID 386098. Skipping PR_SET_MM, as we don't have privileges. sd_pid_get_owner_uid() failed, enabling pager secure mode: No data available Pager executable is "less", options "FRSXMK", quit_on_interrupt: yes Bus n/a: changing state AUTHENTICATING → HELLO Bus n/a: changing state HELLO → CLOSING Failed to list units: Transport endpoint is not connected Bus n/a: changing state CLOSING → CLOSED $ systemd 252 (252.22-1~deb12u1) +PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified I can also can reproduce this on another machine running Ubuntu 22.04 LTS with the systemd 249 (249.11-0ubuntu3.12). On my laptop (Fedora 40) I cannot reproduce the error and it works like in your case. The other two machines are servers.
[systemd-devel] systemctl inaccessible when enabling DynamicUser=true
Hello, I am writing a simple oneshot service which should read access from the journal and systemctl status. To restrict the service I was trying to enable DynamicUser (and added ' SupplementaryGroups=systemd-journal'). However, the service is unable to access unit status information and errors with the message: "Failed to get properties: Transport endpoint is not connected". The error message is not really helpful what exactly this transport endpoint is. What parts of sandboxing do I have to disable again to get this working? This is systemd 252 on Debian. Kind regards, Nils
Re: [systemd-devel] Customize configuration at compile-time vs /usr/lib/systemd/*/*.conf.d
Hi, I am not sure if setting the compile time defaults is possible but in general distributions should ship their configuration in /usr/... and end users should make their adjustments in /etc/... On Tue, Mar 5, 2024, 12:30 Max Gautier wrote: > Hi, > > journald.conf (as well as other components) in the systemd source tree > has the following mention (emphasis mine): > > # **Entries in this file show the compile time defaults**. Local > configuration > # should be created by either modifying this file (or a copy of it placed > in > # /etc/ if the original file is shipped in /usr/), or by creating > "drop-ins" in > # the /etc/systemd/journald.conf.d/ directory. The latter is generally > # recommended. Defaults can be restored by simply deleting the main > # configuration file and all drop-ins located in /etc/. > > However, I cannot find a knob to use to change that default > configuration in meson_options or by looking through src/journal and > grepping. > Should distributions simply use drop-ins in > /usr/lib/systemd/journald.conf.d/ ? (for journald). It's not that it's > hard, but the wording seems to imply that "primary" distributors (aka > the one compiling systemd) should defined compile-time defaults, and > /usr/lib/systemd/*.conf.d should be for overriding that. > > Am I missing documentation somewhere ? > > Thanks > > -- > Max Gautier >
Re: [systemd-devel] logind: Activating session/opening seat fails in systemd v254
On Fri, Feb 16, 2024 at 9:45 AM Lennart Poettering wrote: > > On Do, 15.02.24 22:16, Nils Kattenbeck (nilskem...@gmail.com) wrote: > > > Hi everyone, > > > > I am working on a kiosk-type device which is supposed to start a > > weston instance upon boot. > > Our images were previously based on Debian 12 and Fedora 38, now we > > are working on unifying them. Between the two old image variants the > > systemd units were mostly identical, however, on Fedora 39 with > > systemd 254 they no longer work. Weston/libseat now fails with the > > message: "Could not activate session: Permission denied". (Also see > > the logind logs at the end). > > Neither Weston nor libseat (whatever that is) are a systemd > thing. Please contact the relevant projects for help? I was asking this mailing list because it is not completely unheard of that systemd changes (or deprecates and subsequently removes) some aspects of how environments etc are set up sometimes. However, since the initial mail I have been able to try out different combinations of systemd and weston and could pinpoint this to a change in weston, which no longer uses logind directly but instead uses libseat as an abstraction. > libseat (whatever that is) Libseat is a library to allow using (e)logind and seatd with a common interface: https://github.com/kennylevinsen/seatd/blob/master/libseat/backend/logind.c Sadly it seems unable to properly activate the session according to my logs. (Previous weston versions also supported directly using logind but they removed it in newer versions.) Kind regards, Nils
[systemd-devel] logind: Activating session/opening seat fails in systemd v254
Hi everyone, I am working on a kiosk-type device which is supposed to start a weston instance upon boot. Our images were previously based on Debian 12 and Fedora 38, now we are working on unifying them. Between the two old image variants the systemd units were mostly identical, however, on Fedora 39 with systemd 254 they no longer work. Weston/libseat now fails with the message: "Could not activate session: Permission denied". (Also see the logind logs at the end). I have been looking through the NEWS file and release announcement to see if I could spot any change which could have this impact but nothing stood out. Maybe someone else has a clue and remembers any recent change. This must have been a change between v253 and v254 as Fedora 38 is using the former and f39 is using the latter. Any help would be appreciated as I have worked on this for a few days now without success. (I can also try to create a MWE and publish the repo. It is build using mkosi so reproducing should be easy.) Kind regards, Nils
Re: [systemd-devel] Bump: Testing LogFilterPatterns= on user-level services
> > Interepreting arbitrary regexes configured by unpriv code in priv code > > comes at some risk,. becose afair constructing them can come at O(2^n) > > time, i.e. a rogue regex could make use consume unbounded time on > > processing journal messages. > > Which regex engine is used? glibc’s engine is not safe for use with > untrusted input, but Rust’s is, so that might be an option in the > future. It isn’t OOM-safe, though. Rust isn't used. To my knowledge libpcre2 is used (at least it was at the time the feature landed). That library does not seem to allow setting any restrictions which would make it possible to parse untrusted input. For how exactly this works for rust see the documentation of the crate: https://docs.rs/regex/latest/regex/index.html#untrusted-input So in theory it is certainly possible to allow a regex subset though I am not aware of any C library which does this. A simple workaround we have done in a project I work on is to restrict the set of allowed characters. Doing it that way however puts more restrictions in place than theoretically possible. For the foreseeable future I agree with Lennart that documenting this quirk should be the most important thing. Afterwards this could be made configurable somehow, as well as showing a message or exiting with a non-zero code to indicate that this is not allowed.
Re: [systemd-devel] Bump: Testing LogFilterPatterns= on user-level services
> Interepreting arbitrary regexes configured by unpriv code in priv code > comes at some risk,. becose afair constructing them can come at O(2^n) > time, i.e. a rogue regex could make use consume unbounded time on > processing journal messages. > > Hence, I wouldn't hold your breath. Unless someone figures out a smart > way to deal with this it's unlikely to be supported. I am not sure about construction but checking for matches with arbitrary regexes can definitely result in DOS. Restricting the allowed features, however, alleviates this problem. E.g. the rust regex crate can check in O(m*n) with m = Regex Size and n = Input size. It does this by now allowing (amongst other things) no look-arounds or backrefs. I am not sure how configurable pcre2pattern is but maybe the supported features could be restricted for regexes from users. Nils
Re: [systemd-devel] Permanently remove services
> > They are turning up as failed units, so they are being run, > > even if I don't have any TPM module. Also, I have a notifier in > > my waybar telling me of failed services and I don't want to see > > them there. > > Can you provide logs about this? The goal is definitely to make these > NOPs on TPM-less systems. I am a bit puzzled that the conditioning > they come with is not sufficient. We might need to tweak something > there then. > > The idea is that the system does TPM setup on systems that have a tpm > and on systems lacking that silently just skips all these so that > everything always works fully automatically and robustly without any > ugly error output. > > hence, any chance you can provide logs about this? and what kind of > system is this? i.e. does it really lack a tpm? In the past I have seen errors on systems which do not have libtss2/tpm2-tss installed though I am not sure if those should be silenced. After all, the unit being enabled means that one wants to use it if possible - and if the libraries are missing that should be noticeable to the user instead of a silent fail. @Morten Which distribution are you using and do you have the above libraries installed (or whatever they are called in your distro)? Greetings, Nils
[systemd-devel] Differences between sd-nspawn and sd-run with RootImage/RootDirectory?
Hello, I have come across the issue for rootless sd-nspawn and - while formulating a comment thereunder - read a bit more in a few man pages (systemd and podman related). While doing so the question arose whether there are any technical, under the hood differences between nspawn and systemd.exec's `RootDirectory=/RootImage=` options. It seems like they would provide the same functionality. Can `systemd-spawn` or `systemd-run --property=...` achieve something the other one is not capable of doing? Are they maybe even using the same logic under the hood? I would greatly appreciate any information which might clarify the differences or lack thereof. Kind regards, Nils
Re: systemd-sysupdate support for slow rollout (aka A/B testing)
Hello, I have now created an issue in the systemd repository where this can be tracked further as this seems to be something which would fit into sd-sysupdate itself: https://github.com/systemd/systemd/issues/30855 Kind regards, Nils
Re: sysupdate: Limit update to at most one major version
Continuing in https://github.com/systemd/systemd/issues/30695 On Tue, Jan 2, 2024 at 2:06 PM Lennart Poettering wrote: > > On Di, 02.01.24 13:49, Nils Kattenbeck (nilskem...@gmail.com) wrote: > > > > I'd be fine with adding MaxVersion=. Happy to review a patch, merge > > > something like this (at least file an RFE issue) > > > > Should that be inclusive or exclusive? Naming it MaxVersion would > > imply it to be inclusive though an exclusive bound would likely be > > more useful most of the time. One could then specify MaxVersion=1.3.0 > > in their 1.2.x images and once they have an upgrade path they would > > explicitly raise the max version in e.g. 1.2.15. Otherwise they would > > have to specify 1.99.99. > > In retrospect a VersionBound= property with syntax similar to > > ConditionKernelVersion= would have been better though I guess that > > ship has sailed - or is it? Is sd-sysupdate still considered > > experimental? Not sure if this warrants such a change though :shrug: > > We do not allow "=" nor "<" in version strings, as per > https://uapi-group.org/specifications/specs/version_format_specification/. > > Hence we could use that fact and say: "MaxVersion= <=47.11", > "MaxVersion= <47.11" could be used to make the type of version > comparison explicit. This would implement a tiny subset of the > ConditionKernelVersion= logic, and simply default to imply <= if the > comparison is not specified explicitly. > > Of course, a similar logic should then be implemented for MinVersion, > i.e. >= and > > > > Should we continue this discussion on the mailing list or an issue? > > Issue is better. > > Lennart > > -- > Lennart Poettering, Berlin
Re: systemd-sysupdate support for slow rollout (aka A/B testing)
> > does sysupdate currently support any way to slowly roll out updates > > where the server providing the files can be in control? [...] > > This is currently not available, no. > > The idea so far was always that the server is dumb, and the client > picks the release it wants. I feel like it would be more flexible to have the client mostly handling transferring and applying the data and any additional logic should be handled by either the server or secondary applications which call into sysupdate (or its future dbus API). > I have thought about this usecase a while back, and my thinking was > that such a staged update logic should be driven by the machine > ID. i.e. we should teach sysupdate a simple logic that allows pattern > matching of new versions based on some arithmetic of the machine > ID. More specifically, include some value in the URL pattern that > indicates the percentage of hosts that shall update to this > release. Then, each client takes its machine ID, treats it as an > integer and calculates modulo 100 of it or so, and then checks if the > resulting value is below the intended percentage, and if so it > updates, otherwise it doesn't. > > (or something like that, the above is probably not ideal, since it > would mean it's always the same hosts that try a new release first, > and it probably should be evened out across the set of clients). Any logic based on the machine ID would also have the problem I mentioned below that the ratios would be skewed for stateless devices which cannot persist their machine id to disk. One would at least be able to override it with something persistent like a MAC address though this could be exposed as some argument or environment variable which a secondary application could set before calling sysupdate. > This would then mean for the server that it would first serve > foobar_47.11_3.raw which would be version 47.11 of the OS, and 3% of > the hosts would update to it. And then, once you collected enough > feedback you'd rename the file to foobar_47.11_25.raw and 25% of the > hosts would switch over. Finally you'd set the value to 100 (or maybe > just drop it, which should be considered equivalent to 100), and then > all remaining hosts would update. > > The effect of this is that client's could still explicitly upgrade if > they want, and the updates would be entirely driven by the clients, > but simply via naming the download images the server can control that > "by default" only the chosen number of clients update. The explicit update by clients is definitely a nice bonus though this can also be achieved by a secondary set of definitions looking for files under s3.domain.com/rc/. > > Currently it seems like I would have to implement a different service > > which calls the sysupdate binary (or uses dbus once #28134 has landed) > > and then decides based on some other information. > > > > One idea I had would be that systemd-pull could send the machine-id > > based on which the server could then decide to provide the newer file > > (e.g. last two chars == "00" would roll it out to ~1/255). Though I am > > not sure if sd-pull is supposed to be "anonymous", i.e. do not provide > > this identifying information. Another drawback of this would be that > > stateless systems which reboot often get a new machine-id each boot, > > thus having an increased chance to get the newer version. > > So this idea is not entirely different from my idea, I was just > thinking about pushing this into sysupdate rather than pull. > > > Does anything like this already exist or is planned? Or should that be > > done by different applications on the client side? > > I think it makes a ton of sense to add this to sysupdate. Would love > to review/merge a patch for that. > > > I also remember there being a discussion about plugging in different > > sd-pull like implementations/backends[1] to support delta updates, > > other transports, or TLS client authentication. This could at least be > > adapted to support my idea to send the machine-id as an HTTP header > > (e.g. X-MACHINE-ID). > > If we can avoid it, I'd always adopt a logic whether identifying info > doesn't have to be sent to the server. After all the logic should be > generic and applicable in scenarios where the client should get > anonymity as much as it wants. If the client automatically applies updates the server could always deliver an image which exposes information by e.g. simply updating the Path= to include %m somewhere in it. Though I agree that always sending such information in headers would not be optimal. I also found out that sd-import drops query parameters from the URL. If this were not the case my use case would already be possible by embedding the machine ID as part of the query. This would also make it possible to opt in to sending the information. The problem I think is that there are two user groups of sysupdate with different requirements. On one hand we have end user distributions with A/B
Re: sysupdate: Limit update to at most one major version
> I'd be fine with adding MaxVersion=. Happy to review a patch, merge > something like this (at least file an RFE issue) Should that be inclusive or exclusive? Naming it MaxVersion would imply it to be inclusive though an exclusive bound would likely be more useful most of the time. One could then specify MaxVersion=1.3.0 in their 1.2.x images and once they have an upgrade path they would explicitly raise the max version in e.g. 1.2.15. Otherwise they would have to specify 1.99.99. In retrospect a VersionBound= property with syntax similar to ConditionKernelVersion= would have been better though I guess that ship has sailed - or is it? Is sd-sysupdate still considered experimental? Not sure if this warrants such a change though :shrug: Should we continue this discussion on the mailing list or an issue? Kind regards, Nils
Re: systemd-sysupdate support for slow rollout (aka A/B testing)
Hello and happy New Year, I tried to solve this by adding percent-specifiers as query parameters to the Path= property of the sysupdate definition though to my dismay I had to find out that they are discarded by the sd-import logic. Removing this restriction could solve this problem as one could easily send machine id, os version and similar information to the server. This would in general enable fine grained control over which updates a devices sees. Also see https://lists.freedesktop.org/archives/systemd-devel/2024-January/049889.html for a case where this is desirable. Kind regards, Nils On Wed, Dec 20, 2023, 19:04 Nils Kattenbeck wrote: > Hey everyone, > > does sysupdate currently support any way to slowly roll out updates > where the server providing the files can be in control? This would be > used to slowly make a new version available and have it at e.g. 1% > adoption for a day to monitor regressions before increasing the > coverage. I was unable to find any information about it in the > documentation. > > Currently it seems like I would have to implement a different service > which calls the sysupdate binary (or uses dbus once #28134 has landed) > and then decides based on some other information. > > One idea I had would be that systemd-pull could send the machine-id > based on which the server could then decide to provide the newer file > (e.g. last two chars == "00" would roll it out to ~1/255). Though I am > not sure if sd-pull is supposed to be "anonymous", i.e. do not provide > this identifying information. Another drawback of this would be that > stateless systems which reboot often get a new machine-id each boot, > thus having an increased chance to get the newer version. > > Does anything like this already exist or is planned? Or should that be > done by different applications on the client side? > I also remember there being a discussion about plugging in different > sd-pull like implementations/backends[1] to support delta updates, > other transports, or TLS client authentication. This could at least be > adapted to support my idea to send the machine-id as an HTTP header > (e.g. X-MACHINE-ID). > > Greetings, Nils > > [1] > https://lists.freedesktop.org/archives/systemd-devel/2023-February/048856.html >
Re: sysupdate: Limit update to at most one major version
Forwarding to mailing list for future reference. (Also I want to reference this mail in an upcoming mail). On Mon, Jan 1, 2024, 14:31 Nils Kattenbeck wrote: > Hi Adrian > > You can change the URL you check for updates to include the current >> version number, then upload each version to a separate directory. >> >> I.e. instead of putting all the versions in update.example.com/myos, >> you'd put v2 in u.e.c/m/v1 and you'd put v3 in u.e.c/m/v2 and so forth >> > > Brilliant, I did not think of that. > I guess this would fall down when implementing something more complex like > allowing to updating to the next two versions but this already suffices for > my purpose. (In that case it would be possible to serve the images under > multiple directory but that would be a bit ugly, especially when backing it > with something like S3 which does not support symlinks - and also is > disadvantageous for caching with CDNs.) > > Kind regards, Nils > >>
sysupdate: Limit update to at most one major version
Hello, we are currently using sd-sysupdate to roll out updates and we're wondering if there is any possibility to limit updates to consider at most one next major version. This would allow us to write the software to handle only data migrations from the previous major version instead of any version beforehand. The only thing I have been able to find is MinVersion= which seems to do exactly the opposite of what we would want to do. Kind regards, Nils
systemd-sysupdate support for slow rollout (aka A/B testing)
Hey everyone, does sysupdate currently support any way to slowly roll out updates where the server providing the files can be in control? This would be used to slowly make a new version available and have it at e.g. 1% adoption for a day to monitor regressions before increasing the coverage. I was unable to find any information about it in the documentation. Currently it seems like I would have to implement a different service which calls the sysupdate binary (or uses dbus once #28134 has landed) and then decides based on some other information. One idea I had would be that systemd-pull could send the machine-id based on which the server could then decide to provide the newer file (e.g. last two chars == "00" would roll it out to ~1/255). Though I am not sure if sd-pull is supposed to be "anonymous", i.e. do not provide this identifying information. Another drawback of this would be that stateless systems which reboot often get a new machine-id each boot, thus having an increased chance to get the newer version. Does anything like this already exist or is planned? Or should that be done by different applications on the client side? I also remember there being a discussion about plugging in different sd-pull like implementations/backends[1] to support delta updates, other transports, or TLS client authentication. This could at least be adapted to support my idea to send the machine-id as an HTTP header (e.g. X-MACHINE-ID). Greetings, Nils [1] https://lists.freedesktop.org/archives/systemd-devel/2023-February/048856.html
Re: [RFC] initoverlayfs - a scalable initial filesystem
On Wed, Dec 13, 2023 at 10:03 AM Lennart Poettering wrote: > > On Di, 12.12.23 23:01, Nils Kattenbeck (nilskem...@gmail.com) wrote: > > > > sysexts are erofs or squashfs file systems with verity backing. Only > > > the sectors you access are decompressed. > > > > Okay I forgot that they were erofs based and mentioned cpio archives > > so I assumed they would be one. > > Do they need to be fully read from disk to generate the cpio archive? > > erofs is a file system, cpio is a serialized archive. Two different > things. The discussion here is whether to pass the initrd to the > kernel as one or the other. But noone is suggesting to convert one to > the other at boot time. I was referring to the following line from sd-stub's man page: "The following resources are passed as initrd cpio archives to the booted kernel: [...] /.extra/sysext/*.raw [...]". I assume the initrd containing the sysexts has to be created at some point?
Re: [RFC] initoverlayfs - a scalable initial filesystem
On Tue, Dec 12, 2023 at 10:02 PM Lennart Poettering wrote: > > If you have 7 cpio initrds then the kernel will allocate a tmpfs and > unpack them all into it, one after the other, on top of each other, > and then jumps into the result. > > if you have an erofs and 7 cpio initds, what are you going to do? You > cannot extract into an erofs, it's immutable. You'd need something > like overlayfs, but that would require (at least for now) an > additional step in userspace, which is something to avoid. > > Alternatively (and preferred by me) would support a mode where it > would unpack any cpios it gets into a tmpfs, and then pass an fsopen() > fd to that to the executable it then invokes from the erofs. the > executable could then mount that somewhere if it wants. But this would > require a kenrel patch. Such a kernel patch would likely be the more advanced method. I also saw that they now wrote to the LKML to potentially discuss something like this. The method with an overlaysfs would likely be easier for init systems to use but also less customizable. > > Even if everything is the same there are codes paths which might not > > be taken during usual operation. An example would be services similar > > to the new systemd-bsod which are only triggered in emergencies. > > Having these in the cpio means that they will always be read and > > decompressed. > > systemd-bsod is tiny though, less than 8K compressed here. Not sure it > is a good example. Yes that is right though it is the first and most universal thing which came to mind. A better example would be something like a fleet management SDK (in Java or a similar language with a runtime) which phones to a management server indicating a boot failure and publishing crash logs. > > Using sysexts also has the drawback that each and every one of them > > has to be decompressed. I might be mistaken but I expect that this > > will be the case even if the extension-release in the sysext results > > in it being discarded which is obviously another big drawback. > > sysexts are erofs or squashfs file systems with verity backing. Only > the sectors you access are decompressed. Okay I forgot that they were erofs based and mentioned cpio archives so I assumed they would be one. Do they need to be fully read from disk to generate the cpio archive? > Lennart > > -- > Lennart Poettering, Berlin
Re: [RFC] initoverlayfs - a scalable initial filesystem
Hi, while I have been following this thread passively for now I also wanted to chime in. > (The main reason why sd-stub doesn't actually support erofs-initrds, > is that sd-stub also generates initrd cpios on the fly, to pass > credentials and system extension images to the kernel, and you can't > really mix erofs and cpio initrds into one) What prevents one from mixing the two (especially given that the hypothetical erofs initrd support does not yet exist)? Or are you talking about mixing this with your memmap+root=/dev/pmem suggestion? > The try to optimize the initrd a bit by making it an erofs/memmap > thing and so on. And make sure the initrd only contains stuff you > always need, so that reading it all into memory is necessary anyway, > and hence any approach that tries to run even the initrd off a disk > image won't be necessary becuase you need to read everything anyway. Having to ensure that the initrd is as small as possible is definitely no easy task. Furthermore unless one has total control over the devices, or even if there are only a few hardware revisions, parts of the initrd might not be used. Even if everything is the same there are codes paths which might not be taken during usual operation. An example would be services similar to the new systemd-bsod which are only triggered in emergencies. Having these in the cpio means that they will always be read and decompressed. Using sysexts also has the drawback that each and every one of them has to be decompressed. I might be mistaken but I expect that this will be the case even if the extension-release in the sysext results in it being discarded which is obviously another big drawback. Regardless, even if every single file within the cpio archive (and potential sysexts) is used, erofs still has a distinct advantage over cpio! With cpio everything has to be decompressed and read up front. With erofs this is not the case. Only the fs header has to be read at first as files are decompressed on demand. This means that critical stuff can be started earlier as it does not have to wait for decompression of stuff only needed later on. For example an initrd-only (i.e. not pivolint root), graphical system could start all background services long before the UI starts and accesses large asset files. I agree that this splitting up into another micro-initrd just for some storage stuff etc (which I still have not groked completely) does not seem to offer any advantages to what we have today. *However*, I certainly think that standardizing and supporting some kind of erofs based initrd would gain some advantages. On the other hand this feels like going back to an old ramdisk again. This goes beyond my knowledge but based on the kernel docs most drawbacks of ramdisks would not apply to an approach with erofs. Also maybe the more flexible loopback devices could be used(?) which might alleviate some problems. -- This block device was of fixed size, so the filesystem mounted on it was of fixed size. -> Should not be of concern as it is readonly anyhow. -- Using a ram disk also required unnecessarily copying memory from the fake block device into the page cache (and copying changes back out), as well as creating and destroying dentries. -> (?) This one I am actually not too sure about and supersedes my knowledge on tmpfs, vfs (and its cache layers), erofs caching, and loopback devices). -- Plus it needed a filesystem driver (such as ext2) to format and interpret this data. -> erofs is already included in most initrds (and is not too big if it is not) Regards, Nils
Re: [systemd-devel] Run preset-all of user units on first boot?
I decided to create a bug for this: https://github.com/systemd/systemd/issues/30206 On Mon, Nov 20, 2023 at 1:39 AM Nils Kattenbeck wrote: > > Hello, > I know that preset-all is run by the manager at startup if it is the > first boot. However, this does not seem to be run for user units (i.e. > systemctl --global preset-all). > Based on my findings the presetting is run very early and hooking in a > new service file with WantedBy/Before does not seem possible (and > would also require a daemon-reload). > Is there any other method of how to preset these files at boot? Is > this not done on purpose or has the need for this never come up? > > Thanks for the help. > Greetings, Nils
Re: [systemd-devel] Which archive formats are supported by systemd-sysupdate?
On Tue, Nov 21, 2023 at 6:04 PM Adrian Vovk wrote: > > Hello, > > I think relevant code for sysupdate / systemd-pull is here: > https://github.com/systemd/systemd/blob/main/src/import/import-compress.c Ah I was unaware that systemd-pull does indeed seem to decompress file streams. Thanks for the hint. > Relevant code for the rest of systemd is here: > https://github.com/systemd/systemd/blob/main/src/basic/compress.c > > Not sure why they are different and have different algorithms... That's a > question for whoever wrote systemd-importd, probably Yeah that is a bit weird. My first guess might have been different licenses (GPL vs LGPL) but that does not seem to be the case. I created #30126 suggesting to bring these in sync or at least have the algos match. Previously we thought about using ZSTD but we will stick with XZ for now. Thanks for your help. Greetings, Nils
[systemd-devel] Which archive formats are supported by systemd-sysupdate?
G'day, I was looking into using sysupdate but did not find any information about which archive formats are supported for "url-file". The man page simply states that files are decompressed without specifying it any further and uses .xz files in the examples. Are other formats like .zstd also supported? Is there a list somewhere which I can look at? I skimmed the source code but did not find anything at a first glance (apart from systemd-pull which does not seem to perform decompression). Greetings, Nils
[systemd-devel] Run preset-all of user units on first boot?
Hello, I know that preset-all is run by the manager at startup if it is the first boot. However, this does not seem to be run for user units (i.e. systemctl --global preset-all). Based on my findings the presetting is run very early and hooking in a new service file with WantedBy/Before does not seem possible (and would also require a daemon-reload). Is there any other method of how to preset these files at boot? Is this not done on purpose or has the need for this never come up? Thanks for the help. Greetings, Nils
Re: [systemd-devel] How to use systemd-growfs* services with GPT automount
On Sat, Oct 28, 2023 at 5:40 PM Nils Kattenbeck wrote: > > On Wed, Oct 25, 2023, 13:29 Nils Kattenbeck wrote: >> >> Hi Lennart, >> >> thanks for the information. I finally found out the true cause, >> however, and it's just stupidity on my part. >> While Debian (my mkosi base) does ship systemd-growfs and the man >> pages for all the services, it does not ship the services themselves. >> So I guess that the auto-grow functionality can never be activated. > > > Even after switching to Fedora (and adding two to the cmdline) the growfs > functionality still does not work. The images are simply generated with > mkosi. Is there any part which I might be missing? > > Are there any mechanisms to debug this mechanism? Maybe something with the > generator files? I can also create a minimal example and provide you with the > image, or mkosi files, whichever you prefer if that would help. I had a look into the source of gpt-auto-generator. In add_root_mount the add_mount function is called with growfs set to false without considering any flags/options. This seems to negate the whole purpose of using the growfs flag in the first place?! Kind regards, Nils
Re: [systemd-devel] How to use systemd-growfs* services with GPT automount
On Wed, Oct 25, 2023, 13:29 Nils Kattenbeck wrote: > Hi Lennart, > > thanks for the information. I finally found out the true cause, > however, and it's just stupidity on my part. > While Debian (my mkosi base) does ship systemd-growfs and the man > pages for all the services, it does not ship the services themselves. > So I guess that the auto-grow functionality can never be activated. > Even after switching to Fedora (and adding two to the cmdline) the growfs functionality still does not work. The images are simply generated with mkosi. Is there any part which I might be missing? Are there any mechanisms to debug this mechanism? Maybe something with the generator files? I can also create a minimal example and provide you with the image, or mkosi files, whichever you prefer if that would help. Kind regards, Nils > >
Re: [systemd-devel] How to use systemd-growfs* services with GPT automount
> > ro/rw is a bit weird. Usually in our configuration model the settings > > on the kernel cmdline args take precedence over config in > > /etc/. But ro/rw is different for historical reasons: it only > > specifies the initial ro/rw state of the disks, expecting that > > /etc/fstab later changes things to the final setting. And if neither > > are specified we imply "ro". > > > > Hence, you have two choices: define an /etc/fstab (which of course is > > not what you want with gpt-auto) or just add "rw" to the kernel cmdline. > > > > Lennart I think this could be clarified on the man page for repart.d then. Currently it states: ReadOnly= defaults to on for Verity partition types, and off for all others. GrowFileSystem= defaults to on for all partition types that support it, except if the partition is marked read-only (and thus effectively, defaults to off for Verity partitions). Maybe something like "ReadOnly= defaults to the kernel default ..." (instead of implying that it default to off)
Re: [systemd-devel] How to use systemd-growfs* services with GPT automount
Hi Lennart, thanks for the information. I finally found out the true cause, however, and it's just stupidity on my part. While Debian (my mkosi base) does ship systemd-growfs and the man pages for all the services, it does not ship the services themselves. So I guess that the auto-grow functionality can never be activated. Do you happen to know if it just starts to work magically if I add those service files to the filesystem on my own? Or is this something which can be compiled out? King regards, Nils On Wed, Oct 25, 2023 at 9:57 AM Lennart Poettering wrote: > > On Di, 24.10.23 23:48, Nils Kattenbeck (nilskem...@gmail.com) wrote: > > > > On Mo, 23.10.23 02:00, Nils Kattenbeck (nilskem...@gmail.com) wrote: > > > > > > > Hello, > > > > > > > > I am not sure how to get systemd-growfs-root.service to work with > > > > automount. The partitions are configured via systemd-repart (and the > > > > image created using mkosi). While the partitions are correctly grown > > > > upon boot, the contained filesystem is not grown to match the > > > > partition even though GrowFileSystem defaults to true. Is there > > > > anything I am missing or an easy way to troubleshoot this and get more > > > > information? > > > > > > > > One thing I notice is that the generator.late/-.mount unit has a > > > > Options=ro which as per documentation prevents growing the filesystem. > > > > However, the filesystem is actually mounted read-write so I assume > > > > this is just an artifact of the initrd. Is it not possible to grow the > > > > filesystem from which the initrd starts? > > > > > > Do you have "ro" or "rw" on the kernel cmdline? > > > > I have neither set on the cmdline. > > if you add it, does it work? > > ro/rw is a bit weird. Usually in our configuration model the settings > on the kernel cmdline args take precedence over config in > /etc/. But ro/rw is different for historical reasons: it only > specifies the initial ro/rw state of the disks, expecting that > /etc/fstab later changes things to the final setting. And if neither > are specified we imply "ro". > > Hence, you have two choices: define an /etc/fstab (which of course is > not what you want with gpt-auto) or just add "rw" to the kernel cmdline. > > Lennart > > -- > Lennart Poettering, Berlin
Re: [systemd-devel] How to use systemd-growfs* services with GPT automount
Hi, On Tue, Oct 24, 2023 at 1:33 PM Lennart Poettering wrote: > > On Mo, 23.10.23 02:00, Nils Kattenbeck (nilskem...@gmail.com) wrote: > > > Hello, > > > > I am not sure how to get systemd-growfs-root.service to work with > > automount. The partitions are configured via systemd-repart (and the > > image created using mkosi). While the partitions are correctly grown > > upon boot, the contained filesystem is not grown to match the > > partition even though GrowFileSystem defaults to true. Is there > > anything I am missing or an easy way to troubleshoot this and get more > > information? > > > > One thing I notice is that the generator.late/-.mount unit has a > > Options=ro which as per documentation prevents growing the filesystem. > > However, the filesystem is actually mounted read-write so I assume > > this is just an artifact of the initrd. Is it not possible to grow the > > filesystem from which the initrd starts? > > Do you have "ro" or "rw" on the kernel cmdline? I have neither set on the cmdline. Greetings, Nils
[systemd-devel] How to use systemd-growfs* services with GPT automount
Hello, I am not sure how to get systemd-growfs-root.service to work with automount. The partitions are configured via systemd-repart (and the image created using mkosi). While the partitions are correctly grown upon boot, the contained filesystem is not grown to match the partition even though GrowFileSystem defaults to true. Is there anything I am missing or an easy way to troubleshoot this and get more information? One thing I notice is that the generator.late/-.mount unit has a Options=ro which as per documentation prevents growing the filesystem. However, the filesystem is actually mounted read-write so I assume this is just an artifact of the initrd. Is it not possible to grow the filesystem from which the initrd starts? Kind regards, Nils
Re: [systemd-devel] Is systemd-cryptsetup binary internal?
> > > Why was the decision taken to put these into /usr/lib/systemd instead of > > /usr/libexec/systemd/? > > That's a Fedoraism. Why would one put something there? > > /usr/lib/ is where private arch-dependent package stuff goes. What's > the rationale for /usr/libexec/ though? > I am not aware of it being a Fedoraism. It is at least also used/populated on an Ubuntu server I use and documented as part of the filesystem hierarchy (hier(7)): https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html#ftn.idm236091914528 >
Re: [systemd-devel] Is systemd-cryptsetup binary internal?
Hi, /usr/lib/systemd/ is indeed the place for internal binaries with > unstable interfaces. But it's also the place where we put binaries > that we don't typically expect users to call, because they are > generally called via some well define .service unit or so only. > > systemd-cryptsetup is one of the latter, we'd expect people to use > this via crypttab mostly. However, the interface is nonetheless > stable, it is a long-time part of systemd and so far we never broke > interface and I see no reason we ever would. In fact it might be a > candidate to move over to /usr/bin to make official, if there's > sufficient request for that. (such a request should be made via github > issue tracker) > Why was the decision taken to put these into /usr/lib/systemd instead of /usr/libexec/systemd/? > Thanks in advance for indicating, if systemd-cryptsetup (the binary) is > a > > tool users may rely on. > > Yes, absolutely. > > The only reason when we might break things for you is when we one day > move it from /usr/lib to /usr/bin, ;-) > > Hence: the call interface is certainly stable, the location in that > sense maybe not yet. > > Lennart > > -- > Lennart Poettering, Berlin > Greetings, Nils >
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] 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] systemd-repart /etc automount via discoverable partition specification
Hello, I am currently trying to build a linux image with discoverable partitions in an A/B+etc+var scheme. 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. Kind regards, Nils
Re: [systemd-devel] Why are the priorities of stdout and stderr the same
No, you can use systemd-cat to then invoke your script which applies
to every output of it.
Also, you can just use reply-all in gmail (or even set it as the
default in the settings) to have the correct behaviour of sending
mails also the the mailing list.
On Tue, Aug 29, 2023 at 10:25 PM Cecil Westerhof wrote:
>
> Aargh, forgot again that gmail works differently when replying. :'-{
>
> Op di 29 aug 2023 om 21:07 schreef Cecil Westerhof :
>>
>> Op di 29 aug 2023 om 19:47 schreef Nils Kattenbeck :
>>>
>>> Hi, At least for simple cases you can use systemd-cat which allows
>>> setting different priorities for stdout and stderr. It even explicitly
>>> states that doing so will lose the ordering guarantees which are only
>>> possible when attaching stdout and stderr to the same fd (as Lennart
>>> said).
>>
>>
>> If I understand it correctly, that is on a statement basis, not for the
>> complete script.
>
>
> --
> Cecil Westerhof
Re: [systemd-devel] Why are the priorities of stdout and stderr the same
Hi, At least for simple cases you can use systemd-cat which allows setting different priorities for stdout and stderr. It even explicitly states that doing so will lose the ordering guarantees which are only possible when attaching stdout and stderr to the same fd (as Lennart said). Greetings Nils On Tue, Aug 29, 2023 at 2:10 PM Cecil Westerhof wrote: > > Op di 29 aug 2023 om 11:58 schreef Lennart Poettering > : >> >> On Di, 29.08.23 11:56, Cecil Westerhof (cldwester...@gmail.com) wrote: >> > > I agree with that usecase, and we have discussed this many times >> > > before, but we couldn#t come up with a nice way to make everything >> > > work: proper ordering and distintion of stdout/stderr. >> > >> > I agree that the default behaviour is the right one. But why not give >> > people the possibility to override this behaviour? When they override it >> > themselves, they cannot complain that they lose ordering. >> >> We are generally conservative when providing mechanisms that are too >> glaringly broken. Even if they are opt-in. > > > OK. Thanks for your patience. > > -- > Cecil Westerhof
[systemd-devel] USB installer for mkosi
Hi, currently I am building a minimalistic Linux image using mkosi which should be installed on bare-metal hardware. For the installation I am trying to create a USB-stick installer which simply installs the resulting image on the hardware. First and foremost: Does someone maybe know of an existing tool which generates such a USB installer? For now I have found the installer script[1] from Yocto, and FAI (Fully automatic installation)[2]. I would like to avoid using Yocto and the script seems to also perform partitioning etc. which I do not need as mkosi already generates a ready-to-use raw disk image with partitions set up. FAI on the other hand seems to focus on network installs and prefers to build its own images instead of using an arbitrary .raw/ISOs. So I fear that I will have to write my own installer... I do not require fancy GUI shenanigans; a simple CLI application prompting for the destination disk should suffice. Based on my understanding the primary steps are `cp /dev/usb-stick /dev/target-disk` (or dd for the old fashioned), followed by a `parted --script --fix /dev/target-disk print` to resolve GPT warnings due to the header not being at the end when the disk is larger than the USB stick. Is it possible to replace the second step with `systemd-parted`. Especially given that mkosi v15 now uses it for itself, this would likely be a lot cleaner than invoking parted. The major problem I am facing with that approach is how do I know whether I am booting from a USB stick or already from the final disk drive. One technique which comes to mind would be to create two images, one of which will be placed into the mkosi.extra/ directory of the other. This way I could have one auto-start the install script whereas the other image would be completely free of that logic. Am I missing a more obvious way to perform this? Any help would be greatly appreciated! Kind regard, Nils [1] https://github.com/yoctoproject/poky/blob/13734bb520732882a95da7ee6efe1e5b98568acc/meta/recipes-core/initrdscripts/initramfs-module-install-efi_1.0.bb [2] https://fai-project.org/
[systemd-devel] Attaching virtual session (e.g. SSH) to seat
I am logging in on a PC using SSH and need to access some peripherals which are attached to seat0. loginctl shows that my session is not attached to any seat: SESSION UID USER SEAT TTY 50 1000 septatrix pts/0 The devices are added to the seat using udev rules and I explicitly want to avoid making the device world read-/writeable or adding it to a group. Reading through the man pages for systemd-logind, pam_systemd etc did not lead me anywhere helpful but only confirmed the fact that virtual sessions are not assigned any seat by default. However I was unable to find information on how it is determined if a session is "virtual" or whether it can be configured for pam/logind/udev...
