Re: Ton of random units "could not be found"
On Sat, 2023-12-16 at 15:31 +0100, Lennart Poettering wrote: > On Fr, 15.12.23 22:17, chandler (s...@riseup.net) wrote: > > Other items have different situations, like tmp.mount exists at > > /usr/share/systemd/tmp.mount but isn't an enabled unit or anything, if I > > try to enable or unmask it I'm just told "Unit tmp.mount could not be > > found." or "Unit file tmp.mount does not exist." > > /usr/share/systemd/ is not a directory systemd ever looks into for > unit files. If debian packaged something there, this smells like a > bug. Please report to your distro. Debian does not use tmpfs for /tmp by default. The unit is placed there because it's intentionally not in use unless you enable it (and not just by "systemctl enable", I believe it's done this way to prevent any dependencies in other units from accidentally activating it, possibly at a moment when it would hide already existing contents of /tmp).
Re: [RFC] initoverlayfs - a scalable initial filesystem
On Do, 14.12.23 02:17, Nils Kattenbeck (nilskem...@gmail.com) wrote: > 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? These cpios are created on-the-fly and placed into memory and passed to the invoked kernel. And yes, for that the data they contian needs to be read off disk first. Lennart -- Lennart Poettering, Berlin
Re: Ton of random units "could not be found"
On Fr, 15.12.23 22:17, chandler (s...@riseup.net) wrote: > Hi all, > > When I run `systemctl status --all` I see a ton of "Unit X could not > be found" where X = an item from the list below. How did this mess > happen and how to clean it up? None of these units represent things the > system is using, for the most part. This is not an issue. As Andrei already answered this just tells you that some services have ordering deps against other units which aren't installed, which is entirely fine. It's just metainfo that if you install some packages in combination the right order is applied. There's a reason why these entries are generally not shown. Except you used "--all", which literally means "Hey, please also show me *everything* you have heard about". Just drop the "--all" from your command line. > Some units appear to be remnants left behind in /etc/systemd, for > example /etc/systemd/system/ntp.service is a symlink pointing to > non-existent /lib/systemd/system/ntpsec.service. I can delete > /etc/systemd/system/ntp.service and after `systemctl daemon-reload` it's > now gone from the list below. That smells like a packaging bug, you removed some package and it forgot to invoke "systemctl disable" from it's pakaging uninstall scripts first. File a bug against yout distro. > Other items have different situations, like tmp.mount exists at > /usr/share/systemd/tmp.mount but isn't an enabled unit or anything, if I > try to enable or unmask it I'm just told "Unit tmp.mount could not be > found." or "Unit file tmp.mount does not exist." /usr/share/systemd/ is not a directory systemd ever looks into for unit files. If debian packaged something there, this smells like a bug. Please report to your distro. Lennart -- Lennart Poettering, Berlin
