[systemd-devel] PCR signing / enrolling on UKI and validation by systemd-cryptenroll
Hi everybody, For some time now I have been using UKIs, with SB enabled and tying FDE decryption on PCRs 7+11+14, with the PCR 11 being measured during UKI creation. Then, I use systemd-cryptenroll to update the secret: PCR11=$(/usr/lib/systemd/ukify -c /etc/kernel/uki.conf --measure --output=/tmp/arch-linux.efi build | grep 11:sha256) systemd-cryptenroll --unlock-key-file=/root/creds/fdepassword.txt --wipe-slot=tpm2 --tpm2-device=auto --tpm2-pcrs=7+11:sha256=d05ee4...+14 /dev/nvme0n1p5 This works, flawlessly. Now, I am exploring the possibility to not bind to the value of those PCRS but to their signature, given that I am also embedding that in the UKI (the correspondent .pcrsig section is in place). However, I am a bit lost: * in .pcrsig there is only the signature for pcr11, and there seems to be no way to embed the signatures for other PCR values. * when used in cryptenroll, how should I use this? So far, seems should be a call like systemd-cryptenroll --unlock-key-file=/root/creds/fdepassword.txt --wipe-slot=tpm2 --tpm2-device=auto --tpm2-public-key=/root/creds/tpm2-pcr-public.pem --tpm2-public-key-pcrs= ... but then I do not see what should be provided in tpm2-public-key-pcrs. The same values I am currently giving to --tpm2-pcrs? the signatures that I get from the .pcrsig for 11 + the calculated signatures for the current values of the PCRs 7 and 14? Thank you very much for your time, -- Felix Rubio
[systemd-devel] unlocking LUKS volume using PCRs and UKI
Hi everybody, Some months ago I tried to learn about systemd cryptenroll, ukify, etc., and I managed to get a UKI that gets updated every time the kernel / modules change by running: ## /usr/lib/systemd/ukify --linux /boot/vmlinuz-linux --initrd /boot/amd-ucode.img --initrd /boot/initramfs-linux.img \ --os-release=@$OSRELEASE \ --cmdline="$CMDLINE" \ --secureboot-certificate=/root/SecureBoot/MOK.crt --secureboot-private-key=/root/SecureBoot/MOK.key \ --output=$OUTPUTPATH/$UKIFILE build ## To set up the unlock of the disk, I ran the following command (only once, as pcrs 7 and 14 have not changed since then): systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto --tpm2-pcrs=7+14 /dev/nvme0n1p5 Since then, systemd-cryptenroll has been extended so that literal values can be provided, meaning that (*I think*) I can upgrade my previous process to: ## PCR11=$(/usr/lib/systemd/ukify --linux /boot/vmlinuz-linux --initrd /boot/amd-ucode.img --initrd /boot/initramfs-linux.img \ --os-release=@$OSRELEASE \ --cmdline="$CMDLINE" \ --secureboot-certificate=/root/SecureBoot/MOK.crt --secureboot-private-key=/root/SecureBoot/MOK.key \ --measure \ --phases="enter-initrd" \ --pcr-private-key=/root/SecureBoot/PCRsigning/tpm2-pcr-private.pem \ --pcr-public-key=/root/SecureBoot/PCRsigning/tpm2-pcr-public.pem \ --output=$OUTPUTPATH/$UKIFILE build | grep 11:sha256) systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto --tpm2-pcrs=7+$PCR11+14 /dev/nvme0n1p5 ## Do you guys think this is a sensible approach? As I want to bind the unlock of the disk to PCR11, I think I only need to get the measurement of that PCR register in the "enter-initrd" phase, right? What are the implications of providing as well the pcr-private-key parameter? I have gone through the documentation of systemd-cryptenroll, systemd-measure and systemd's ukify, but is not clear to me if this set of flags will (besides providing the measurement I am interested on) also let the kernel continue booting only if the signed policy that gets calculated out of that register is fulfilled. Should that be the case, this additional control will not harm but I guess is a bit redundant for my use case? Thank you very much for your time, -- Felix Rubio "Don't believe what you're told. Double check."
[systemd-devel] Help debugging the access to a hashmap object
Hi everybody,
I am kind of lost, and after some hours giving a look at the issue...
maybe somebody can give me a hand? I am working on the PR
https://github.com/systemd/systemd/pull/28339, to provide a way to
specify literals for the PCRs. As part of this PR I am creating a
hashmap of hashmaps, in which keys are strings (for the container
hashmap, the banks: e.g., "sha256", and for the contained hashmap the
pcr index: e.g., "11").
My problem is that in my test I populate PCR idx 11 and I get the
following debugging output from hashmap_get (which I call right after
storing it):
HM: 0x55b0b5524c88 11 1 1
In which 0x55bc13fc0c88 is the pointer to the bank, 11 is the pcr_idx,
and 1 and 1 are respectively the hash and idx as found by _hashmap_get
in hashmap.c:1359 in my branch.
Should I use either a parameter pointer for "11" or a constant, there is
no difference: it works as expected. So far so good. Now, should I call
it from another method (in this case, a method I use to generate the
mask out of all the keys in the map), what I get is quite different:
HM: 0x55b0b5524c88 11 1 4294967295
in which the idx is 4294967295 ==> IDX_NIL. In both cases, I am calling
hashmap_get like this:
TPM2B_DIGEST *v2 = hashmap_get(bank, "11");
First I thought that somehow the value was being deleted, so then I
decided to print all the keys for that hashmap (expecting to find none,
as I only set one entry). In this case, what I run, right after setting
the element and on the other function, is:
int *k;
TPM2B_DIGEST *v;
HASHMAP_FOREACH_KEY(v, k, bank) {
_cleanup_free_ char *hex = NULL;
hex = hexmem(v->buffer, v->size);
fprintf(stderr, "%p %d %s\n", bank, *k, hex);
}
and what I obtained is:
IN : 0x55b0b5524c88 1526739249
3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969
OUT: 0x55b0b5524c88 892625971
3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969
So: I am getting the same pointer for the bank, the hex value for the
PCR is correct, but the key is different: the entry is not lost, just
seems to be relocated? How is this possible?
Thank you in advance, if anybody can point out what am I doing wrong...
:-/.
Re: [systemd-devel] Systemd-cryptsetup triggers a black screen after upgrading to 6.4.1
Nope: AMD Ryzen 7 6800H, But thank you for the suggestion! Felix On 2023-07-07 09:07, Christian Hesse wrote: Felix Rubio on Thu, 2023/07/06 18:07: Using arch linux, I have had my kernel upgraded from 6.3.9 to 6.4.1. After regenerating the UKI, that works, I get just a black screen when systemd-cryptsetup should be either using the TPM to unlock the drive or to ask me the rescue password. Possibly running on a Framework laptop with Intel 12th gen or later? https://bugs.archlinux.org/task/78961 https://bugzilla.kernel.org/show_bug.cgi?id=217631
[systemd-devel] Systemd-cryptsetup triggers a black screen after upgrading to 6.4.1
Using arch linux, I have had my kernel upgraded from 6.3.9 to 6.4.1. After regenerating the UKI, that works, I get just a black screen when systemd-cryptsetup should be either using the TPM to unlock the drive or to ask me the rescue password. Luckily I have an old UKI with 6.3.9 (also the correspondent /lib/modules) so that I can boot with the old one, but the question is: any idea on how to debug this issue? I had the same problem previously, which I could trace back to the upgrade of linux-firmware and that got fixed two days later when the same package got updated, but now I have checked and there's been no update about that. Is there any way to set systemd in verbose mode, so that I get more information before the black screen? Thank you, Felix
Re: [systemd-devel] Enrolling PCR11 does not work as expected
In order to achieve the check of a number of PCRs, what do you guys think of this approach? 1. When running ukify, add the "measure" flag so that the expected value of the PCR11 is printed. 2. Then, script the reset of an unused PCR (in my case, 23), and the extend it with the current value of PCRs 7 and 14, and the expected value of PCR 11 3. Run systemd-cryptenroll against PCR 23 4. add a configuration drop to /etc/systemd/system/systemd-cryptsetup@.service.d, so that at ExecPre a similar script of that in 2 is run, but in this case resetting PCR 23 and extending it with the actual values of PCRs 7, 14 and 11. Do you guys this approach is sound? Thank you, Felix On 2023-07-05 14:26, Lennart Poettering wrote: On Mi, 05.07.23 13:11, Felix Rubio (fe...@kngnt.org) wrote: For what is explained on the the systemd-pcrphase.service(8) and comparing it to what I see in the log of the systemd services, there are three events in relation to this question: systemd-pcrphase-initrd.service [...] [systemd-ask-password-console.service] [...] systemd-pcrphase-sysinit systemd-pcrphase This means that, indeed, running cryptenroll after the new kernel has booted will never provide the correct PCR registry for 11. But then... what options do I have? Do I need to choose between having PCRs 7 and 14, so that I make sure that SB is up and running and all the certs from shim have not changed, or to have only PCR 11 so that I know that the UKI has not changed although SB can potentially be even disabled (please, correct me if wrong)? The idea is that with systemd-measure you sign the pre-calculated PCRs for all phases you care about with a key, and then you use enroll the public key that matches that signature in the disk encryption, rather than literal PCR values. Using signed PCR policies enables you to do multiple things at once: 1. You can easily enroll one public key, and have it cover multiple phases of the boot, simply by providing multiple signatures for the PCR values expected in the various boot phases. 2. You can easily enroll one public key, and then update the UKI and still boot up correctly, by providing a new set of signatures for the new expected PCR values for the various boot phases. Hence, the PCR 11 logic we have in place is *not* designed with TPM policies that bind to explicit PCR values in mind. Instead it is designed in mind with policies that bind to public keys that match signatures of those PCR values. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Enrolling PCR11 does not work as expected
I understand that, but systemd-measure is only about PCR 11. Is there any way to provide a list of PCRs, so that additionally can be embedded on the UKI? Thank you, Felix On 2023-07-05 14:26, Lennart Poettering wrote: On Mi, 05.07.23 13:11, Felix Rubio (fe...@kngnt.org) wrote: For what is explained on the the systemd-pcrphase.service(8) and comparing it to what I see in the log of the systemd services, there are three events in relation to this question: systemd-pcrphase-initrd.service [...] [systemd-ask-password-console.service] [...] systemd-pcrphase-sysinit systemd-pcrphase This means that, indeed, running cryptenroll after the new kernel has booted will never provide the correct PCR registry for 11. But then... what options do I have? Do I need to choose between having PCRs 7 and 14, so that I make sure that SB is up and running and all the certs from shim have not changed, or to have only PCR 11 so that I know that the UKI has not changed although SB can potentially be even disabled (please, correct me if wrong)? The idea is that with systemd-measure you sign the pre-calculated PCRs for all phases you care about with a key, and then you use enroll the public key that matches that signature in the disk encryption, rather than literal PCR values. Using signed PCR policies enables you to do multiple things at once: 1. You can easily enroll one public key, and have it cover multiple phases of the boot, simply by providing multiple signatures for the PCR values expected in the various boot phases. 2. You can easily enroll one public key, and then update the UKI and still boot up correctly, by providing a new set of signatures for the new expected PCR values for the various boot phases. Hence, the PCR 11 logic we have in place is *not* designed with TPM policies that bind to explicit PCR values in mind. Instead it is designed in mind with policies that bind to public keys that match signatures of those PCR values. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Enrolling PCR11 does not work as expected
For what is explained on the the systemd-pcrphase.service(8) and comparing it to what I see in the log of the systemd services, there are three events in relation to this question: systemd-pcrphase-initrd.service [...] [systemd-ask-password-console.service] [...] systemd-pcrphase-sysinit systemd-pcrphase This means that, indeed, running cryptenroll after the new kernel has booted will never provide the correct PCR registry for 11. But then... what options do I have? Do I need to choose between having PCRs 7 and 14, so that I make sure that SB is up and running and all the certs from shim have not changed, or to have only PCR 11 so that I know that the UKI has not changed although SB can potentially be even disabled (please, correct me if wrong)? Thank you! Felix On 2023-07-05 10:36, Lennart Poettering wrote: On Mi, 05.07.23 08:30, Felix Rubio (fe...@kngnt.org) wrote: Hi everybody, In my setup (sd-boot+UKI+LUKS) I am using PCRs 7+11+14 to unlock the LUKS drive. Should I use only PCRs 7+14 everything works, but when I add 11 I need to provide the rescue password every single time I boot. I have extracted the values of those PCRs using tpm2_pcrread in two consecutive boots, and they are equal, so at least the issue is reproducible. To enroll the PCRs, after a new kernel (and, therefore, the UKI) has been generated, I run the following command: systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto --tpm2-pcrs=7+11+14 After reading the documentation on systemd-measure (that I am not using at the moment): could it be that there are events added to PCR 11 after the unlocking has happened, so that I am enrolling the wrong PCR value? Otherwise... what am I doing wrong? We mesaure the "boot phase" into PCR 11 too. See systemd-pcrphase.service(8) for details. Generally the assumption is that PCR 11 is used for signed PCR policies, i.e. under vendor control. Lennart -- Lennart Poettering, Berlin
[systemd-devel] Enrolling PCR11 does not work as expected
Hi everybody, In my setup (sd-boot+UKI+LUKS) I am using PCRs 7+11+14 to unlock the LUKS drive. Should I use only PCRs 7+14 everything works, but when I add 11 I need to provide the rescue password every single time I boot. I have extracted the values of those PCRs using tpm2_pcrread in two consecutive boots, and they are equal, so at least the issue is reproducible. To enroll the PCRs, after a new kernel (and, therefore, the UKI) has been generated, I run the following command: systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto --tpm2-pcrs=7+11+14 After reading the documentation on systemd-measure (that I am not using at the moment): could it be that there are events added to PCR 11 after the unlocking has happened, so that I am enrolling the wrong PCR value? Otherwise... what am I doing wrong? Felix
[systemd-devel] How to tie the unlocking of a LUKS device to multiple PCRs, when one of them is calculated?
Hi everybody, systemd-cryptenroll can seal/unseal the LUKS key in the TPM predicted to the state of some registers, e.g.: systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto --tpm2-pcrs=7+11+14 The problem is that this requires, when there are kernel / bootloader / ... updates, to restart the system, unlock manually and run the command again to enroll the new pcr values. As discussed in this mailing list, the way to go to ensure that both the kernel and initramfs are checked is to use UKI, whose expected PCR 11 state can be calculated by systemd-measure (examples from https://www.freedesktop.org/software/systemd/man/systemd-measure.html): * To generate the signature: systemd-measure sign --linux=vmlinux --osrel=os-release.txt --cmdline=cmdline.txt \ --initrd=initrd.cpio --splash=splash.bmp --dtb=devicetree.dtb --pcrpkey=tpm2-pcr-public.pem \ --bank=sha1 --bank=sha256 --private-key=tpm2-pcr-private.pem \ --public-key=tpm2-pcr-public.pem >tpm2-pcr-signature.json.tmp * To embed the signature on the image: ukify --output foo.efi --os-release @os-release.txt --cmdline @cmdline.txt --splash splash.bmp \ --devicetree devicetree.dtb --pcr-private-key tpm2-pcr-private.pem \ --pcr-public-key tpm2-pcr-public.pem --pcr-banks sha1,sha256 vmlinux initrd.cpio * To enroll the PCR policy: systemd-cryptenroll --tpm2-device=auto --tpm2-public-key=tpm2-pcr-public.pem --tpm2-signature=tpm2-pcr-signature.json This process binds the unsealing of the LUKS decryption key to the PCR 11, but is not clear how (or even if it is possible) to add other PCRs to the mix (those being 7 and 14, in my case). To compare, this is what I was doing when dealing directly with the TPM (so, before switching to systemd), creating two policies and combining them with a policyor: # session for auth based on pcr tpm2_startauthsession -S session.ctx tpm2_policypcr -S session.ctx -L regular.policy -l sha256:0,1,7,9 tpm2_policypassword -S session.ctx -L regular.policy tpm2_flushcontext session.ctx # session for auth based on rescue password tpm2_startauthsession -S session.ctx tpm2_policysecret -S session.ctx -L rescue.policy -c o '' tpm2_flushcontext session.ctx # compound both policies using OR tpm2_startauthsession -S session.ctx tpm2_policyor -S session.ctx -L compound.policy sha256:rescue.policy,regular.policy tpm2_flushcontext session.ctx # create the seal object tpm2_create -C prim.ctx -c key.ctx -u key.pub -r key.priv -L compound.policy -i- -p '' -a 'fixedtpm|fixedparent' Is there any way to do something similar with systemd-cryptenroll? Regards! -- Felix
Re: [systemd-devel] sd-boot setup and PCRs
Hi Lennart, Andrei, Adrian Understood, and thank you very much :-) then 7+11+14 it is. Regards! --- Felix Rubio "Don't believe what you're told. Double check." On 2023-06-19 17:21, Lennart Poettering wrote: On So, 18.06.23 20:56, Felix Rubio (fe...@kngnt.org) wrote: Hi everybody, After some days offline, today I have gone through the emails exchanged a couple of weeks ago and agreed: UKI is the way to go. Last time I checked about it I read about possible problems related to when some modules would be loaded and so, but I see that my knowledge was outdated. This said, right now my setup looks like: SecureBoot is enabled, I am using Shim, Systemd-Boot as shim's second stage, and a UKI. As the disk is encrypted, for now I am making the decryption predicated to PCRs 7 and 14, so that the decryption will only fail when either SB state changes, or when shim certificates/hashes change. So far so good. Out of curiosity now, I am wondering: what would happen in case somebody boots the system from, e.g., a USB drive that contains a signed image? Even if the shim is the same version, I assume it will fail to unlock because the MOK will not contain my certificate? Should that certificate had been stolen and present, be enough to then unlock the disk? MOK is persisted in an EFI var, hence it doesn't matter what you boot from, the MOK db will be the same. Hence if that UKI on the usb drive is signed by some key that is in your MOK then this will just be accepted and get access to your keys. I am trying to assess if I should put in the mix PCR 4, so that I can keep track of the UKI image that gets loaded. Do you guys think this would be needed, or is overkill? If you use UKIs, bind to the signature for PCR 11. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] sd-boot setup and PCRs
Hi Andrei, In that case, could happen that a malicious actor that has had in the past access to the systemd-boot, shim, and the UKI, comes back with those 3 on a USB stick and boots the machine? Then it would indeed make sense to bind the LUKS key to PCR 4, this making it 4+7+14, so that the use of outdated UKI is not possible. Thank you! Felix On 2023-06-19 14:04, Andrei Borzenkov wrote: On 19.06.2023 10:19, Felix Rubio wrote: "Signed by whom?" - Signed by an actor trusted by Secure Boot, either at the platform level, or by any of the Shim contributors (I have not checked yet if it comes with a list of certificates, or only contains the one I enrolled) "What is \"your certificate\"?" - The one I generated and enrolled into MOK. In this case PCR 14 will not change. PCR 4 will include measurement of the binary loaded by shim. So if you place the same version of systemd-boot binary on USB it is up to the systemd-boot. The shim readme states that PCR 4 will be extended with "the hash of any binary for which Verify is called through the shim_lock protocol". So as long as systemd-boot calls shim to verify UKI you need the same UKI binary to unlock encrypted device. Which is not much different from simply booting from hard disk. I am not familiar with details of UKI implementation, but if it is possible to override kernel command line, you can trivially boot into /bin/sh unless you also bind LUKS key to the PCR 12 (or whatever is used to measure kernel parameters). Regards! Felix On 2023-06-19 06:26, Andrei Borzenkov wrote: On 18.06.2023 21:56, Felix Rubio wrote: Hi everybody, After some days offline, today I have gone through the emails exchanged a couple of weeks ago and agreed: UKI is the way to go. Last time I checked about it I read about possible problems related to when some modules would be loaded and so, but I see that my knowledge was outdated. This said, right now my setup looks like: SecureBoot is enabled, I am using Shim, Systemd-Boot as shim's second stage, and a UKI. As the disk is encrypted, for now I am making the decryption predicated to PCRs 7 and 14, so that the decryption will only fail when either SB state changes, or when shim certificates/hashes change. So far so good. Out of curiosity now, I am wondering: what would happen in case somebody boots the system from, e.g., a USB drive that contains a signed image? Signed by whom? Even if the shim is the same version, I assume it will fail to unlock because the MOK will not contain my certificate? What is "your certificate"? Should that certificate had been stolen and present, be enough to then unlock the disk? I am trying to assess if I should put in the mix PCR 4, so that I can keep track of the UKI image that gets loaded. Do you guys think this would be needed, or is overkill? Regards, Felix
Re: [systemd-devel] sd-boot setup and PCRs
"Signed by whom?" - Signed by an actor trusted by Secure Boot, either at the platform level, or by any of the Shim contributors (I have not checked yet if it comes with a list of certificates, or only contains the one I enrolled) "What is \"your certificate\"?" - The one I generated and enrolled into MOK. Regards! Felix On 2023-06-19 06:26, Andrei Borzenkov wrote: On 18.06.2023 21:56, Felix Rubio wrote: Hi everybody, After some days offline, today I have gone through the emails exchanged a couple of weeks ago and agreed: UKI is the way to go. Last time I checked about it I read about possible problems related to when some modules would be loaded and so, but I see that my knowledge was outdated. This said, right now my setup looks like: SecureBoot is enabled, I am using Shim, Systemd-Boot as shim's second stage, and a UKI. As the disk is encrypted, for now I am making the decryption predicated to PCRs 7 and 14, so that the decryption will only fail when either SB state changes, or when shim certificates/hashes change. So far so good. Out of curiosity now, I am wondering: what would happen in case somebody boots the system from, e.g., a USB drive that contains a signed image? Signed by whom? Even if the shim is the same version, I assume it will fail to unlock because the MOK will not contain my certificate? What is "your certificate"? Should that certificate had been stolen and present, be enough to then unlock the disk? I am trying to assess if I should put in the mix PCR 4, so that I can keep track of the UKI image that gets loaded. Do you guys think this would be needed, or is overkill? Regards, Felix
[systemd-devel] sd-boot setup and PCRs
Hi everybody, After some days offline, today I have gone through the emails exchanged a couple of weeks ago and agreed: UKI is the way to go. Last time I checked about it I read about possible problems related to when some modules would be loaded and so, but I see that my knowledge was outdated. This said, right now my setup looks like: SecureBoot is enabled, I am using Shim, Systemd-Boot as shim's second stage, and a UKI. As the disk is encrypted, for now I am making the decryption predicated to PCRs 7 and 14, so that the decryption will only fail when either SB state changes, or when shim certificates/hashes change. So far so good. Out of curiosity now, I am wondering: what would happen in case somebody boots the system from, e.g., a USB drive that contains a signed image? Even if the shim is the same version, I assume it will fail to unlock because the MOK will not contain my certificate? Should that certificate had been stolen and present, be enough to then unlock the disk? I am trying to assess if I should put in the mix PCR 4, so that I can keep track of the UKI image that gets loaded. Do you guys think this would be needed, or is overkill? Regards, Felix
Re: [systemd-devel] why systemd-boot (seems as everyone else) does not check the signatures of initramfs?
Just to close this off, because you guys have spend time in helping me navigate through this: Finally I decided to go for FDE based on the TPM. Then, most of my concerns where addressed by using PCRs 0,1,7 and 9, so that initramfs gets also measured. This allows me to keep a separate boot partition, and to not get involved yet with UKI. Now I am trying to work out a way to smooth the case when after a kernel / modules update the TPM state changes and will not unlock automatically... but this for another day, I guess :-) Thank you very much for you help! -- Felix Rubio "Don't believe what you're told. Double check." On 2023-05-27 08:31, Felix Rubio wrote: Hi Lennart, I remember having read some time ago that UKI could pose problems with early-boot modules provided by vendors and so. But... let's give it a try! Then, the process should be: 1. Install a version of shim signed with MS keys. 2. Generate the UKI 3. rename the UKI image to grubx64.efi so that it gets picked up by shim As a side: the ESP partition is bit small. Do you think if I introduce systemd-boot I could load the UKI being stored from /boot? In that case this would be like 1. Install a version of shim signed with MS keys. 2. Install systemd-boot as grubx64.efi so that it gets picked up by shim 3. Generate the UKI to /boot/ I will give it a try... and see how it goes. Regards! -- Felix Rubio "Don't believe what you're told. Double check." On 2023-05-25 10:26, Lennart Poettering wrote: On Mi, 24.05.23 19:01, Felix Rubio (fe...@kngnt.org) wrote: Hi Lennart, "Sorry, but GPG is a no-go. Not in 2023." Yes, I understand that. What I am trying to get is a simple way to verify that the initramfs has not been tampered with. UKI comes with its own challenges, using encryption tied to a measured boot looks overkill, and I fully agree in which adding an authentication layer is not desirable. I am not sure what "challenges" you specifically have in mind, but a UKI with an initrd in a PE envelope (i.e. the "add-on" concept I mentioned), then you should be pretty close to current behaviour, no? Then... what alternatives are available for just performing verification of the initramfs? I was giving a look at IMA now, so this could be sorted with a policy... but I think this is not supported in sd-boot. IMA verifies files after the kernel is up, not before. It's not suitable for validating initrds. Anway, you should really ask yourself what cryptographic key you want to authenticate against. Local or vendor one, and where shall it be stored. That dictates your choices more than anything else. In the case I wrap the initramfs on a PE envelope, as you suggested, when then its signature be validated automatically? when it gets loaded? Because, if so... this would work enough for this use case. In the "add-on" module for UKIs I mentioned the validation of both the UKI and the add-ons are done via regular UEFI SecureBoot or via shim. Both UKIs and add-ons are just PE files after all that thus can be verified that way. Because the files can be authenticated via shim you get MOK and so on. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] why systemd-boot (seems as everyone else) does not check the signatures of initramfs?
Hi everybody, Continuing the work/learning path I started last week, I have had a development: Still with shim loading systemd-boot, which can read the kernel and initramfs from XBOOTLDR partition, I have introduced LUKS to encrypt the root partition (XBOOTLDR is not encrypted). Originally I was planning to move from this to UKI so that I can make sure that both kernel and initramfs are checked before booting, but today I have considered a different course of action: Should I use the TPM to store a key to decrypt the disk like this: systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=0+1+7+9 Then, by using PCR9 the initrd would be checked before allowing the boot sequence to continue. By doing this, then, I do not have to switch to UKI until I have learned more about it. Do you guys think this reasoning is flawed? Thank you, --- Felix Rubio "Don't believe what you're told. Double check." On 2023-05-25 10:26, Lennart Poettering wrote: On Mi, 24.05.23 19:01, Felix Rubio (fe...@kngnt.org) wrote: Hi Lennart, "Sorry, but GPG is a no-go. Not in 2023." Yes, I understand that. What I am trying to get is a simple way to verify that the initramfs has not been tampered with. UKI comes with its own challenges, using encryption tied to a measured boot looks overkill, and I fully agree in which adding an authentication layer is not desirable. I am not sure what "challenges" you specifically have in mind, but a UKI with an initrd in a PE envelope (i.e. the "add-on" concept I mentioned), then you should be pretty close to current behaviour, no? Then... what alternatives are available for just performing verification of the initramfs? I was giving a look at IMA now, so this could be sorted with a policy... but I think this is not supported in sd-boot. IMA verifies files after the kernel is up, not before. It's not suitable for validating initrds. Anway, you should really ask yourself what cryptographic key you want to authenticate against. Local or vendor one, and where shall it be stored. That dictates your choices more than anything else. In the case I wrap the initramfs on a PE envelope, as you suggested, when then its signature be validated automatically? when it gets loaded? Because, if so... this would work enough for this use case. In the "add-on" module for UKIs I mentioned the validation of both the UKI and the add-ons are done via regular UEFI SecureBoot or via shim. Both UKIs and add-ons are just PE files after all that thus can be verified that way. Because the files can be authenticated via shim you get MOK and so on. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] why systemd-boot (seems as everyone else) does not check the signatures of initramfs?
Hi Lennart, I remember having read some time ago that UKI could pose problems with early-boot modules provided by vendors and so. But... let's give it a try! Then, the process should be: 1. Install a version of shim signed with MS keys. 2. Generate the UKI 3. rename the UKI image to grubx64.efi so that it gets picked up by shim As a side: the ESP partition is bit small. Do you think if I introduce systemd-boot I could load the UKI being stored from /boot? In that case this would be like 1. Install a version of shim signed with MS keys. 2. Install systemd-boot as grubx64.efi so that it gets picked up by shim 3. Generate the UKI to /boot/ I will give it a try... and see how it goes. Regards! -- Felix Rubio "Don't believe what you're told. Double check." On 2023-05-25 10:26, Lennart Poettering wrote: On Mi, 24.05.23 19:01, Felix Rubio (fe...@kngnt.org) wrote: Hi Lennart, "Sorry, but GPG is a no-go. Not in 2023." Yes, I understand that. What I am trying to get is a simple way to verify that the initramfs has not been tampered with. UKI comes with its own challenges, using encryption tied to a measured boot looks overkill, and I fully agree in which adding an authentication layer is not desirable. I am not sure what "challenges" you specifically have in mind, but a UKI with an initrd in a PE envelope (i.e. the "add-on" concept I mentioned), then you should be pretty close to current behaviour, no? Then... what alternatives are available for just performing verification of the initramfs? I was giving a look at IMA now, so this could be sorted with a policy... but I think this is not supported in sd-boot. IMA verifies files after the kernel is up, not before. It's not suitable for validating initrds. Anway, you should really ask yourself what cryptographic key you want to authenticate against. Local or vendor one, and where shall it be stored. That dictates your choices more than anything else. In the case I wrap the initramfs on a PE envelope, as you suggested, when then its signature be validated automatically? when it gets loaded? Because, if so... this would work enough for this use case. In the "add-on" module for UKIs I mentioned the validation of both the UKI and the add-ons are done via regular UEFI SecureBoot or via shim. Both UKIs and add-ons are just PE files after all that thus can be verified that way. Because the files can be authenticated via shim you get MOK and so on. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] why systemd-boot (seems as everyone else) does not check the signatures of initramfs?
Hi Lennart, "Sorry, but GPG is a no-go. Not in 2023." Yes, I understand that. What I am trying to get is a simple way to verify that the initramfs has not been tampered with. UKI comes with its own challenges, using encryption tied to a measured boot looks overkill, and I fully agree in which adding an authentication layer is not desirable. Then... what alternatives are available for just performing verification of the initramfs? I was giving a look at IMA now, so this could be sorted with a policy... but I think this is not supported in sd-boot. In the case I wrap the initramfs on a PE envelope, as you suggested, when then its signature be validated automatically? when it gets loaded? Because, if so... this would work enough for this use case. Thank you --- Felix Rubio "Don't believe what you're told. Double check." On 2023-05-24 18:11, Lennart Poettering wrote: On Mi, 24.05.23 16:20, Felix Rubio (fe...@kngnt.org) wrote: Hi Andrei, Lennart @Andrei: Do you think, then, that the same private key used for SecureBoot could be used for GPG signing the initramfs? That would be cool, as the whole boot signing infrastructure would still depend on a single entity. @Lennart: I was thinking in using a private key for which I'd enroll the certificate in MOK (I mean, just following the standard use case for MOK). Without having much idea about the code base of systemd-boot, I am willing to give it a try (to a GPG with private key from SB) provided you think is something the community might benefit from. What are your thoughts? Sorry, but GPG is a no-go. Not in 2023. But also I am not sure I understand what are you trying to do? Note that shim only authenticates PE binaries, hence you'd have to wrap your initrd in a PE binary anyway to validate an initrd against MOK. And we really don#t want to add another layer of authentication in sd-boot, let's leave that in uefi sb firmware + shim. i.e. we expressly don#t want to embedd a crypto stack like grub. And even if we could we don't get access to MOK iirc, shim makes that impossible for later boot components. If you wrap your initrd in a PE envelope this is pretty much exactly what UKIs are. – Also note that there's currently a PR pending that allows wrapping kernel command lines in separate PE files which can be read by a UKI, a concept we call "add-on", which would we could extend to initrds too i guess, see https://github.com/systemd/systemd/pull/27358 Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] why systemd-boot (seems as everyone else) does not check the signatures of initramfs?
Hi Andrei, Lennart @Andrei: Do you think, then, that the same private key used for SecureBoot could be used for GPG signing the initramfs? That would be cool, as the whole boot signing infrastructure would still depend on a single entity. @Lennart: I was thinking in using a private key for which I'd enroll the certificate in MOK (I mean, just following the standard use case for MOK). Without having much idea about the code base of systemd-boot, I am willing to give it a try (to a GPG with private key from SB) provided you think is something the community might benefit from. What are your thoughts? Regards, -- Felix Rubio "Don't believe what you're told. Double check." On 2023-05-24 14:35, Lennart Poettering wrote: On Mi, 24.05.23 12:22, Felix Rubio (fe...@kngnt.org) wrote: I agree that having a measured boot, that decrypts the system is a better solution... but this is, correct me if wrong, still very green: There are some approaches supported, but none of them seems to be structural: they rely on the existence of a TPM, introduce additional dependencies on the update process (when the kernel/initramfs changes the previous measurement will not be correct anymore and needs to be updated), etc. On the other hand UKI comes with its own challenges, and also forces the admin to rebuild the UKI any time there is an update. I feel there should be some middle point in which we do not have to rely on a TPM and a fully measured system, but we can still make sure that the initramfs is trusted. The question, then, is: Is this something that could be supported in systemd-boot, or this is something that is considered to be just out of scope? As in the other mail: Which key do you intend to use for validation? Note that in systemd git main there's already support for generating UKIs dynamically when a kernel RPM/DEB is installed (as long as the "kernel-install" infra is in use). It can be signed with a local key, that can be enrolled with MOK. With that we make it reasonably easy to run a setup with a locally signed initrd – but it means that you'll get a MOK prompt during at least one boot. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] why systemd-boot (seems as everyone else) does not check the signatures of initramfs?
Hi Andrei, Thank you for correcting my statement about Grub2, I did not know that. I agree that having a measured boot, that decrypts the system is a better solution... but this is, correct me if wrong, still very green: There are some approaches supported, but none of them seems to be structural: they rely on the existence of a TPM, introduce additional dependencies on the update process (when the kernel/initramfs changes the previous measurement will not be correct anymore and needs to be updated), etc. On the other hand UKI comes with its own challenges, and also forces the admin to rebuild the UKI any time there is an update. I feel there should be some middle point in which we do not have to rely on a TPM and a fully measured system, but we can still make sure that the initramfs is trusted. The question, then, is: Is this something that could be supported in systemd-boot, or this is something that is considered to be just out of scope? Thank you --- Felix Rubio "Don't believe what you're told. Double check." On 2023-05-23 21:32, Andrei Borzenkov wrote: On 23.05.2023 21:54, Felix Rubio wrote: Hi everybody, I am trying to understand something, and after looking around I have not found any explicit answer. Maybe somebody in this list can shed some light on the matter? I have a laptop in which I am setting up the boot process through systemd-boot, and this works. Now, I'd like to give a try to enable Secure Boot so that the whole boot sequence is protected against tampering. As I am still learning about the technology, I prefer to land on the use of shim/MOK. For what I have read, the sequence should be: 1. Install a version of shim signed with MS keys. 2. On that same folder copy systemd-bootx64.efi, renamed to grubx64.efi (as shim seems to work only with Grub as 2nd stage loader). 3. Sign the kernel with the key for which the certificate has been enrolled in MOK. 4. Reboot, enroll the keys and... voila. So far, so good... until we hit the initramfs wall: the efi's and kernel signatures are verified, but not that of the initramfs. I have seen that grub2 does not do it (it relies in GPG signatures, in which seems to be a workaround), and I have not found any place stating that systemd-boot GPG is independent alternative method of verifying files and most certainly not a workaround (it was implemented in grub2 long before Secure Boot support). does it. I have seen however, some steering towards the use of UKI... but this comes with its own problems about out-of-tree kernel modules and so. So, the question is: why the kernel image gets verified but not the initramfs? Is this mandated by some standard, or is an engineering decision? Kernel image has verifiable origin (it is signed by the same entity that provides your distribution). It is static and does not change on end user system which makes it possible to sign by maintainers of distribution by a secret key that is hopefully kept secret. initrd is volatile, it is usually generated on the same system where it should be verified which means the key to sign it must be kept on the same system as well. Which makes it more probable that secret key will be leaked if system is compromised. And leaked secret key allows installing an arbitrary malware as part of initrd. Measured boot does not have this problem. If you encrypt your root and only allow decrypting if initrd (and kernel and any other data used during boot) has known content then initrd will be implicitly verified and if it is changed system simply fails to boot. This does not require any key management or storing any persistent secret on end system. Downside is that it requires TPM (or some other tamper resistant way to store hashes) so not universally applicable. Thank you very much!
[systemd-devel] why systemd-boot (seems as everyone else) does not check the signatures of initramfs?
Hi everybody, I am trying to understand something, and after looking around I have not found any explicit answer. Maybe somebody in this list can shed some light on the matter? I have a laptop in which I am setting up the boot process through systemd-boot, and this works. Now, I'd like to give a try to enable Secure Boot so that the whole boot sequence is protected against tampering. As I am still learning about the technology, I prefer to land on the use of shim/MOK. For what I have read, the sequence should be: 1. Install a version of shim signed with MS keys. 2. On that same folder copy systemd-bootx64.efi, renamed to grubx64.efi (as shim seems to work only with Grub as 2nd stage loader). 3. Sign the kernel with the key for which the certificate has been enrolled in MOK. 4. Reboot, enroll the keys and... voila. So far, so good... until we hit the initramfs wall: the efi's and kernel signatures are verified, but not that of the initramfs. I have seen that grub2 does not do it (it relies in GPG signatures, in which seems to be a workaround), and I have not found any place stating that systemd-boot does it. I have seen however, some steering towards the use of UKI... but this comes with its own problems about out-of-tree kernel modules and so. So, the question is: why the kernel image gets verified but not the initramfs? Is this mandated by some standard, or is an engineering decision? Thank you very much! -- Felix Rubio "Don't believe what you're told. Double check."
Re: [systemd-devel] setting up systemd-boot with separate EFI and boot partitions
Thank you Lennart. When I separated the /boot from /boot/efi I formatted /boot partition with ext2. After reading your answer I reformatted it to FAT and... all works. Regards! --- Felix Rubio "Don't believe what you're told. Double check." On 2023-05-23 10:51, Lennart Poettering wrote: On Mo, 22.05.23 14:26, Felix Rubio (fe...@kngnt.org) wrote: I have installed arch linux recently, with systemd-boot as boot manager and the EFI partition mounted on /boot. I am wondering how can I mount the EFI partition on /boot/efi, while vmlinuz-linux and initramf remain in /boot? Currently in my /boot/loader/entries/arch.conf I have the following: title Arch Linux linux /vmlinuz-linux initrd /amd-ucode.img initrd /initramfs-linux.img options root=PARTUUID= rw On this setup, I guess amd-ucode.img must remain in /boot/efi, but how can I specify that vmlinuz-linux and initramfs-linux.img are in another partition, if possible at all? sd-boot is an EFI program that uses EFI APIs to access file systems, hence it only generally supports FAT. It will look in the ESP as well as in XBOOTLDR. Thus is you mark your /boot/ partition as XBOOTLDR and format it is vfat it should just work. Lennart -- Lennart Poettering, Berlin
[systemd-devel] setting up systemd-boot with separate EFI and boot partitions
I have installed arch linux recently, with systemd-boot as boot manager and the EFI partition mounted on /boot. I am wondering how can I mount the EFI partition on /boot/efi, while vmlinuz-linux and initramf remain in /boot? Currently in my /boot/loader/entries/arch.conf I have the following: title Arch Linux linux /vmlinuz-linux initrd /amd-ucode.img initrd /initramfs-linux.img options root=PARTUUID= rw On this setup, I guess amd-ucode.img must remain in /boot/efi, but how can I specify that vmlinuz-linux and initramfs-linux.img are in another partition, if possible at all? Regards, -- Felix Rubio "Don't believe what you're told. Double check."
Re: [systemd-devel] "[Match]" section in systemd.link file doesn't match interface
Thank you for your help! I've found my problem and it was way simpler than I thought. The systemd.link manpage mentions: "The first (in lexical order) of the link files that matches a given device is applied. Note that a default file 99-default.link is shipped by the system. Any user-supplied .link should hence have a lexically earlier name to be considered at all." My .link file wasn't considered because its file name came lexically after '99-default.link'. I'm now happily using the mac address for matching. I use `udevadm test-builtin net_setup_link /sys/class/net/ens19` for applying a changed .link file to my link. On Tue, Mar 3, 2020, 10:59 Mantas Mikulėnas wrote: > > > On Mon, Mar 2, 2020, 16:59 Felix <mailto:systemd-de...@fj.hamme.net>> wrote: > > Hello everybody, > > I'm failing to set an alias for a link using systemd-networkd. Am I > doing something wrong? Is this a bug? > > > I'm on this systemd version: > systemd 244 (244.3-1~bpo10+1) > +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP > +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS > +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid > > This runs on a Debian Buster inside a virtual machine hosted on a > proxmox 6.1 server, if that matters. > > I'm trying to set an alias for a link using systemd-networkd, > following > this documentation: > https://www.freedesktop.org/software/systemd/man/systemd.link.html#Alias= > . > I put my file in /etc/systemd/network/, as > -rw-r--r-- 1 root root 56 Mär 2 14:06 ens19.link > with this content: > > ``` > [Match] > Path=/sys/class/net/ens19 > > > The Path= setting is documented to match against the ID_PATH udev > property, not against the list of sysfs paths. (For example udevadm > shows "pci-:01:00.0" on my machine.) > > > > [Link] > Alias=myalias > ``` > > I also tried to replace `Path=/sys/class/net/ens19` with > `MACAddress=be:19:32:ed:c0:61` and `OriginalName=ens19`. > > > OriginalName matches the kernel-assigned name (udev property > 'INTERFACE'), which is always either eth# or wlan# or usb# or similar. > > Names such as ens# or eno# are not original – the interfaces are > renamed by udev, and this actually happens *after* applying .link > files (as the .link files specify which naming policy to use in the > first place.) > > > > > After `systemctl restart systemd-networkd` or even rebooting the alias > is still not set: > > > > How can I set the link alias using systemd-networkd? > > > .link files are not applied by networkd – they're applied by udev. > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] "[Match]" section in systemd.link file doesn't match interface
Hello everybody, I'm failing to set an alias for a link using systemd-networkd. Am I doing something wrong? Is this a bug? I'm on this systemd version: systemd 244 (244.3-1~bpo10+1) +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid This runs on a Debian Buster inside a virtual machine hosted on a proxmox 6.1 server, if that matters. I'm trying to set an alias for a link using systemd-networkd, following this documentation: https://www.freedesktop.org/software/systemd/man/systemd.link.html#Alias= . I put my file in /etc/systemd/network/, as -rw-r--r-- 1 root root 56 Mär 2 14:06 ens19.link with this content: ``` [Match] Path=/sys/class/net/ens19 [Link] Alias=myalias ``` I also tried to replace `Path=/sys/class/net/ens19` with `MACAddress=be:19:32:ed:c0:61` and `OriginalName=ens19`. After `systemctl restart systemd-networkd` or even rebooting the alias is still not set: ``` 3: ens19: mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether be:19:32:ed:c0:61 brd ff:ff:ff:ff:ff:ff ``` I expected/want to see this: ``` 3: ens19: mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether be:19:32:ed:c0:61 brd ff:ff:ff:ff:ff:ff alias myalias ``` `networkctl status ens19` doesn't show my .link file: `Link File: /usr/lib/systemd/network/99-default.link`. `udevadm test-builtin net_setup_link /sys/class/net/ens19` prints this: ``` Load module index Parsed configuration file /etc/systemd/network/ens19.link Parsed configuration file /usr/lib/systemd/network/99-default.link Created link configuration context. ID_NET_DRIVER=virtio_net Config file /usr/lib/systemd/network/99-default.link applies to device ens19 link_config: autonegotiation is unset or enabled, the speed and duplex are not writable. Using default interface naming scheme 'v240'. ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link Unload module index Unloaded link configuration context. ``` How can I set the link alias using systemd-networkd? Thanks, Felix ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] ntpd stop job delays reboot up to 90s
Full message waiting to reboot: A stop job is running for NTP server Daemon (1min nns / 1min 30s). This occurs on various installations here at various times, whether rebooting or shutting down, most never, others routinely, yet not every time, or not a full 90s delay. Just tonight it's been happening on openSUSE 42.3beta with systemd-228. How is it that a shutdown delay like this can occur when there was no problem with the startup? # journalctl -b -1 | grep ntp Failed to look up boot -1: No such boot ID in journal # journalctl -b | grep ntp Jun 27 04:50:53 hpg33 kernel: Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes) Jun 27 04:51:22 hpg33 ntpd[1177]: ntpd 4.2.8p10@1.3728-o Tue Jun 13 18:04:39 UTC 2017 (1): Starting Jun 27 04:51:22 hpg33 ntpd[1177]: Command line: /usr/sbin/ntpd -p /var/run/ntp/ntpd.pid -g -u ntp:ntp -c /etc/ntp.conf Jun 27 04:51:22 hpg33 ntpd[1181]: proto: precision = 0.060 usec (-24) Jun 27 04:51:22 hpg33 ntpd[1181]: switching logging to file /var/log/ntp Jun 27 04:51:22 hpg33 start-ntpd[1166]: Starting network time protocol daemon (NTPD) -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] multi-user.target -> rescue.target and back to multi-user issues
Andrei Borzenkov composed on 2016-06-22 06:39 (UTC+0300): > TBH, switch between run-time levels never really worked in the past, > before systemd, so at least there is no regression :) This is news to me. I was doing this for years. What brokenness was I not encountering? > Well, getty's are spawned dynamically on demand Not here. I found the wait for them to appear when booting to multi-user.target routinely frustrating, so I have a script to run post-installation that creates e.g.: /etc/systemd/system/getty.target.wants # ls -gG total 0 lrwxrwxrwx 1 53 Dec 27 01:54 getty@tty1.service -> ../../../../usr/lib/systemd/system/getty@tty1.service lrwxrwxrwx 1 38 Dec 26 19:46 .getty@tty1.service.01 -> /usr/lib/systemd/system/getty@.service lrwxrwxrwx 1 49 Dec 27 01:54 getty@tty2.service -> ../../../../usr/lib/systemd/system/getty@.service lrwxrwxrwx 1 49 Dec 27 01:54 getty@tty3.service -> ../../../../usr/lib/systemd/system/getty@.service lrwxrwxrwx 1 49 Dec 27 01:54 getty@tty4.service -> ../../../../usr/lib/systemd/system/getty@.service lrwxrwxrwx 1 49 Dec 27 01:54 getty@tty5.service -> ../../../../usr/lib/systemd/system/getty@.service lrwxrwxrwx 1 49 Dec 27 01:54 getty@tty6.service -> ../../../../usr/lib/systemd/system/getty@.service > ...switching > between multi-user and graphical would kill them. That's probably not > what users expect. +1 > Adding Conflicts=rescue.target may help to workaround this specific case -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] shutdown delayed by failure to start a service
Lennart Poettering composed on 2016-05-30 17:37 (UTC+0200): > Felix Miata wrote: >> Lennart Poettering composed on 2016-05-29 18:40 (UTC+0200): >> >Felix Miata wrote: >> >>The message I see is equivalent in form as during boot, e.g. when a >> >>filesystem not noauto in fstab is to be mounted but cannot be found, so a >> >>delay of typically 90sec, but sometimes much longer, occurs. Mount >> >>specification mistyped or a subsequently changed volume label, or similarly >> >>a change of filesystem UUID should be an easy enough way to observe what >> >>I've not infrequently seen, though the cause(s) of the more irritating >> >>shutdown delays isn't coming to mind ATM. If this was something I had a >> >>reliable recreate scenario for I'd have filed a bug somewhere by now, >> >>likely >> >>at least a year ago. >> >Well, we put a timeout of 90s on *everything* systemd starts or >> >stops. Hence, saying that you see some 90s timeout just means >> >*something* isn't finishing as quickly as it should, with exactly zero >> >information about what that something might be... >> Now that I know this isn't something familiar to you, I'll be on the watch >> to collect specifics to report next time I encounter it. Will there be a >> specific journalctl option to use at that time, or will -b do it? > "journalctl -b" shows you everything that happened during your current > boot. If you are trying to find log data generated during shutdown > this probably won't give you what you want, as you probably want the > data from the previous boot, not the current one, i.e. "journalctl > -b-1" is what you want... Caught one by journal. I had forgotten to edit fstab after some partition shuffling. Old/unchanged fstab (excerpt): LABEL=2st17f24 /disks/f24 ext4noatime,nofail 1 2 # blkid /dev/sda17 /dev/sda21 /dev/sda17: LABEL="2st17f25" UUID="bcb777c0-2283-41f8-a345-30356d7f253e" TYPE="ext4" PTTYPE="dos" PARTUUID="0051ea28-11" /dev/sda21: LABEL="2st21f24" UUID="98b1d584-6a0f-4b02-8dd4-e47f11ab994a" TYPE="ext4" PTTYPE="dos" PARTUUID="0051ea28-15" Subsequently repaired fstab (excerpt): LABEL=2st17f25 /disks/f25 ext4noatime,nofail 0 0 LABEL=2st21f24 /disks/f24 ext4noatime,nofail 0 0 # uname -a Linux g5eas 3.16.7-35-desktop #1 SMP PREEMPT Sun Feb 7 17:32:21 UTC 2016 (832c776) x86_64 x86_64 x86_64 GNU/Linux # zypper se -si | egrep 'systemd|udev' i | libgudev-1_0-0 | package | 210.1463730809.e37fc98-25.40.2 | x86_64 | Update i | libudev1 | package | 210.1463730809.e37fc98-25.40.2 | x86_64 | Update i | python-pyudev| package | 0.16.1-9.1.5 | noarch | OSS i | systemd | package | 210.1463730809.e37fc98-25.40.2 | x86_64 | Update i | systemd-bash-completion | package | 210.1463730809.e37fc98-25.40.2 | noarch | Update i | systemd-logger | package | 210.1463730809.e37fc98-25.40.2 | x86_64 | Update i | systemd-presets-branding-openSUSE| package | 0.3.0-12.7.1 | noarch | Update i | systemd-sysvinit | package | 210.1463730809.e37fc98-25.40.2 | x86_64 | Update i | udev | package | 210.1463730809.e37fc98-25.40.2 | x86_64 | Update i | util-linux-systemd | package | 2.25.1-20.1 | x86_64 | Update # journalctl -b -1 | tail -n55 Jun 14 22:14:21 g5eas systemd[1]: Stopping Apply Kernel Variables... Jun 14 22:14:21 g5eas systemd[1]: Stopped Apply Kernel Variables. Jun 14 22:14:21 g5eas systemd[1]: Stopping Setup Virtual Console... Jun 14 22:14:21 g5eas systemd[1]: Stopping Load Kernel Modules... Jun 14 22:14:21 g5eas systemd[1]: Stopped Load Kernel Modules. Jun 14 22:14:21 g5eas systemd[1]: Stopping Encrypted Volumes. Jun 14 22:14:21 g5eas systemd[1]: Stopped target Encrypted Volumes. Jun 14 22:14:21 g5eas systemd[1]: Stopping Swap. Jun 14 22:14:21 g5eas systemd[1]: Deactivating swap /dev/sda7... Jun 14 22:14:21 g5eas systemd[1]: Deactivating swap /dev/sda7... Jun 14 22:14:21 g5eas systemd[1]: Deactivating swap /dev/sda7... Jun 14 22:14:21 g5eas systemd[1]: Deactivating swap /dev/sda7... Jun 14 22:14:21 g5eas systemd[1]: Deactivating swap /dev/sda7... Jun 14 22:14:21 g5eas systemd[1]: Stopping Update UTMP about System Reboot/Shutdown... Jun 14 22:14:21 g5eas systemd[1]: Stopped Entropy Daemon based on the HAVEGE algorithm.
Re: [systemd-devel] shutdown delayed by failure to start a service
Lennart Poettering composed on 2016-05-30 17:37 (UTC+0200): > Felix Miata wrote: >> Lennart Poettering composed on 2016-05-29 18:40 (UTC+0200): >> >Felix Miata wrote: >> >>The message I see is equivalent in form as during boot, e.g. when a >> >>filesystem not noauto in fstab is to be mounted but cannot be found, so a >> >>delay of typically 90sec, but sometimes much longer, occurs. Mount >> >>specification mistyped or a subsequently changed volume label, or similarly >> >>a change of filesystem UUID should be an easy enough way to observe what >> >>I've not infrequently seen, though the cause(s) of the more irritating >> >>shutdown delays isn't coming to mind ATM. If this was something I had a >> >>reliable recreate scenario for I'd have filed a bug somewhere by now, >> >>likely >> >>at least a year ago. >> >Well, we put a timeout of 90s on *everything* systemd starts or >> >stops. Hence, saying that you see some 90s timeout just means >> >*something* isn't finishing as quickly as it should, with exactly zero >> >information about what that something might be... >> Now that I know this isn't something familiar to you, I'll be on the watch >> to collect specifics to report next time I encounter it. Will there be a >> specific journalctl option to use at that time, or will -b do it? > "journalctl -b" shows you everything that happened during your current > boot. If you are trying to find log data generated during shutdown > this probably won't give you what you want, as you probably want the > data from the previous boot, not the current one, i.e. "journalctl > -b-1" is what you want... Caught by journal: # blkid /dev/sda17 /dev/sda17: LABEL="2st17f25" UUID="bcb777c0-2283-41f8-a345-30356d7f253e" TYPE="ext4" PTTYPE="dos" PARTUUID="0051ea28-11" # uname -a Linux g5eas 3.16.7-35-desktop #1 SMP PREEMPT Sun Feb 7 17:32:21 UTC 2016 (832c776) x86_64 x86_64 x86_64 GNU/Linux # zypper se -si | egrep 'systemd|udev' i | libgudev-1_0-0 | package | 210.1463730809.e37fc98-25.40.2 | x86_64 | Update i | libudev1 | package | 210.1463730809.e37fc98-25.40.2 | x86_64 | Update i | python-pyudev| package | 0.16.1-9.1.5 | noarch | OSS i | systemd | package | 210.1463730809.e37fc98-25.40.2 | x86_64 | Update i | systemd-bash-completion | package | 210.1463730809.e37fc98-25.40.2 | noarch | Update i | systemd-logger | package | 210.1463730809.e37fc98-25.40.2 | x86_64 | Update i | systemd-presets-branding-openSUSE| package | 0.3.0-12.7.1 | noarch | Update i | systemd-sysvinit | package | 210.1463730809.e37fc98-25.40.2 | x86_64 | Update i | udev | package | 210.1463730809.e37fc98-25.40.2 | x86_64 | Update i | util-linux-systemd | package | 2.25.1-20.1 | x86_64 | Update # journalctl -b -1 | tail -n55 Jun 14 22:14:21 g5eas systemd[1]: Stopping Apply Kernel Variables... Jun 14 22:14:21 g5eas systemd[1]: Stopped Apply Kernel Variables. Jun 14 22:14:21 g5eas systemd[1]: Stopping Setup Virtual Console... Jun 14 22:14:21 g5eas systemd[1]: Stopping Load Kernel Modules... Jun 14 22:14:21 g5eas systemd[1]: Stopped Load Kernel Modules. Jun 14 22:14:21 g5eas systemd[1]: Stopping Encrypted Volumes. Jun 14 22:14:21 g5eas systemd[1]: Stopped target Encrypted Volumes. Jun 14 22:14:21 g5eas systemd[1]: Stopping Swap. Jun 14 22:14:21 g5eas systemd[1]: Deactivating swap /dev/sda7... Jun 14 22:14:21 g5eas systemd[1]: Deactivating swap /dev/sda7... Jun 14 22:14:21 g5eas systemd[1]: Deactivating swap /dev/sda7... Jun 14 22:14:21 g5eas systemd[1]: Deactivating swap /dev/sda7... Jun 14 22:14:21 g5eas systemd[1]: Deactivating swap /dev/sda7... Jun 14 22:14:21 g5eas systemd[1]: Stopping Update UTMP about System Reboot/Shutdown... Jun 14 22:14:21 g5eas systemd[1]: Stopped Entropy Daemon based on the HAVEGE algorithm. Jun 14 22:14:21 g5eas systemd[1]: Stopped LSB: Set default boot entry if called. Jun 14 22:14:21 g5eas systemd[1]: Stopping Load/Save Random Seed... Jun 14 22:14:21 g5eas haveged[483]: haveged: Stopping due to signal 15 Jun 14 22:14:21 g5eas haveged[483]: haveged starting up Jun 14 22:14:21 g5eas systemd[1]: Deactivated swap /dev/disk/by-path/pci-:00:1f.2-scsi-0:0:0:0-part7. Jun 14 22:14:21 g5eas systemd[1]: Deactivated swap /dev/disk/by-path/pci-:00:1f.2-ata-1.0-part7. Jun 14 22:14:21 g5eas systemd[1]: Deactivated swap
Re: [systemd-devel] Stretch systemd_230-1_amd64.deb systemctl set-default segfaults
Lennart Poettering composed on 2016-06-02 13:21 (UTC+0200): Felix Miata wrote: Anyone else notice this happening? Known problem? [ 848.647555] systemctl[666]: segfault at 0 ip 561573dc3c03 sp 7ffeddbff490 error 4 in systemctl[561573d51000+a3000] Please provide a proper backtrace. "coredumpctl" might help you. I can if you think it would be useful, but for now I think it reasonable to assume based upon https://github.com/systemd/systemd/issues/3339 that it would be of little use at best. Thanks to Evgeny for the bug report pointer! -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Stretch systemd_230-1_amd64.deb systemctl set-default segfaults
Anyone else notice this happening? Known problem? [ 848.647555] systemctl[666]: segfault at 0 ip 561573dc3c03 sp 7ffeddbff490 error 4 in systemctl[561573d51000+a3000] -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] shutdown delayed by failure to start a service
Lennart Poettering composed on 2016-05-29 18:40 (UTC+0200): Felix Miata wrote: The message I see is equivalent in form as during boot, e.g. when a filesystem not noauto in fstab is to be mounted but cannot be found, so a delay of typically 90sec, but sometimes much longer, occurs. Mount specification mistyped or a subsequently changed volume label, or similarly a change of filesystem UUID should be an easy enough way to observe what I've not infrequently seen, though the cause(s) of the more irritating shutdown delays isn't coming to mind ATM. If this was something I had a reliable recreate scenario for I'd have filed a bug somewhere by now, likely at least a year ago. Well, we put a timeout of 90s on *everything* systemd starts or stops. Hence, saying that you see some 90s timeout just means *something* isn't finishing as quickly as it should, with exactly zero information about what that something might be... Now that I know this isn't something familiar to you, I'll be on the watch to collect specifics to report next time I encounter it. Will there be a specific journalctl option to use at that time, or will -b do it? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] shutdown delayed by failure to start a service
Mantas Mikulėnas composed on 2016-05-27 20:05 (UTC+0300): Lennart Poettering wrote: Felix Miata wrote: Did this ever get fixed? IOW, sometimes a service will fail to start when a system is started, or later, after a session of updating, a previously operating service fails to restart, or a newly installed service fails to start, or a service is removed. Then at shutdown/reboot time, systemd pauses 90 seconds with a message about trying to *start* a service. I think I most often notice this when I try to hold down CAD after a normal shutdown/reboot order gets stuck or seemingly ignored. At such times I typically see an "endless" string of failing to save sound card state messages. I have never heard of something like this. And what you describe is not really how systemd works. At shutdown, we actually only shut down services, we don't start any. The message I see is equivalent in form as during boot, e.g. when a filesystem not noauto in fstab is to be mounted but cannot be found, so a delay of typically 90sec, but sometimes much longer, occurs. Mount specification mistyped or a subsequently changed volume label, or similarly a change of filesystem UUID should be an easy enough way to observe what I've not infrequently seen, though the cause(s) of the more irritating shutdown delays isn't coming to mind ATM. If this was something I had a reliable recreate scenario for I'd have filed a bug somewhere by now, likely at least a year ago. Not when a distro installs some junk with DefaultDependencies=no & WantedBy=shutdown.target... So, you're saying this is something you're familiar with? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] shutdown delayed by failure to start a service
Did this ever get fixed? IOW, sometimes a service will fail to start when a system is started, or later, after a session of updating, a previously operating service fails to restart, or a newly installed service fails to start, or a service is removed. Then at shutdown/reboot time, systemd pauses 90 seconds with a message about trying to *start* a service. I think I most often notice this when I try to hold down CAD after a normal shutdown/reboot order gets stuck or seemingly ignored. At such times I typically see an "endless" string of failing to save sound card state messages. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] resolved: use special nameservers for some domains
Am 11.05.2016 um 21:04 schrieb Lennart Poettering: > However, this all implies that there's an interface for each of these > DNS server "routes"... if you only have a single interface, and want > to route on that single interface to different DNS servers then, nope, > we don't support that currently. But I think it would be OK to add > this. Is there a good way to record that feature wish which increases the chance that someone will work on that? If not I just hope this thread will be remembered just in case a resolved developer has a sudden attack of boredom :-) Thank you very much for your workaround suggestion, Felix ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] resolved: use special nameservers for some domains
I'd like to know if resolved can redirect DNS queries for certain domains to different name servers? rationale: I want to query a few DNS black lists but my provider's name servers have been blocked because they send too many queries to the BL. However my intended usage qualifies for the "free" tier. Assuming this is not possible at the moment should I file a github issue? Or is such a feature considered "feature creep" so it won't be added to resolved "ever"? fs PS: I know that I can use dnsmasq and other software. However resolved is quite well suited for my limited use cases so if possible I'd like to keep resolved without installing extra stuff. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cannot mount anything after recovering and redoing boot mbr
c...@endlessnow.com composed on 2015-07-27 16:35 (UTC-0500): A root is getting mounted and I figure it's the same but will double check (away from system right now). Would some kind of root getting mounted at startup and being different from root in /etc/fstab make some sort of difference? Would that cause manual mounts of old style nonportable dev shortnames (e.g. mount /dev/sda7 /mnt) to fail with the error of busy when done at the command line? (from emergency shell). I may just back the data off and do a reinstall. So if anyone can chime in with other things to try, please do it now before I have to blow it all away. As for things to try I would reduce fstab to one line for /, then try booting normally. I've seen dracut at various times hard code swap or other partition UUIDs that become out of sync with what's on the HD following updates or restoring from backup, e.g.: http://bugzilla.opensuse.org/show_bug.cgi?id=936964 cf. http://lists.opensuse.org/opensuse/2015-07/msg00080.html https://bugzilla.redhat.com/show_bug.cgi?id=1187007 -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] CAD often useless
Lennart Poettering composed on 2015-04-16 12:16 (UTC+0200): Felix Miata wrote: Zbigniew JÄdrzejewski-Szmek composed on 2015-04-15 18:11 (UTC): On Wed, Apr 15, 2015 at 13:31:38 -0400, Felix Miata wrote: This isn't the first time or the only system. This particular one is an old Athlon booted to F22 just updated last night. In order to try some follow-up on a bug, I booted with drm.debug=14 log_buf_len=16M on cmdline. Somehow after exiting IceWM back into KDM, the system quit responding. After some waiting, I was switched to a tty full of systemd-journal failed to write readonly filesystem messages. How the system got / into a readonly state I have no idea, but my complaint is $SUBJECT, the time it takes, or the complete failure, trying to reboot when there is a problem, often seeing failed to store sound card state or failing boot *start* jobs. Why has rebooting to get out of trouble gotten to be so nearly impossible? Did you try to press CAD more than 7 times within 2s? This should result in immedate reboot. I don't normally count, but what I usually do is just hold the three keys down until the reboot process becomes apparent. My fingers and keyboards are old. I just hold CAD down until reboot proceeds, or not. All that have repeat and delay configurable in BIOS are set to 20 cps 250 delay. Linux does not use the hardware typematic rate anymore, since about 10 years. It's irrelevant what you configure there. My systems are all multiboot. Most have floppy drives and will boot DOS. KDE I always set to same. But you are using IceWM you said. I only ever use IceWM to discover whether DE startup trouble is in Xorg or in K*. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] CAD often useless
Lennart Poettering composed on 2015-04-16 12:32 (UTC+0200): Felix Miata wrote: Needing again to CAD on yet another machine (kt88b this time, kt400 earlier), again encountering / going into RO state, I noticed this time the message Ctrl-Alt-Del was pressed more than 7 times within 2s, rebooting immediately. I remember having seen this on previous occasions to need CAD, but it's still on the screen now, several minutes later, with the NUM key's LED remaining responsive. IOW, it doesn't do either what it says, or what I wanted. This is on F22 with PAE kernel 4.0.0-1 and PATA storage only except for empty floppy drive. When you see this message, then systemd will not bother with shuttding down daemons cleanly anymore. However, it will still unmount all file systems and sync things do disk. It will also pass control back to the initrd, So if initrd is deleted or rebuilt for the running kernel, shut down normally is not possible? which might disassemble LVM if that is used. NA here. If things hang in that logic then this is either an issue with LVM/initrd, or with your driver/hw when we try to sync the disks. Definitely the disks in the two systems that triggered the thread... Given that your fs was remounted read-only (which the kernel does automatically if it notices something seriously wrong with the disk), my guess is that the disk syncing trips you up. In the latter of the two, I found the cheapie PS has flimsy connectors after subsequent POST couldn't find the disk. I pinched them all closed on and reconnected the one for the HD, and its trouble stopped. In the former, there was some problem with cabling as well, but I already forgot what. :-p -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] black screen on startx exit
Lennart Poettering composed on 2015-04-16 12:40 (UTC+0200): Felix Miata wrote: I asked the following on freedesktop list a month ago and got no response. As there was quite some time between this showing up in Fedora and Tumbleweed, and Tumbleweed only lately upgraded systemd from 210 to 219, it looks like systemd could be playing at least some part in this. I first noticed this last May on rv200 and filed a Redhat bug: https://bugzilla.redhat.com/show_bug.cgi?id=1096487 Later it happened with Nouveau NV11 and I updated that bug. Still later I noticed it happen on Cauldron on rv200: https://ml.mageia.org/l/arc/dev/2014-09/msg00218.html By last month it was happening in Tumbleweed on NV11. So this doesn't look like any problem specific to the distros, but I don't see any existing bug on bugs.freedesktop.org either. Could this be a problem in something else, systemd or pam maybe? I've not seen this on Intel as old as 845G? Would it actually be two bugs, one against Nouveau and another against Radeon? Has no one else here encountered this? I do no see how this is related to systemd in any way. I thought it possible. I don't understand what dependencies if any Xorg may have on systemd, and saw an apparent time connection between upgrade to 219 and problem appearance in Tumbleweed. Please ask the X11/drivers people for help, http://lists.x.org/archives/xorg/2015-March/057252.html got no response. A follow-up attempt is at http://lists.x.org/archives/xorg/2015-April/057314.html or even better your distro maintainers. That's what the links in my OP were about. The bugzilla.redhat.com bug has generated no response. The mageia-dev mailing list provided no useful response in both September and February. https://bugs.mageia.org/show_bug.cgi?id=15662 has generated no response as well. Only place left that makes sense to try is kernel, maybe KMS fault switching back from 1600x1200 to 1024x768? -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] black screen on startx exit
I asked the following on freedesktop list a month ago and got no response. As there was quite some time between this showing up in Fedora and Tumbleweed, and Tumbleweed only lately upgraded systemd from 210 to 219, it looks like systemd could be playing at least some part in this. I first noticed this last May on rv200 and filed a Redhat bug: https://bugzilla.redhat.com/show_bug.cgi?id=1096487 Later it happened with Nouveau NV11 and I updated that bug. Still later I noticed it happen on Cauldron on rv200: https://ml.mageia.org/l/arc/dev/2014-09/msg00218.html By last month it was happening in Tumbleweed on NV11. So this doesn't look like any problem specific to the distros, but I don't see any existing bug on bugs.freedesktop.org either. Could this be a problem in something else, systemd or pam maybe? I've not seen this on Intel as old as 845G? Would it actually be two bugs, one against Nouveau and another against Radeon? Has no one else here encountered this? -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] CAD often useless
This isn't the first time or the only system. This particular one is an old Athlon booted to F22 just updated last night. In order to try some follow-up on a bug, I booted with drm.debug=14 log_buf_len=16M on cmdline. Somehow after exiting IceWM back into KDM, the system quit responding. After some waiting, I was switched to a tty full of systemd-journal failed to write readonly filesystem messages. How the system got / into a readonly state I have no idea, but my complaint is $SUBJECT, the time it takes, or the complete failure, trying to reboot when there is a problem, often seeing failed to store sound card state or failing boot *start* jobs. Why has rebooting to get out of trouble gotten to be so nearly impossible? -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] CAD often useless
Zbigniew Jędrzejewski-Szmek composed on 2015-04-15 18:11 (UTC): On Wed, Apr 15, 2015 at 13:31:38 -0400, Felix Miata wrote: This isn't the first time or the only system. This particular one is an old Athlon booted to F22 just updated last night. In order to try some follow-up on a bug, I booted with drm.debug=14 log_buf_len=16M on cmdline. Somehow after exiting IceWM back into KDM, the system quit responding. After some waiting, I was switched to a tty full of systemd-journal failed to write readonly filesystem messages. How the system got / into a readonly state I have no idea, but my complaint is $SUBJECT, the time it takes, or the complete failure, trying to reboot when there is a problem, often seeing failed to store sound card state or failing boot *start* jobs. Why has rebooting to get out of trouble gotten to be so nearly impossible? Did you try to press CAD more than 7 times within 2s? This should result in immedate reboot. My fingers and keyboards are old. I just hold CAD down until reboot proceeds, or not. All that have repeat and delay configurable in BIOS are set to 20 cps 250 delay. KDE I always set to same. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] CAD often useless
Felix Miata composed on 2015-04-15 14:48 (UTC-0400): Zbigniew JÄdrzejewski-Szmek composed on 2015-04-15 18:11 (UTC): On Wed, Apr 15, 2015 at 13:31:38 -0400, Felix Miata wrote: This isn't the first time or the only system. This particular one is an old Athlon booted to F22 just updated last night. In order to try some follow-up on a bug, I booted with drm.debug=14 log_buf_len=16M on cmdline. Somehow after exiting IceWM back into KDM, the system quit responding. After some waiting, I was switched to a tty full of systemd-journal failed to write readonly filesystem messages. How the system got / into a readonly state I have no idea, but my complaint is $SUBJECT, the time it takes, or the complete failure, trying to reboot when there is a problem, often seeing failed to store sound card state or failing boot *start* jobs. Why has rebooting to get out of trouble gotten to be so nearly impossible? Did you try to press CAD more than 7 times within 2s? This should result in immedate reboot. My fingers and keyboards are old. I just hold CAD down until reboot proceeds, or not. All that have repeat and delay configurable in BIOS are set to 20 cps 250 delay. KDE I always set to same. Needing again to CAD on yet another machine (kt88b this time, kt400 earlier), again encountering / going into RO state, I noticed this time the message Ctrl-Alt-Del was pressed more than 7 times within 2s, rebooting immediately. I remember having seen this on previous occasions to need CAD, but it's still on the screen now, several minutes later, with the NUM key's LED remaining responsive. IOW, it doesn't do either what it says, or what I wanted. This is on F22 with PAE kernel 4.0.0-1 and PATA storage only except for empty floppy drive. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] root= ignored
Chris Murphy composed on 2015-01-28 23:51 (UTC-0700): Felix Miata wrote: Chris Murphy composed on 2015-01-27 23:29 (UTC-0700): Felix Miata wrote: Lennart Poettering composed on 2015-01-28 02:03 (UTC+0100): Hmm, Fedora doesn't obey root=? That sounds like a bug. I'm not sure what it means, Fedora doesn't obey root=. Since a long time it uses root=UUID= and this has worked for me. All current distros whose bootloaders I've used include a root= in each of their bootloader stanzas. AFAIK, root=UUID= is used in Fedora's Grub2 stanzas. That's true unless LVM is being used, which happens to be the default, in which case it's root=VG/LV. I've used LVM on exactly one HD, since wiped, too many years ago to remember when or which. When Fedora is the source and clone, attempting boot of clone using default initrd produces an emergency shell, unlike openSUSE. I'm unable to reproduce this problem on a BIOS system. What you describe below looks little like the process I described. Old volume is Btrfs, new volumes is Btrfs (new volume UUID), I didn't think any mention of filesystem type would be relevant in describing my process, but all clones used as a Fedora / here have been either EXT3 or EXT4. and I just copy the I wrote clone for a reason. I don't just copy files. I clone (logical, root, autonomous) *partitions*, subsequently modifying only fstab, volume label and UUID before attempting boot from it. files from old to new (I actually used btrfs send receive). I of course had to install a new bootloader with grub2-install, and create The process I wrote was intended to make it clear that no bootloader that may have been on a Fedora / partition was used for booting a Fedora clone as adjusted to its new location. It's a process that was relatively simple and reliable until humanly memorable cmdline root= parameters what worked formerly began being disregarded by Fedora's boot process in apparent favor of incorporating a root filesystem UUID subject to change during backup/restore process in its initrd. Somehow dracut is baking in the EFI System partition UUID into the initramfs, instead of honoring the correct one that I put into fstab. As a result boot fails and will always fail until I rebuild the initramfs. So I'd definitely consider that a bug. https://bugzilla.redhat.com/show_bug.cgi?id=1187007 Noted, commented, CC'd. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] root= ignored
Chris Murphy composed on 2015-01-27 23:29 (UTC-0700): Felix Miata wrote: Lennart Poettering composed on 2015-01-28 02:03 (UTC+0100): Hmm, Fedora doesn't obey root=? That sounds like a bug. I'm not sure what it means, Fedora doesn't obey root=. Since a long time it uses root=UUID= and this has worked for me. All current distros whose bootloaders I've used include a root= in each of their bootloader stanzas. AFAIK, root=UUID= is used in Fedora's Grub2 stanzas. Maybe it went into Fedora's Grub Legacy cmdlines before the switch to Grub2. I don't remember. I haven't installed any of Fedora's bootloaders since Fedora dropped Grub Legacy, so don't have first-hand experience from which to know otherwise. Most distros do not require use of their own bootloaders to successfully boot. I've been using openSUSE's Grub Legacy for booting all distros installed on my own systems ever since Grub2 started becoming distros' default bootloader. This has worked for all, except as described below. In the pre-libata days, as I remember, any syntactically correct root= on cmdline was what would be used to find /etc/fstab and get the root filesystem up. Included among the possibles valid with post-libata distros have been: root=/dev/sdX root=/dev/disk/by-label/... root=LABEL=... root=/dev/disk/by-uuid/... root=UUID=... What it means is that traditional cmdline root= option still works with openSUSE's configured-by-default initrds, but not with Fedora's configured-by-default initrds. Translated, this means the following process that works with non-Fedora root partitions fails with Fedora's root partitions: 1-boot anything other than intended logical source partition on a BIOS multiboot system with 1 HD only 2-clone an existing unmounted logical source/root partition to some other unmounted partition 3-configure a unique UUID and volume label on the clone 4-mount the clone and adjust its fstab appropriately 5-in the HD's bootloader menu (not the boot menu on the clone), clone the source stanza and adjust it appropriately to use for the clone, using any of the above listed (legal) root= forms. When Fedora is the source and clone, attempting boot of clone using default initrd produces an emergency shell, unlike openSUSE. To boot a Fedora clone normally requires a chroot rescue (what I usually do) or a /boot/initramfs-0-rescue*.img boot to rebuild its normal initrd(s). This Fedora characteristic in effect produces an undesirable, and likely unforeseeable by most, stumbling block to at least one backup/restore scenario that involves no change of hardware that Fedora's Dracut hostonly configuration seems to suggest would be safe. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] root= ignored (was: failing boot start jobs delay reboot)
Lennart Poettering composed on 2015-01-28 02:03 (UTC+0100): Felix Miata wrote: Both. When they occur during init they repeat during shutdown. Even when I let init complete and succeed to fix the typo or oversight, the init failure gets remembered and repeated at shutdown. Often the start job is on account of a volume label that has been replaced, usually along with a UUID, because the clone is a partition on the same HD. Fedora is particularly frustrating by embedding dependent root volume label and not obeying root= on cmdline (openSUSE obeys root=). Those typos usually have to be fixed by chroot to run dracut. Hmm, Fedora doesn't obey root=? That sounds like a bug. I think it's only a problem due to Fedora's configuration of its Dracut hostonly option used by default. AFAICR, its rescue initrds have always worked. I can't remember now, but it may possibly be Mageia with hostonly enabled disobeys root= too, locking onto root's UUID when the initrd was built. It's never been a problem I've observed in openSUSE, which let dracut evolve a lot longer before switching to it from mkinitrd. Harald? -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] failing boot start jobs delay reboot
Lennart Poettering composed on 2015-01-28 02:33 (UTC+0100): Felix Miata wrote ... So, I actually implemented this now. Or actually, I only implemented the part about C-A-D triggering a reboot. I picked 7x per 2s as limit though, seemed easier to me. It should be easy to extend this to show information about running jobs after 3x too. http://cgit.freedesktop.org/systemd/systemd/commit/?id=2e5c94b9aaefce46835b623e800cfc168995ea3f Hope this is useful, No objection from this non-programmer. Thanks. :-) Out of curiosity, I looked at that URL, little there I understand, but I did notice a comment string that seemed like might include a typo: C-A-D too more. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] failing boot start jobs delay reboot
Andrei Borzenkov composed on 2015-01-20 11:24 (UTC+0300): Felix Miata wrote: When they occur during init they repeat during shutdown. Even when I let init complete and succeed to fix the typo or oversight, the init failure gets remembered and repeated at shutdown. Yes, that's the problem. For once, traditional workflow of - stop in emergency shell when mount fails - fix /etc/fstab - ^D to continue boot no more works, because /etc/fstab is not reevaluated so systemd will still try the same broken mount again. Also I have observed delays during shutdown/reboot /probably/ triggered by failed mounts but am not sure how to reproduce them. If you have simple step by step guide how to trigger such delays, would be great. Given what I have written in this thread, I am puzzled that you ask this. Try what I just did (on multiboot host gx28c with 8 or more volume lines in eash installation's fstab; 'fdisk -l | grep /dev/sda | wc -l' produces 24 on this host): 1-have fstab entries for openSUSE 13.1 and TW mount using the form LABEL= 2-in TW's fstab, misspell the volume label for 13.1 3-boot TW 4-when the waiting for dev-disk-by\x2dlabel-LABEL.device (failing volume's label) start job appears, right away CAD, and shutdown will proceed normally for a short time, after which the waiting for dev-disk-by\x2dlabel-LABEL.device previously experienced will institute a similar delay before reboot completes 5-boot 13.1 6-restore TW's fstab to have correct volume label spellings next boot I repeated on same host using Fedora 20 and 21 to get similar delays. For both TW and F21 I also tried letting init proceed into emergency shell, fixing fstab, then CAD, whereupon reboot proceeded quickly for both. To reach Fedora 20 emergency shell after a very long wait (3 minutes here on 2.8GHz 32 bit single core P4), include a misspelled root volume after LABEL= on cmdline. (Warning: /dev/disk/by-label/fedor23 does not exist; Generating...) -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] failing boot start jobs delay reboot
Has anything been done in more recent releases about this? I do a lot of cloning, and sometimes produce typos on grub cmdlines and fstab lines. This produces long delays in init followed by emergency mode when the non-essential mount fails and fstab for that device does not include the nofail option. When I recognize early in init that I have made a fstab typo, I try to CAD to choose another boot choice that isn't broken and fix the typo, but that produces yet another start job wait for the same broken job, often followed by a gazillion failed to save sound card state messages from holding down CAD. openSUSEes, Mageias Fedoras (including Factories, Cauldrons Rawhides) comprise most of my installations subject to these self-inflicted delays that I can't recall being a problem with sysvinit. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] failing boot start jobs delay reboot
Andrei Borzenkov composed on 2015-01-20 06:35 (UTC+0300): Mon, 19 Jan 2015 17:59:41 -0500 Felix Miata composed: Has anything been done in more recent releases about this? I do a lot of cloning, and sometimes produce typos on grub cmdlines and fstab lines. This produces long delays in init followed by emergency mode when the non-essential mount fails and fstab for that device does not include the nofail option. When I recognize early in init that I have made a fstab typo, I try to CAD to choose another boot choice that isn't broken and fix the typo, but that produces yet another start job wait for the same broken job, often followed by a gazillion failed to save sound card state messages from holding down CAD. openSUSEes, Mageias Fedoras (including Factories, Cauldrons Rawhides) comprise most of my installations subject to these self-inflicted delays that I can't recall being a problem with sysvinit. Self inflicted delays during boot or during Ctrl-Alt-Del? Both. When they occur during init they repeat during shutdown. Even when I let init complete and succeed to fix the typo or oversight, the init failure gets remembered and repeated at shutdown. Often the start job is on account of a volume label that has been replaced, usually along with a UUID, because the clone is a partition on the same HD. Fedora is particularly frustrating by embedding dependent root volume label and not obeying root= on cmdline (openSUSE obeys root=). Those typos usually have to be fixed by chroot to run dracut. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] rpcbind static, want enabled
Andrei Borzenkov composed on 2014-10-21 12:12 (UTC+0400): Felix Miata wrote: Andrei Borzenkov composed on 2014-10-21 11:29 (UTC+0400): Felix Miata wrote: I have 27 Fedora 21 22 installations to real hardware, all originating via HTTP process. Half work as expected. Those that do have NetworkManager not installed, and have rpcbind.service enabled Those that misbehave by having a more than a minute delay on attempt to mount nfs via fstab entries, of which half do and half do not have NetworkManager installed, have rpcbind.service static then it is socket activated, you need to enable rpcbind.socket. But every one of the failing installations already had: rpcbind.socket enabled same as the working installations. With chkconfig and sysvinit it was a simple matter to enable rpcbind. With systemd evolved to v216 it seems I should be able to 'systemctl enable rpcbind.service', but that changes nothing on these installations. What's the obstacle here? If the explanation is in man systemctl or man rpcbind, I'm not finding it. Lots more blame, unit status and logs at: http://fm.no-ip.com/Tmp/Linux/F/NFS/ Also Fedora mailing list thread: https://lists.fedoraproject.org/pipermail/test/2014-May/121461.html May 29 00:40:00 g5eas rpc.statd[692]: Version 1.3.0 starting May 29 00:40:00 g5eas systemd[1]: Started RPC bind service. It looks like rpcbind is correctly attempted to be started when statd tries to contact it so socket activation appears to work as far as systemd is concerned. Then for some reasons rpcbind fails to process request from statd. Enabling more debugging on rpcbind and/or statd may explain why registration fails. Those are not things I know how or wish to pursue. I found a workaround, no thanks to the systemctl 216-10.fc22 man page, which says: enable NAME... Enable one or more unit files or unit file instances, as specified on the command line That's invalid WRT rpcbind. In order to enable rpcbind I found the following produces satisfactory results: systemctl add-wants multi-user.target rpcbind The question remains how and why 13 of 26 (I miscounted in my original thread post) installations were set to static instead of enabled in the first place, and whether the workaround amounts to an optimal solution. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] rpcbind static, want enabled
Andrei Borzenkov composed on 2014-10-21 11:29 (UTC+0400): Felix Miata wrote: I have 27 Fedora 21 22 installations to real hardware, all originating via HTTP process. Half work as expected. Those that do have NetworkManager not installed, and have rpcbind.service enabled Those that misbehave by having a more than a minute delay on attempt to mount nfs via fstab entries, of which half do and half do not have NetworkManager installed, have rpcbind.service static then it is socket activated, you need to enable rpcbind.socket. But every one of the failing installations already had: rpcbind.socket enabled same as the working installations. With chkconfig and sysvinit it was a simple matter to enable rpcbind. With systemd evolved to v216 it seems I should be able to 'systemctl enable rpcbind.service', but that changes nothing on these installations. What's the obstacle here? If the explanation is in man systemctl or man rpcbind, I'm not finding it. Lots more blame, unit status and logs at: http://fm.no-ip.com/Tmp/Linux/F/NFS/ Also Fedora mailing list thread: https://lists.fedoraproject.org/pipermail/test/2014-May/121461.html -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] failed to store sound card state
I see this repeated often during reboot attempts that do not proceed as expected to swiftly do the deed. It seems to be prerequisite to shutdown/reboot. I can't recall ever seeing anything like it when sysvinit was employed. Why does rebooting require the storing of a sound card state, particularly when there are no connected speakers and no sound system has been employed the entire time since booting (typical of multiuser rather than graphical startup, 3 on Grub cmdline)? -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] failed to store sound card state
On 2014-03-27 21:46 (GMT-0300) Cristian Rodríguez composed: Felix Miata composed: I see this repeated often during reboot attempts that do not proceed as expected to swiftly do the deed. It seems to be prerequisite to shutdown/reboot. I can't recall ever seeing anything like it when sysvinit was employed. Why does rebooting require the storing of a sound card state, particularly when there are no connected speakers and no sound system has been employed the entire time since booting (typical of multiuser rather than graphical startup, 3 on Grub cmdline)? Hey! :-) This is not a systemd issue.. but an implementation detail of the alsa units instead. Systemd controls startup and shutdown, right? Maybe what systemd requires it do is too obtuse for the alsa people to figure out how to prevent shutdown delays? BTW, this is normally not a problem that I can recall. It occurs following CAD that follows quickly on the heels of making a Grub menu selection and realizing a selection error had been made, before any filesystems have been mounted, and before many if not most units have been triggered to start. rpm -qf /usr/lib/systemd/system/alsa*.service | uniq alsa-utils-1.0.27.2-4.2.1.x86_64 ??? alsa-utils-1.0.27.2-2.mga4 alsa-utils-1.0.27.2-5.fc21.i686 -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] socket based activation for Python?
Hi, I develop Python software and some of this software comes with a Python daemon which is started during boot. Í can write a service file easily, just starting the daemon as I do now with a traditional init script. If I understand the concept correctly, my daemon should use socket-based activation for the most efficient usage of systemd. However I did not find any reference how to do that in Python… To me it looks like sd-daemon and friends are only available for applications written in C. - Is that true? - Is there any project to provide systemd glue code to Python? fs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
