Re: [systemd-devel] The best way to execute kexec via dbus
On Friday 26. August 2022, 16:29:04 (+02:00), Andrei Borzenkov wrote: > Please answer to the list, not me personally. You do it second time. > Sorry, most other mailing lists I am on have reply-to-list as default, I will pay attention to it. > On 26.08.2022 17:12, Tomáš Hnyk wrote: > > On Friday 26. August 2022, 15:02:54 (+02:00), Andrei Borzenkov wrote: > > Indeed, the above makes these two work (included when launched from the > > GUI), thanks!: > > sudo systemctl start kexec.target --job-mode=replace-irreversibly --no-block > > qdbus --system org.freedesktop.systemd1 /org/freedesktop/systemd1 > > org.freedesktop.systemd1.Manager.StartUnit kexec.target replace-irreversibly > > > > Is this a misconfiguration on my part or is that something that should be > > filled as a bug? > > This should be filed as a bug. It is expected to work (IMHO). > I will do that once I update distro to a recent systemd (should be in October), I am on 249 and only 250 and 251 are allowed for bugreports, as I just found out. > > > systemd-analyze gives "Startup finished in 8.467s (firmware) + 402ms > > (loader) + 3.001s (kernel) + 2.885s (userspace) = 14.756s" > > Those eight seconds in firmware are why I am after kexec. Grub gives 4 > > seconds in loader, only systemd is this fast. I am not sure how to check if > > I booted useing systemd-boot otherwise. > > It does not really matter for this specific problem. What matters is > that your have systemd-boot configuration where systemctl can find > suitable boot entry. Of course, it you do not actually use systemd-boot > this can be considered a bug as well, but do not mix two independent issues. > > > efibootmgr gives: > > > > > > BootOrder: > > ,0001,0019,001A,001D,001E,0010,0011,0012,0013,0014,0015,0020,0022,0023,0024,001B,001C,001F,0003 > > Boot* Linux Boot Manager > > Boot0001* ubuntu > > Boot0003* Linux-Firmware-Updater > > > > So I do not understand why the kexec kernel is not loaded, should I remove > > grub completely? > > > > I do not understand this last sentence. I was asking if uninstalling grub might make kexec work, but as per your comment above, that is independent. Thanks for your help! Tomas
Re: [systemd-devel] logind: discontinuous TTYs?
Hi, Arseny Maslennikov wrote: > $ TTYID=tty2 # for example > $ ln -s /dev/null /etc/systemd/system/autovt@$TTYID.service This works, thank you! T.
Re: [systemd-devel] logind: discontinuous TTYs?
On Fri, Aug 26, 2022 at 06:55:46PM +0300, Toomas Rosin wrote: > Hi, > > I would like to configure logind so that it spawns getties only on tty1 > and tty12. I know I can set NAutoVTs to 12, but how to disable getties > on tty2..tty11? $ TTYID=tty2 # for example $ ln -s /dev/null /etc/systemd/system/autovt@$TTYID.service > > Regards, > T. signature.asc Description: PGP signature
Re: [systemd-devel] logind: discontinuous TTYs?
Do they have to be autospawned by logind? You can always statically start getty@.service on any tty you want (like it used to be with inittab). On Fri, Aug 26, 2022 at 7:11 PM Toomas Rosin wrote: > Hi, > > I would like to configure logind so that it spawns getties only on tty1 > and tty12. I know I can set NAutoVTs to 12, but how to disable getties > on tty2..tty11? > > Regards, > T. > -- Mantas Mikulėnas
[systemd-devel] logind: discontinuous TTYs?
Hi, I would like to configure logind so that it spawns getties only on tty1 and tty12. I know I can set NAutoVTs to 12, but how to disable getties on tty2..tty11? Regards, T.
[systemd-devel] systemd-oomd: why swap only?
man oomd.conf: > SwapUsedLimit= >Sets the limit for memory and swap usage on the system before systemd-oomd will take action. If the fraction of memory used and the fraction of swap used on the system are both more than what is defined here, systemd- oomd will act on eligible >descendant control groups with swap usage greater than 5% of total swap, starting from the ones with the highest swap usage. Why memory usage doesn't count? Bug or intentional?
Re: [systemd-devel] The best way to execute kexec via dbus
Please answer to the list, not me personally. You do it second time. On 26.08.2022 17:12, Tomáš Hnyk wrote: > On Friday 26. August 2022, 15:02:54 (+02:00), Andrei Borzenkov wrote: > >> On 26.08.2022 13:54, Tomáš Hnyk wrote: >>> >> > Indeed, it must have been the late night, they are the same. However, >>> the following are not the same even the man page says they are: > > sudo systemctl kexec # results in kexec > > full log here: https://hastebin.com/gubivumaha.apache > > srp 26 10:38:08 GreenOne systemd[1]: Reached target System Shutdown. > srp 26 10:38:08 GreenOne systemd[1]: Reached target Late Shutdown >>> Services. > srp 26 10:38:08 GreenOne systemd[1]: Starting Reboot via kexec... > srp 26 10:38:08 GreenOne systemd[1]: Shutting down. > srp 26 10:38:08 GreenOne systemd-shutdown[1]: Syncing filesystems and >>> block devices. > srp 26 10:38:08 GreenOne systemd-shutdown[1]: Sending SIGTERM to >>> remaining processes... > srp 26 10:38:08 GreenOne systemd-journald[416]: Journal stopped > > > sudo systemctl start kexec.target --job-mode=replace-irreversibly >>> --no-block # failed attempted kexec > You are right. systemctl does more (and differently) in case of "systemctl kexec". Not sure whether it needs explicit documentation though, as expectations are that it /should/ have the same effect. >>> Well, I guess then the man page could say something like (caps are what >>> would change) - I did assume one was just shorthand for the other: >>> >>> Shut down and reboot the system via kexec. This is MORE OR >>> LESS/TYPICALLY/SHOULD BE(+delete "is") equivalent to systemctl start >>> kexec.target --job-mode=replace-irreversibly --no-block. >>> > srp 26 10:39:04 GreenOne systemctl[2041]: Cannot automatically load >>> kernel: ESP mount point not found. That could be the actual reason. systemctl attempts to autodetect kernel for kexec and it needs ESP; final call to "systemctl --force kexec" happens late, when ESP (/boot/efi in your case) is already unmounted. For testing you could set DefaultDependencies=false for /boot/efi to avoid it being unmounted on shutdown. >>> Where can I set it? kexec.target already has "DefaultDependencies=no" in >>> [Unit]? >>> >> >> It is not about kexec.target. >> >> You can add it in drop-in, like >> >> bor@localhost:~> cat /etc/systemd/system/boot-efi.mount.d/nodef.conf >> [Unit] >> DefaultDependencies=false >> bor@localhost:~> >> >> By default fsck service has RemainAfterExit=yes and mount units require >> fsck services so they are stopped anyway, I had to add override >> >> bor@localhost:~> cat >> /etc/systemd/system/systemd-fsck@dev-disk-by\\x2duuid-893B\\x2d91D8.service.d/exit.conf >> >> [Service] >> RemainAfterExit=false >> bor@localhost:~> >> > > Indeed, the above makes these two work (included when launched from the GUI), > thanks!: > sudo systemctl start kexec.target --job-mode=replace-irreversibly --no-block > qdbus --system org.freedesktop.systemd1 /org/freedesktop/systemd1 > org.freedesktop.systemd1.Manager.StartUnit kexec.target replace-irreversibly > > Is this a misconfiguration on my part or is that something that should be > filled as a bug? This should be filed as a bug. It is expected to work (IMHO). > I would have expected this to just work right away. Is it safe if I leave my > configuration system with the overrides you suggested? > Well, I do not trust systemd to not attempt fsck on mounted filesystem in response to some event, so I guess better is to remove Conflicts=shutdown.target. > >> >> But notice also that systemd only supports automatic detection when >> using systemd-boot. E.g. here openSUSE provides customer service that >> detects default grub2 boot entry and performs "kexec --load". >> > > But I am using systemd-boot! Do not forget to mention in in your bug report. > systemd-analyze gives "Startup finished in 8.467s (firmware) + 402ms (loader) > + 3.001s (kernel) + 2.885s (userspace) = 14.756s" > Those eight seconds in firmware are why I am after kexec. Grub gives 4 > seconds in loader, only systemd is this fast. I am not sure how to check if I > booted useing systemd-boot otherwise. It does not really matter for this specific problem. What matters is that your have systemd-boot configuration where systemctl can find suitable boot entry. Of course, it you do not actually use systemd-boot this can be considered a bug as well, but do not mix two independent issues. > efibootmgr gives: > > > BootOrder: > ,0001,0019,001A,001D,001E,0010,0011,0012,0013,0014,0015,0020,0022,0023,0024,001B,001C,001F,0003 > Boot* Linux Boot Manager > Boot0001* ubuntu > Boot0003* Linux-Firmware-Updater > > So I do not understand why the kexec kernel is not loaded, should I remove > grub completely? > I do not understand this last sentence.
Re: [systemd-devel] The best way to execute kexec via dbus
On 26.08.2022 13:54, Tomáš Hnyk wrote: > > > >> > > > Indeed, it must have been the late night, they are the same. However, > the following are not the same even the man page says they are: > > > > > > sudo systemctl kexec # results in kexec > > > > > > full log here: https://hastebin.com/gubivumaha.apache > > > > > > srp 26 10:38:08 GreenOne systemd[1]: Reached target System Shutdown. > > > srp 26 10:38:08 GreenOne systemd[1]: Reached target Late Shutdown > Services. > > > srp 26 10:38:08 GreenOne systemd[1]: Starting Reboot via kexec... > > > srp 26 10:38:08 GreenOne systemd[1]: Shutting down. > > > srp 26 10:38:08 GreenOne systemd-shutdown[1]: Syncing filesystems and > block devices. > > > srp 26 10:38:08 GreenOne systemd-shutdown[1]: Sending SIGTERM to > remaining processes... > > > srp 26 10:38:08 GreenOne systemd-journald[416]: Journal stopped > > > > > > > > > sudo systemctl start kexec.target --job-mode=replace-irreversibly > --no-block # failed attempted kexec > > > > > > > You are right. systemctl does more (and differently) in case of > > "systemctl kexec". Not sure whether it needs explicit documentation > > though, as expectations are that it /should/ have the same effect. > > > Well, I guess then the man page could say something like (caps are what > would change) - I did assume one was just shorthand for the other: > > Shut down and reboot the system via kexec. This is MORE OR > LESS/TYPICALLY/SHOULD BE(+delete "is") equivalent to systemctl start > kexec.target --job-mode=replace-irreversibly --no-block. > > > > srp 26 10:39:04 GreenOne systemctl[2041]: Cannot automatically load > kernel: ESP mount point not found. > > > > That could be the actual reason. systemctl attempts to autodetect kernel > > for kexec and it needs ESP; final call to "systemctl --force kexec" > > happens late, when ESP (/boot/efi in your case) is already unmounted. > > > > For testing you could set DefaultDependencies=false for /boot/efi to > > avoid it being unmounted on shutdown. > > > Where can I set it? kexec.target already has "DefaultDependencies=no" in > [Unit]? > It is not about kexec.target. You can add it in drop-in, like bor@localhost:~> cat /etc/systemd/system/boot-efi.mount.d/nodef.conf [Unit] DefaultDependencies=false bor@localhost:~> By default fsck service has RemainAfterExit=yes and mount units require fsck services so they are stopped anyway, I had to add override bor@localhost:~> cat /etc/systemd/system/systemd-fsck@dev-disk-by\\x2duuid-893B\\x2d91D8.service.d/exit.conf [Service] RemainAfterExit=false bor@localhost:~> But notice also that systemd only supports automatic detection when using systemd-boot. E.g. here openSUSE provides customer service that detects default grub2 boot entry and performs "kexec --load".
Re: [systemd-devel] The best way to execute kexec via dbus
On 26.08.2022 12:29, Tomáš Hnyk wrote: > On Friday 26. August 2022, 06:55:15 (+02:00), Andrei Borzenkov wrote: > >> On 26.08.2022 03:59, Tomáš Hnyk wrote: >>> Hello,I am trying to be able to reboot with kexec from a GUI (I am >>> modifying this: https://github.com/varlesh/org.kde.plasma.compact-shutdown >>> ). As far as I can tell, I need to use qdbus. Via command line, I can >>> successfully reboot with kexec with: >>> systemctl start kexec.target --job-mode=replace-irreversibly --no-block >>> >>> When I remove the --noblock parameter, the kexed reboot fails and normal >>> reboot is performed. >> >> There should be no difference between the two. Both do exactly the same >> D-Bus call. Debug logs in both cases would be interesting. >> > Indeed, it must have been the late night, they are the same. However, the > following are not the same even the man page says they are: > > sudo systemctl kexec # results in kexec > > full log here: https://hastebin.com/gubivumaha.apache > > srp 26 10:38:08 GreenOne systemd[1]: Reached target System Shutdown. > srp 26 10:38:08 GreenOne systemd[1]: Reached target Late Shutdown Services. > srp 26 10:38:08 GreenOne systemd[1]: Starting Reboot via kexec... > srp 26 10:38:08 GreenOne systemd[1]: Shutting down. > srp 26 10:38:08 GreenOne systemd-shutdown[1]: Syncing filesystems and block > devices. > srp 26 10:38:08 GreenOne systemd-shutdown[1]: Sending SIGTERM to remaining > processes... > srp 26 10:38:08 GreenOne systemd-journald[416]: Journal stopped > > > sudo systemctl start kexec.target --job-mode=replace-irreversibly --no-block > # failed attempted kexec > You are right. systemctl does more (and differently) in case of "systemctl kexec". Not sure whether it needs explicit documentation though, as expectations are that it /should/ have the same effect. > full log here: https://hastebin.com/ruzunihepe.apache > > srp 26 10:39:04 GreenOne systemd[1]: Starting Unload nvidia modesetting > modules from kernel POTREBUJE NVIDIA PRO KEXEC... > srp 26 10:39:04 GreenOne kernel: [drm] [nvidia-drm] [GPU ID 0x0100] > Unloading driver > srp 26 10:39:04 GreenOne systemd[1]: lvm2-monitor.service: Deactivated > successfully. > srp 26 10:39:04 GreenOne systemd[1]: Stopped Monitoring of LVM2 mirrors, > snapshots etc. using dmeventd or progress polling. > srp 26 10:39:04 GreenOne systemd[1]: Reached target System Shutdown. > srp 26 10:39:04 GreenOne systemd[1]: Reached target Late Shutdown Services. > srp 26 10:39:04 GreenOne systemd[1]: Starting Reboot via kexec... > srp 26 10:39:04 GreenOne systemctl[2041]: No kexec kernel loaded and > autodetection failed. > srp 26 10:39:04 GreenOne systemctl[2041]: Cannot automatically load kernel: > ESP mount point not found. That could be the actual reason. systemctl attempts to autodetect kernel for kexec and it needs ESP; final call to "systemctl --force kexec" happens late, when ESP (/boot/efi in your case) is already unmounted. For testing you could set DefaultDependencies=false for /boot/efi to avoid it being unmounted on shutdown. > srp 26 10:39:04 GreenOne systemctl[2041]: Failed to load kexec kernel, > continuing without. > srp 26 10:39:04 GreenOne systemd[1]: Shutting down.
Re: [systemd-devel] socket activation selinux context on create
On Do, 25.08.22 14:46, Ted Toth (txt...@gmail.com) wrote: > I've tested setting the type of the port using semanage port -a > however when I start the service netstat still shows the type as > init_t. I don't know of any other way to get a type transition of a > socket to happen, do you?. I've also posted to the selinux list but > haven't gotten any responses yet. Uh, that's a question for the selinux people. I only have a limited insight into selinux, and wouldn't know how to do such things. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] The best way to execute kexec via dbus
On Friday 26. August 2022, 06:55:15 (+02:00), Andrei Borzenkov wrote: > On 26.08.2022 03:59, Tomáš Hnyk wrote: > > Hello,I am trying to be able to reboot with kexec from a GUI (I am > > modifying this: https://github.com/varlesh/org.kde.plasma.compact-shutdown > > ). As far as I can tell, I need to use qdbus. Via command line, I can > > successfully reboot with kexec with: > > systemctl start kexec.target --job-mode=replace-irreversibly --no-block > > > > When I remove the --noblock parameter, the kexed reboot fails and normal > > reboot is performed. > > There should be no difference between the two. Both do exactly the same > D-Bus call. Debug logs in both cases would be interesting. > Indeed, it must have been the late night, they are the same. However, the following are not the same even the man page says they are: sudo systemctl kexec # results in kexec full log here: https://hastebin.com/gubivumaha.apache srp 26 10:38:08 GreenOne systemd[1]: Reached target System Shutdown. srp 26 10:38:08 GreenOne systemd[1]: Reached target Late Shutdown Services. srp 26 10:38:08 GreenOne systemd[1]: Starting Reboot via kexec... srp 26 10:38:08 GreenOne systemd[1]: Shutting down. srp 26 10:38:08 GreenOne systemd-shutdown[1]: Syncing filesystems and block devices. srp 26 10:38:08 GreenOne systemd-shutdown[1]: Sending SIGTERM to remaining processes... srp 26 10:38:08 GreenOne systemd-journald[416]: Journal stopped sudo systemctl start kexec.target --job-mode=replace-irreversibly --no-block # failed attempted kexec full log here: https://hastebin.com/ruzunihepe.apache srp 26 10:39:04 GreenOne systemd[1]: Starting Unload nvidia modesetting modules from kernel POTREBUJE NVIDIA PRO KEXEC... srp 26 10:39:04 GreenOne kernel: [drm] [nvidia-drm] [GPU ID 0x0100] Unloading driver srp 26 10:39:04 GreenOne systemd[1]: lvm2-monitor.service: Deactivated successfully. srp 26 10:39:04 GreenOne systemd[1]: Stopped Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling. srp 26 10:39:04 GreenOne systemd[1]: Reached target System Shutdown. srp 26 10:39:04 GreenOne systemd[1]: Reached target Late Shutdown Services. srp 26 10:39:04 GreenOne systemd[1]: Starting Reboot via kexec... srp 26 10:39:04 GreenOne systemctl[2041]: No kexec kernel loaded and autodetection failed. srp 26 10:39:04 GreenOne systemctl[2041]: Cannot automatically load kernel: ESP mount point not found. srp 26 10:39:04 GreenOne systemctl[2041]: Failed to load kexec kernel, continuing without. srp 26 10:39:04 GreenOne systemd[1]: Shutting down. srp 26 10:39:04 GreenOne systemd-shutdown[1]: Syncing filesystems and block devices. srp 26 10:39:04 GreenOne systemd-shutdown[1]: Sending SIGTERM to remaining processes... srp 26 10:39:04 GreenOne systemd-journald[419]: Journal stopped Note that "Unload nvidia modesetting modules from kernel POTREBUJE NVIDIA PRO KEXEC..." is a systemd unit as per https://wiki.archlinux.org/title/kexec#No_kernel_mode-setting_(Nvidia) that is needed on my system to achieve kexec and which is WantedBy=kexec.target I get almost the same results with the following: qdbus --system org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager.StartUnit kexec.target replace-irreversibly # failed attempted kexec (for testing purposes, I got a polkit policy that allows my user to start systemd units, which I guess is not great security-wise) full log here: https://hastebin.com/onesohuwik.apache srp 26 10:39:57 GreenOne systemd[1]: Starting Unload nvidia modesetting modules from kernel POTREBUJE NVIDIA PRO KEXEC... srp 26 10:39:57 GreenOne kernel: [drm] [nvidia-drm] [GPU ID 0x0100] Unloading driver srp 26 10:39:57 GreenOne systemd[1]: lvm2-monitor.service: Deactivated successfully. srp 26 10:39:57 GreenOne systemd[1]: Stopped Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling. srp 26 10:39:57 GreenOne systemd[1]: Reached target System Shutdown. srp 26 10:39:57 GreenOne systemd[1]: Reached target Late Shutdown Services. srp 26 10:39:57 GreenOne systemd[1]: Starting Reboot via kexec... srp 26 10:39:57 GreenOne systemctl[1979]: No kexec kernel loaded and autodetection failed. srp 26 10:39:57 GreenOne systemctl[1979]: Cannot automatically load kernel: ESP mount point not found. srp 26 10:39:57 GreenOne systemctl[1979]: Failed to load kexec kernel, continuing without. srp 26 10:39:57 GreenOne systemd[1]: Shutting down. srp 26 10:39:57 GreenOne kernel: nvidia-modeset: Unloading srp 26 10:39:57 GreenOne systemd-shutdown[1]: Syncing filesystems and block devices. srp 26 10:39:57 GreenOne systemd-shutdown[1]: Sending SIGTERM to remaining processes... srp 26 10:39:57 GreenOne systemd-journald[422]: Journal stopped (the only difference here is that nvidia is actualy unloaded, it does not seem relevant to me, so I think these cases are identical) > > And can I somehow get around it? I am now using this: > > qdbus --system org.freedesktop.systemd1
[systemd-devel] Antw: [EXT] Re: [systemd‑devel] Ordering units and targets with devices
>>> Michael Cassaniti schrieb am 26.08.2022 um 06:46 >>> in Nachricht <01000182d8797b39-375650cc-485b-43ec-84e0-9be3a66f22f4-000...@email.amazonses.co >: > On 25/8/22 22:22, Lennart Poettering wrote: >> On Do, 25.08.22 10:50, Michael Cassaniti (mich...@cassaniti.id.au) wrote: >> >>> It seems to be somewhat more complicated than that, and perhaps it has more >>> to do with my setup. Here's my /etc/crypttab which just might explain a bit: >>> >>> # Mount root and swap >>> # These will initially have an empty password >>> root /dev/disk/by-partlabel/root - > fido2-device=/dev/yubico-fido2,token-timeout=0,try-empty-password=true,x-init > rd.attach >>> swap /dev/disk/by-partlabel/swap - > fido2-device=/dev/yubico-fido2,token-timeout=0,try-empty-password=true,x-init > rd.attach >>> >>> I think the fact that both of these get setup at boot and will concurrently >>> try to access the FIDO2 token is causing issues. That crypttab is included >>> in the initrd. >> There was an issue with concurrent access to FIDO2 devices conflicting >> with each other. This was addressed in libfido2 though, it will now >> take a BSD lock on the device while talking to it, thus synchronizing >> access properly. >> >> See this bug: >> >> https://github.com/systemd/systemd/issues/23889 >> >> Maybe it's sufficient to update libfido2 on your system? >> >> >> Lennart >> >> -- >> Lennart Poettering, Berlin > Hi Lennart, > Thanks for the fast response. I've got version 1.11 of libfido2 and it > seems I'd need 1.12 (to be released) to fix it [1]. It terrifies me to > think what I might break on my system by upgrading libfido2. On Gentoo Or "Use the source, Luke": Try to "patch in" just that missing lock into your current version. > there is revdep-rebuild but Ubuntu doesn't have anything like that. I'm > on Ubuntu 22.10 which is the latest development version so I can use > some shiny new systemd features. > > For now I've written a rather dodgy generator that will scan through the > generated units for both cryptsetup and resume, then add in some > ordering. Currently it will make the cryptsetup units run serially. I am > yet to test it though. > > [1]: https://github.com/Yubico/libfido2/pull/604#issuecomment-1178637796 > > Thanks, > Michael Cassaniti, Australia
