Re: Got tired of waiting for suspend/resume (something like that)
Le 02/02/2018 à 10:28, Curt a écrit : Maybe an encrypted swap is overkill in a home alone machine; I am now idly wondering whether there exists any documented (and successful) remote unencrypted swap attacks. Why "remote" ? AFAIK, disk encryption is against physical attacks, not remote attacks. Then again, as they say here, encrypting your swap "ça ne mange pas de pain," Swap encryption per se does not. But swap encryption with a random key prevents hibernation.
Re: Got tired of waiting for suspend/resume (something like that)
Curtwrote: > Maybe an encrypted swap is overkill in a home alone machine; I am now > idly wondering whether there exists any documented (and successful) remote > unencrypted swap attacks. I use it on all my systems, beause it is cheap to setup and just works behind the curtains, making sure no sensitive date written to swap is ever available for later recovery. Maybe I grew a bit more paranoid in the events since Edward Snowdens leaks, but since cryptswap is so easy to use, I thought: why not. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Got tired of waiting for suspend/resume (something like that)
On 2018-02-01, Sven Hartgewrote: > Curt wrote: > >> Still, I'm uncertain what goes into /etc/fstab. > >>/dev/mapper/swap none swap sw 0 0 > >> ? > > Yes, this is correct. With crypted-swap you need to use the device > mapper device, because the UUID changes on every boot, as you > discovered. (Which is the point of having a freshly encrypted swap using > a random key during boot.) Thank you; actually, as noted in yet another recursive response, in my particular case it was /dev/mapper/*cryptswap1* ..., corresponding to the 'name' in /etc/crypttab (Nicolas Georges told me as much (to use the 'name' in crypttab in my /etc/fstab entry), but I didn't grok right away what was 'name' and what was not 'name' in that file. Maybe an encrypted swap is overkill in a home alone machine; I am now idly wondering whether there exists any documented (and successful) remote unencrypted swap attacks. Then again, as they say here, encrypting your swap "ça ne mange pas de pain," except for the bug (and the fact that the tutorial I followed to encrypt my home directory never said anything about changing /etc/fstab following swap encryption--or maybe I missed it). > Grüße, > Sven. > -- “True terror is to wake up one morning and discover that your high school class is running the country.” – Kurt Vonnegut
Re: Got tired of waiting for suspend/resume (something like that)
Curtwrote: > Still, I'm uncertain what goes into /etc/fstab. >/dev/mapper/swap none swap sw 0 0 > ? Yes, this is correct. With crypted-swap you need to use the device mapper device, because the UUID changes on every boot, as you discovered. (Which is the point of having a freshly encrypted swap using a random key during boot.) Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Got tired of waiting for suspend/resume (something like that)
On 2018-02-01, Nicolas Georgewrote: > >> Unfortunately my crypttab (which I've never touched or looked at) >> reveals the following: >> # >> cryptswap1 /dev/sda5 /dev/urandom swap,cipher=3Daes-cbc-essiv:sha256 >> Which is dangerous because that dev/sda5 gets wiped out at every >> (re)boot. > The danger is quite exaggerated, but better eliminate it altogether if > convenient. > >> Still, I'm uncertain what goes into /etc/fstab. >>/dev/mapper/swap none swap sw 0 0 Actually, for posterity, that should be /dev/mapper/cryptswap1 none swap sw 0 0 cryptswap1 being the crypttab "name". > > Indeed, /dev/mapper/swap, since your swap device is named like that in > crypttab. Although I personally prefer a more explicit name. > > Regards, Thank you. > Nicolas George > -- “True terror is to wake up one morning and discover that your high school class is running the country.” – Kurt Vonnegut
Re: Got tired of waiting for suspend/resume (something like that)
Curt (2018-02-01): > Unfortunately my crypttab (which I've never touched or looked at) > reveals the following: > > # > cryptswap1 /dev/sda5 /dev/urandom swap,cipher=aes-cbc-essiv:sha256 > > Which is dangerous because that dev/sda5 gets wiped out at every > (re)boot. The danger is quite exaggerated, but better eliminate it altogether if convenient. > curty@einstein:~/tips$ find -L /dev/disk -samefile /dev/sda5 > /dev/disk/by-partuuid/00065379-05 > /dev/disk/by-path/pci-:00:11.0-ata-1-part5 > /dev/disk/by-id/wwn-0x50014ee2b0b1534b-part5 > /dev/disk/by-id/ata-WDC_WD15EARS-22MVWB0_WD-WCAZA8328525-part5 > > I probably should change my crypttab (as a sane precaution) to: > > swap > /dev/disk/by-id//dev/disk/by-id/ata-WDC_WD15EARS-22MVWB0_WD-WCAZA8328525-part5 > /dev/urandom swap,cipher=aes-cbc-essiv:sha256,size=256 That would probably work. "PARTUUID=00065379-05" would probably too. > Still, I'm uncertain what goes into /etc/fstab. > >/dev/mapper/swap none swap sw 0 0 > > ? Indeed, /dev/mapper/swap, since your swap device is named like that in crypttab. Although I personally prefer a more explicit name. Regards, -- Nicolas George signature.asc Description: Digital signature
Re: Got tired of waiting for suspend/resume (something like that)
David Wright (2018-02-01): > Vaguely Thanks. > Later the page goes on to describe suspend/resume but not with > a random key. Some people might see that as a challenge, others > as an opportunity. I make no judgment of such people. The whole point of using an ephemeral key is to make the contents of the swap useless after the system has terminated. For forensic, but of course also for resume. If something was designed do be impossible and people find a "challenge" or an "opportunity" to try to do anyway, thus weakening or voiding its benefits, they are just idiots. I can make that judgement, because I understand what I am talking about. > Not everyone is using them. What can I say? If a good solution exists and people insist on using a bad one, I can only watch and smile. > Of course, you know that the only fix is the one you suggested in the BTS. > Best not to think about any other options. I do not pretend that the solution is the only one, it is not. But I can make the difference between a good solution and a bad one. Please forgive me, but I do not like to argue further with you on this. Regards, -- Nicolas George signature.asc Description: Digital signature
Re: Got tired of waiting for suspend/resume (something like that)
Curt wrote: > Unfortunately my crypttab (which I've never touched or looked at) > reveals the following: > > # > cryptswap1 /dev/sda5 /dev/urandom swap,cipher=aes-cbc-essiv:sha256 > > Which is dangerous because that dev/sda5 gets wiped out at every > (re)boot. > > curty@einstein:~/tips$ find -L /dev/disk -samefile /dev/sda5 > /dev/disk/by-partuuid/00065379-05 > /dev/disk/by-path/pci-:00:11.0-ata-1-part5 > /dev/disk/by-id/wwn-0x50014ee2b0b1534b-part5 > /dev/disk/by-id/ata-WDC_WD15EARS-22MVWB0_WD-WCAZA8328525-part5 > > I probably should change my crypttab (as a sane precaution) to: > > swap > /dev/disk/by-id//dev/disk/by-id/ata-WDC_WD15EARS-22MVWB0_WD-WCAZA8328525-part5 > /dev/urandom swap,cipher=aes-cbc-essiv:sha256,size=256 > > Still, I'm uncertain what goes into /etc/fstab. > > /dev/mapper/swap none swap sw 0 0 > > ? in the above example (crypttab) you could replace /dev/sda5 with /dev/disk/by-id/ata-WDC_WD15EARS-22MVWB0_WD-WCAZA8328525-part5 in fstab however goes whatever is returned by lvm (most probably leave untouched) regards
Re: Got tired of waiting for suspend/resume (something like that)
On Thu 01 Feb 2018 at 17:48:18 (+0100), Nicolas George wrote: > David Wright (2018-02-01): > > That assumes it's stable. The OP said it's not. I'm making no judgment > > on the matter. > > The OP described the use of an ephemeral key to encrypt the swap. Are > you familiar with that practice? Vaguely, so I just googled it. That led me to https://wiki.archlinux.org/index.php/Dm-crypt/Swap_encryption Looking through this, I think I might have been regurgitating the section "UUID and LABEL" which describes how to share a filesystem and swapspace. Their main aim appears to be reducing the chances of accidental corruption. Later the page goes on to describe suspend/resume but not with a random key. Some people might see that as a challenge, others as an opportunity. I make no judgment of such people. The page is very baroque; last update 2018-01-08. > If not, better acknowledge it and let > the conversation pass by you. > > > The contents will be wanted if it's being used for resume which is in > > the Subject line. (I didn't write it.) > > You completely misunderstood the problem. The swap is waited by initrd > for resume, but that is not wanted by the user. It is a bug of newer > versions of initramfs-tools that try to set up resume automatically and > do not detect ephemeral keys. I didn't try to guess whether the OP used suspend/hibernate etc. nor whether they might in future. And I'm sorry it took you a long time to find your fix to your problem. > > AIUI, again, correct me if I'm wrong, partition names and UUIDs are > > modern, non-baroque contraptions introduced with GPT. > > Indeed. On the other hand, LVM also allows to make a partition-like > system with labels. Not everyone is using them. > > Of course, the filesystem LABEL and UUID reside in the filesystem. > > That's why a mechanism exists to have a filesystem and swap space > > in the same partition. I'd be interested to know why the offset was > > introduced if not for such a purpose. Just interested, you understand. > > I have no axe to grind. Remember, I'm not the OP. I only know what the > > OP tells us. > > These options have been introduced for some reason, they do not matter. They do if mention of them causes people to look at whether the options, or some part of them, could be useful. > What matters is that a lot of people, when confronted with a problem, > will not take time and try to understand how it all fits together. > Instead, they will just take the first solution they think of, implement > it, find drawbacks, fix them the same way, entering an endless loop of > piling kludges over kludges. I know several people who function like > that. Of course, you know that the only fix is the one you suggested in the BTS. Best not to think about any other options. > The solution you quoted is a perfect example of that. Better learn to > recognize them rather than propagate them. BTW you could cut the patronising tone without harming your ability to argue a point. Cheers, David.
Re: Got tired of waiting for suspend/resume (something like that)
On 2018-02-01, Curtwrote: > On 2018-02-01, Nicolas George wrote: >> >> >> David Wright (2018-02-01): >>> As far as finding the swap partition with fstab, ISTR a workaround. >>> Without the details, you make the swap partition with a tiny >>> filesystem in it, which gives it a stable UUID and LABEL. You then >>> specify an offset in every reference to its use, which skips over >>> the filesystem at its start. >> >> What are you trying to achieve with this baroque contraption? >> >> If a swap is encrypted normally, then just use its UUID. >> >> If a swap is encrypted with an ephemeral key, that means its contents is >> not wanted after a reboot, so there is no need to preserve the key, >> obviously. As to how to specify it in fstab, you need to use the name >> declared in crypttab. > > Unfortunately my crypttab (which I've never touched or looked at) > reveals the following: > > # > cryptswap1 /dev/sda5 /dev/urandom swap,cipher=aes-cbc-essiv:sha256 > > Which is dangerous because that dev/sda5 gets wiped out at every > (re)boot. > Then again maybe not seriously defective to leave it as /dev/sda5 as I have only one disk (which reminds of the Clarol commercial concerning lives). -- “True terror is to wake up one morning and discover that your high school class is running the country.” – Kurt Vonnegut
Re: Got tired of waiting for suspend/resume (something like that)
On 2018-02-01, Nicolas Georgewrote: > > > David Wright (2018-02-01): >> As far as finding the swap partition with fstab, ISTR a workaround. >> Without the details, you make the swap partition with a tiny >> filesystem in it, which gives it a stable UUID and LABEL. You then >> specify an offset in every reference to its use, which skips over >> the filesystem at its start. > > What are you trying to achieve with this baroque contraption? > > If a swap is encrypted normally, then just use its UUID. > > If a swap is encrypted with an ephemeral key, that means its contents is > not wanted after a reboot, so there is no need to preserve the key, > obviously. As to how to specify it in fstab, you need to use the name > declared in crypttab. Unfortunately my crypttab (which I've never touched or looked at) reveals the following: # cryptswap1 /dev/sda5 /dev/urandom swap,cipher=aes-cbc-essiv:sha256 Which is dangerous because that dev/sda5 gets wiped out at every (re)boot. curty@einstein:~/tips$ find -L /dev/disk -samefile /dev/sda5 /dev/disk/by-partuuid/00065379-05 /dev/disk/by-path/pci-:00:11.0-ata-1-part5 /dev/disk/by-id/wwn-0x50014ee2b0b1534b-part5 /dev/disk/by-id/ata-WDC_WD15EARS-22MVWB0_WD-WCAZA8328525-part5 I probably should change my crypttab (as a sane precaution) to: swap /dev/disk/by-id//dev/disk/by-id/ata-WDC_WD15EARS-22MVWB0_WD-WCAZA8328525-part5 /dev/urandom swap,cipher=aes-cbc-essiv:sha256,size=256 Still, I'm uncertain what goes into /etc/fstab. /dev/mapper/swap none swap sw 0 0 ? > Using filesystem labels and UUID is IMHO a very bad design, because they > reside inside the filesystem itself. Better use LVM, partition names or > partition UUIDs. > > Regards, > -- “True terror is to wake up one morning and discover that your high school class is running the country.” – Kurt Vonnegut
Re: Got tired of waiting for suspend/resume (something like that)
David Wright (2018-02-01): > That assumes it's stable. The OP said it's not. I'm making no judgment > on the matter. The OP described the use of an ephemeral key to encrypt the swap. Are you familiar with that practice? If not, better acknowledge it and let the conversation pass by you. > The contents will be wanted if it's being used for resume which is in > the Subject line. (I didn't write it.) You completely misunderstood the problem. The swap is waited by initrd for resume, but that is not wanted by the user. It is a bug of newer versions of initramfs-tools that try to set up resume automatically and do not detect ephemeral keys. > AIUI, again, correct me if I'm wrong, partition names and UUIDs are > modern, non-baroque contraptions introduced with GPT. Indeed. On the other hand, LVM also allows to make a partition-like system with labels. > Of course, the filesystem LABEL and UUID reside in the filesystem. > That's why a mechanism exists to have a filesystem and swap space > in the same partition. I'd be interested to know why the offset was > introduced if not for such a purpose. Just interested, you understand. > I have no axe to grind. Remember, I'm not the OP. I only know what the > OP tells us. These options have been introduced for some reason, they do not matter. What matters is that a lot of people, when confronted with a problem, will not take time and try to understand how it all fits together. Instead, they will just take the first solution they think of, implement it, find drawbacks, fix them the same way, entering an endless loop of piling kludges over kludges. I know several people who function like that. The solution you quoted is a perfect example of that. Better learn to recognize them rather than propagate them. Regards, -- Nicolas George signature.asc Description: Digital signature
Re: Got tired of waiting for suspend/resume (something like that)
On Thu 01 Feb 2018 at 17:15:40 (+0100), Nicolas George wrote: > David Wright (2018-02-01): > > As far as finding the swap partition with fstab, ISTR a workaround. > > Without the details, you make the swap partition with a tiny > > filesystem in it, which gives it a stable UUID and LABEL. You then > > specify an offset in every reference to its use, which skips over > > the filesystem at its start. > > What are you trying to achieve with this baroque contraption? I'm not trying to achieve anything. I'm not the OP. I prefaced my reply with ISTR. IOW someone else invented this method and I neither ask for credit nor disparage it. > If a swap is encrypted normally, then just use its UUID. That assumes it's stable. The OP said it's not. I'm making no judgment on the matter. > If a swap is encrypted with an ephemeral key, that means its contents is > not wanted after a reboot, so there is no need to preserve the key, > obviously. As to how to specify it in fstab, you need to use the name > declared in crypttab. The contents will be wanted if it's being used for resume which is in the Subject line. (I didn't write it.) > Using filesystem labels and UUID is IMHO a very bad design, because they > reside inside the filesystem itself. Better use LVM, partition names or > partition UUIDs. AIUI, again, correct me if I'm wrong, partition names and UUIDs are modern, non-baroque contraptions introduced with GPT. Of course, the filesystem LABEL and UUID reside in the filesystem. That's why a mechanism exists to have a filesystem and swap space in the same partition. I'd be interested to know why the offset was introduced if not for such a purpose. Just interested, you understand. I have no axe to grind. Remember, I'm not the OP. I only know what the OP tells us. Cheers, David.
Re: Got tired of waiting for suspend/resume (something like that)
David Wright (2018-02-01): > As far as finding the swap partition with fstab, ISTR a workaround. > Without the details, you make the swap partition with a tiny > filesystem in it, which gives it a stable UUID and LABEL. You then > specify an offset in every reference to its use, which skips over > the filesystem at its start. What are you trying to achieve with this baroque contraption? If a swap is encrypted normally, then just use its UUID. If a swap is encrypted with an ephemeral key, that means its contents is not wanted after a reboot, so there is no need to preserve the key, obviously. As to how to specify it in fstab, you need to use the name declared in crypttab. Using filesystem labels and UUID is IMHO a very bad design, because they reside inside the filesystem itself. Better use LVM, partition names or partition UUIDs. Regards, -- Nicolas George signature.asc Description: Digital signature
Re: Got tired of waiting for suspend/resume (something like that)
On Thu 01 Feb 2018 at 15:05:10 (+), Curt wrote: > On 2018-02-01, David Wrightwrote: > >> > >> Sorry but where does that leave > >> > >> /etc/initramfs-tools/conf.d/resume > >> > >> > >> ??? > >> > >> Also 'RESUME=none'? > > > > Yes; but AIUI the important one is the one in the initramfs as that's > > the one that gets looked at when you turn the computer on. > > Well, I don't know, but anything in /etc/initramfs-tools/conf.d/ > supercedes initramfs.conf*; in addition, 'resume' appears to be a 'stale' file > from a previous version of initramfs-tools that is now "caduc." I got > rid of it, added 'RESUME=none' to initramsfs.conf (documented) and reran > update-initramfs and the "Tired of waiting..." problem disappeared. > > * > #(Note that configuration options from this file can be overridden > # by config files in the /etc/initramfs-tools/conf.d directory. Hence my "Yes". What's in the filesystem matters when you build initramfs, and what's in the ramfs matters when you actually resume. > > On the changing UUID, are you using the scheme where swap is encrypted > > with a random key? IIRC that can lead to a problem as the key would > > have to be preserved across the reboot. > > I'm unsure how this works. The UUID of the encrypted swap partition is > randomized apparently (changes at every boot); this was not a problem > before (or I was simply unaware of it), but now it is (because I see no > alternative but to comment out the swap entry in /etc/fstab). As far as finding the swap partition with fstab, ISTR a workaround. Without the details, you make the swap partition with a tiny filesystem in it, which gives it a stable UUID and LABEL. You then specify an offset in every reference to its use, which skips over the filesystem at its start. That just leaves you with preserving the encryption key. Cheers, David.
Re: Got tired of waiting for suspend/resume (something like that)
On 2018-02-01, David Wrightwrote: >> >> Sorry but where does that leave >> >> /etc/initramfs-tools/conf.d/resume >> >> >> ??? >> >> Also 'RESUME=none'? > > Yes; but AIUI the important one is the one in the initramfs as that's > the one that gets looked at when you turn the computer on. Well, I don't know, but anything in /etc/initramfs-tools/conf.d/ supercedes initramfs.conf*; in addition, 'resume' appears to be a 'stale' file from a previous version of initramfs-tools that is now "caduc." I got rid of it, added 'RESUME=none' to initramsfs.conf (documented) and reran update-initramfs and the "Tired of waiting..." problem disappeared. * #(Note that configuration options from this file can be overridden # by config files in the /etc/initramfs-tools/conf.d directory. > On the changing UUID, are you using the scheme where swap is encrypted > with a random key? IIRC that can lead to a problem as the key would > have to be preserved across the reboot. I'm unsure how this works. The UUID of the encrypted swap partition is randomized apparently (changes at every boot); this was not a problem before (or I was simply unaware of it), but now it is (because I see no alternative but to comment out the swap entry in /etc/fstab). > Cheers, > David. > > -- “True terror is to wake up one morning and discover that your high school class is running the country.” – Kurt Vonnegut
Re: Got tired of waiting for suspend/resume (something like that)
On Thu 01 Feb 2018 at 13:11:20 (+), Curt wrote: > On 2018-02-01, Curtwrote: > >> > >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D885160 > > > > Your very own bug report. > > > >> It includes an easy workaround: include "RESUME=none" in > >> /etc/initramfs-tools/initramfs.conf. > > > > Sorry but where does that leave > > /etc/initramfs-tools/conf.d/resume > > > ??? > > Also 'RESUME=none'? Yes; but AIUI the important one is the one in the initramfs as that's the one that gets looked at when you turn the computer on. On the changing UUID, are you using the scheme where swap is encrypted with a random key? IIRC that can lead to a problem as the key would have to be preserved across the reboot. Cheers, David.
Re: Got tired of waiting for suspend/resume (something like that)
On 2018-02-01, Curtwrote: > On 2018-02-01, Curt wrote: >> On 2018-02-01, Curt wrote: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D885160 >>> >>> Your very own bug report. >>> It includes an easy workaround: include "RESUME=none" in /etc/initramfs-tools/initramfs.conf. >>> >> >> Sorry but where does that leave >> >> /etc/initramfs-tools/conf.d/resume > > I'm reading that the above file is "a stale file ... which is the > location where the RESUME variable had to be set in versions prior to > 0.129." > > https://lists.debian.org/debian-kernel/2017/04/msg00338.html > > I'm going to move it out of the way and see what happens. > No, you can't move it out of the way ('resume.bak' was read just like 'resume' was read--silly me). I deleted the file, reran 'update-initramfs -u', rebooted, and all is well (swap line commented out in /etc/fstab). >> >> ??? >> >> Also 'RESUME=none'? > > -- “True terror is to wake up one morning and discover that your high school class is running the country.” – Kurt Vonnegut
Re: Got tired of waiting for suspend/resume (something like that)
On 2018-02-01, Curtwrote: > On 2018-02-01, Curt wrote: >>> >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D885160 >> >> Your very own bug report. >> >>> It includes an easy workaround: include "RESUME=none" in >>> /etc/initramfs-tools/initramfs.conf. >> > > Sorry but where does that leave > > /etc/initramfs-tools/conf.d/resume I'm reading that the above file is "a stale file ... which is the location where the RESUME variable had to be set in versions prior to 0.129." https://lists.debian.org/debian-kernel/2017/04/msg00338.html I'm going to move it out of the way and see what happens. > > ??? > > Also 'RESUME=none'? -- “True terror is to wake up one morning and discover that your high school class is running the country.” – Kurt Vonnegut
Re: Got tired of waiting for suspend/resume (something like that)
On 2018-02-01, Curtwrote: >> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D885160 > > Your very own bug report. > >> It includes an easy workaround: include "RESUME=none" in >> /etc/initramfs-tools/initramfs.conf. > Sorry but where does that leave /etc/initramfs-tools/conf.d/resume ??? Also 'RESUME=none'? -- “True terror is to wake up one morning and discover that your high school class is running the country.” – Kurt Vonnegut
Re: Got tired of waiting for suspend/resume (something like that)
On 2018-02-01, Nicolas Georgewrote: > > Curt (2018-02-01): >> It's something like "Tired of waiting for resume/suspend." > >> cryptsetup: WARNING: target cryptswap1 has a random key, skipped > > See this bug report: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D885160 Your very own bug report. > It includes an easy workaround: include "RESUME=none" in > /etc/initramfs-tools/initramfs.conf. So if I put "RESUME=none' in /etc/initramfs-tools/initramfs.conf and rerun 'update-initramfs -u' it will no longer wait for resume. What I'm puzzled about is the UUID of my swap in /etc/fstab (it changes at every boot?). When I uncommented the swap line not only did "it" get tired of waiting for resume, but afterwards something (dev-udisks?) took and even longer time trying find my swap partition I think. Thank you for your help. > Note that your problem has absolutely nothing to do with systemd. I didn't mean to imply it did. > Regards, > > Nicolas George > > -- “True terror is to wake up one morning and discover that your high school class is running the country.” – Kurt Vonnegut
Re: Got tired of waiting for suspend/resume (something like that)
Curt (2018-02-01): > It's something like "Tired of waiting for resume/suspend." > cryptsetup: WARNING: target cryptswap1 has a random key, skipped See this bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885160 It includes an easy workaround: include "RESUME=none" in /etc/initramfs-tools/initramfs.conf. Note that your problem has absolutely nothing to do with systemd. Regards, -- Nicolas George signature.asc Description: Digital signature