Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #191830 > unrolled thread

Re: Got tired of waiting for suspend/resume (something like that)

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Got tired of waiting for suspend/resume (something like that) Nicolas George <george@nsup.org> - 2018-02-01 13:50 +0100
    Re: Got tired of waiting for suspend/resume (something like that) Curt <curty@free.fr> - 2018-02-01 14:20 +0100
      Re: Got tired of waiting for suspend/resume (something like that) Curt <curty@free.fr> - 2018-02-01 14:20 +0100
        Re: Got tired of waiting for suspend/resume (something like that) Curt <curty@free.fr> - 2018-02-01 14:50 +0100
          Re: Got tired of waiting for suspend/resume (something like that) Curt <curty@free.fr> - 2018-02-01 15:00 +0100
        Re: Got tired of waiting for suspend/resume (something like that) David Wright <deblis@lionunicorn.co.uk> - 2018-02-01 15:00 +0100
          Re: Got tired of waiting for suspend/resume (something like that) Curt <curty@free.fr> - 2018-02-01 16:10 +0100
            Re: Got tired of waiting for suspend/resume (something like that) David Wright <deblis@lionunicorn.co.uk> - 2018-02-01 17:10 +0100
              Re: Got tired of waiting for suspend/resume (something like that) Nicolas George <george@nsup.org> - 2018-02-01 17:20 +0100
                Re: Got tired of waiting for suspend/resume (something like that) Nicolas George <george@nsup.org> - 2018-02-01 17:50 +0100
                  Re: Got tired of waiting for suspend/resume (something like that) David Wright <deblis@lionunicorn.co.uk> - 2018-02-01 18:50 +0100
                    Re: Got tired of waiting for suspend/resume (something like that) Nicolas George <george@nsup.org> - 2018-02-01 20:00 +0100
                Re: Got tired of waiting for suspend/resume (something like that) David Wright <deblis@lionunicorn.co.uk> - 2018-02-01 17:50 +0100
                Re: Got tired of waiting for suspend/resume (something like that) Curt <curty@free.fr> - 2018-02-01 18:00 +0100
                  Re: Got tired of waiting for suspend/resume (something like that) Curt <curty@free.fr> - 2018-02-01 18:10 +0100
                  Re: Got tired of waiting for suspend/resume (something like that) deloptes <deloptes@gmail.com> - 2018-02-01 19:10 +0100
                  Re: Got tired of waiting for suspend/resume (something like that) Nicolas George <george@nsup.org> - 2018-02-01 20:00 +0100
                    Re: Got tired of waiting for suspend/resume (something like that) Curt <curty@free.fr> - 2018-02-01 21:00 +0100
                  Re: Got tired of waiting for suspend/resume (something like that) Sven Hartge <sven@svenhartge.de> - 2018-02-01 22:10 +0100
                    Re: Got tired of waiting for suspend/resume (something like that) Curt <curty@free.fr> - 2018-02-02 10:40 +0100
                      Re: Got tired of waiting for suspend/resume (something like that) Sven Hartge <sven@svenhartge.de> - 2018-02-02 11:30 +0100
                      Re: Got tired of waiting for suspend/resume (something like that) Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-02-03 11:00 +0100

Page 1 of 2  [1] 2  Next page →

#191830 — Re: Got tired of waiting for suspend/resume (something like that)

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [next] | [standalone]

#191832

On 2018-02-01, Nicolas George <george@nsup.org> wrote:
>
> 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

[toc] | [prev] | [next] | [standalone]

#191833

On 2018-02-01, Curt <curty@free.fr> 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


???

Also 'RESUME=none'?
-- 
“True terror is to wake up one morning and discover that your high school class
is running the country.” – Kurt Vonnegut

[toc] | [prev] | [next] | [standalone]

#191834

On 2018-02-01, Curt <curty@free.fr> wrote:
> On 2018-02-01, Curt <curty@free.fr> 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

[toc] | [prev] | [next] | [standalone]

#191836

On 2018-02-01, Curt <curty@free.fr> wrote:
> On 2018-02-01, Curt <curty@free.fr> wrote:
>> On 2018-02-01, Curt <curty@free.fr> 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

[toc] | [prev] | [next] | [standalone]

#191835

On Thu 01 Feb 2018 at 13:11:20 (+0000), Curt wrote:
> On 2018-02-01, Curt <curty@free.fr> 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
> 
> 
> ???
> 
> 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.

[toc] | [prev] | [next] | [standalone]

#191839

On 2018-02-01, David Wright <deblis@lionunicorn.co.uk> wrote:
>> 
>> 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

[toc] | [prev] | [next] | [standalone]

#191841

On Thu 01 Feb 2018 at 15:05:10 (+0000), Curt wrote:
> On 2018-02-01, David Wright <deblis@lionunicorn.co.uk> wrote:
> >> 
> >> 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.

[toc] | [prev] | [next] | [standalone]

#191842

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#191843

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#191847

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.

[toc] | [prev] | [next] | [standalone]

#191856

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#191844

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.

[toc] | [prev] | [next] | [standalone]

#191845

On 2018-02-01, Nicolas George <george@nsup.org> 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:

# <target name> <source device>         <key file>      <options>
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-0000: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

[toc] | [prev] | [next] | [standalone]

#191846

On 2018-02-01, Curt <curty@free.fr> wrote:
> On 2018-02-01, Nicolas George <george@nsup.org> 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:
>
> # <target name> <source device>         <key file>      <options>
> 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

[toc] | [prev] | [next] | [standalone]

#191849

Curt wrote:

> Unfortunately my crypttab (which I've never touched or looked at)
> reveals the following:
> 
> # <target name> <source device>         <key file>      <options>
> 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-0000: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

[toc] | [prev] | [next] | [standalone]

#191855

[Multipart message — attachments visible in raw view] — view raw

Curt (2018-02-01):
> Unfortunately my crypttab (which I've never touched or looked at)
> reveals the following:
> 
> # <target name> <source device>         <key file>      <options>
> 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-0000: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

[toc] | [prev] | [next] | [standalone]

#191859

On 2018-02-01, Nicolas George <george@nsup.org> wrote:
>
>> Unfortunately my crypttab (which I've never touched or looked at)
>> reveals the following:

>> # <target name> <source device>         <key file>      <options>
>> 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

[toc] | [prev] | [next] | [standalone]

#191861

Curt <curty@free.fr> 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.)

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#191865

On 2018-02-01, Sven Hartge <sven@svenhartge.de> wrote:
> Curt <curty@free.fr> 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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web