[SOLVED] Ubuntu 19.04-> 19.10: Problem with encrypted swap partition

jkcray · 04-15-2020, 03:53 AM

Hi.
I had a bad moment when (belatedly) upgrading Ubuntu 19.04-> 19.10 last weekend.

The upgrade process

do-release-upgrade

complained that it couldn't read my encrypted swap partition and didn't create initrd.img-5.3.0-46-generic in /boot.

In fact I had a broken symlink for

initrd.img -> initrd.img-5.3.0-46-generic

until the very end of the update when (happy days) the installer *did* create initrd.img-5.3.0-46-generic.

(Beer was consumed.)

Can I assume that the same "end of update" fix will work when I upgrade to 20.04 LTS?

My /etc/fstab

Code:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/ubuntu--vg-root / ext4 errors=remount-ro 0 1
# /boot was on /dev/sda1 during installation
UUID=91ee4872-1d44-431b-b56e-62a0c8e5e5d1 /boot ext2 defaults 0 2
#/dev/mapper/ubuntu--vg-swap_1 none swap sw 0 0
/dev/mapper/cryptswap1 none swap sw 0 0

My /etc/crypttab

Code:

sda5_crypt UUID=f06d7a31-34bb-4911-99b0-d91c272350a5 none luks,discard
cryptswap1 UUID=07ebc8c9-dd82-4e61-b64b-160e0b63a811 /dev/urandom swap,offset=1024,cipher=aes-xts-plain64

Joseph Borg posted that the best way to deal with this problem is

Quote:

After you've run `do-release-upgrade -d`:

1) sudo swapoff -a
2) sudo cryptsetup remove cryptswap1
3) Edit `/etc/fstab`, remove the line mentioning cryptswap1
4) Edit `/etc/crypttab `, remove the line mentioning cryptswap1
5) sudo update-initramfs -u
6) sudo update-grub
7) Reboot

Or maybe not a problem at all?

Advice very much appreciated.

John

dna9 · 04-16-2020, 03:20 PM

are you dual booting? did you do a "cold" boot and totally power off the computer for a couple minutes? does a swap partition need to be encrypted? just asking. i have had gremlins after updating and when i do a cold boot things got fixed. 20.04 final is right around the corner and we will see.

jkcray · 04-17-2020, 04:10 AM

Quote:

Originally Posted by dna9

are you dual booting? did you do a "cold" boot and totally power off the computer for a couple minutes? does a swap partition need to be encrypted? just asking. i have had gremlins after updating and when i do a cold boot things got fixed. 20.04 final is right around the corner and we will see.

Hi dna9, thanks for the reply.

This issue seems to be very obscure - the post by Joseph Borg (on a different forum) is the only relevant material that I found.

Essentially I had a standard install of Ubuntu 19.04 on my laptop (HP8440p) with no dual boot.

What is apparently unusual is that my swap partition is encrypted (as is my home partition):

Code:

$ df|grep -v snap
Filesystem                  1K-blocks      Used Available Use% Mounted on
udev                          3925804         0   3925804   0% /dev
tmpfs                          793880      2076    791804   1% /run
/dev/mapper/ubuntu--vg-root 476173360 231602020 220360092  52% /
tmpfs                         3969400    266516   3702884   7% /dev/shm
tmpfs                            5120         4      5116   1% /run/lock
tmpfs                         3969400         0   3969400   0% /sys/fs/cgroup
/dev/sda1                      482922    274399    183589  60% /boot
tmpfs                          793880       128    793752   1% /run/user/1000
/home/myname/.Private         476173360 231602020 220360092  52% /home/myname

This all works/worked fine but when I updated to 19.10 using

Code:

$ sudo apt update 
$ sudo apt upgrade
$ sudo apt dist-upgrade
$ sudo apt autoremove
$ sudo do-release-upgrade

the install went fine but (as I posted above)

Quote:

The upgrade process

do-release-upgrade

complained that it couldn't read my encrypted swap partition and didn't create initrd.img-5.3.0-46-generic in /boot.

But at the very end of the upgrade, it *did*, to my great relief.

I'll certainly follow your advice re doing a cold reboot before updating to 20.04.

But should I change to an un-encrypted swap partition before that?

And is it safe to use Joseph Borg's suggested procedure

Code:

After you've run `do-release-upgrade -d`:

1) sudo swapoff -a
2) sudo cryptsetup remove cryptswap1
3) Edit `/etc/fstab`, remove the line mentioning cryptswap1
4) Edit `/etc/crypttab `, remove the line mentioning cryptswap1
5) sudo update-initramfs -u
6) sudo update-grub
7) Reboot

to do so?
Many thanks,
John

dna9 · 04-18-2020, 12:57 PM

if everything came back up and booted fine then that's awesome. all i'm saying is a swap file shouldn't need to be encrypted. it is nothing more than a file on a hard disk used to provide space for programs which have been transferred from the processor's memory. cheers!

ondoho · 04-18-2020, 03:04 PM

Quote:

Originally Posted by jkcray

And is it safe to use Joseph Borg's suggested procedure

Code:

After you've run `do-release-upgrade -d`:

1) sudo swapoff -a
2) sudo cryptsetup remove cryptswap1
3) Edit `/etc/fstab`, remove the line mentioning cryptswap1
4) Edit `/etc/crypttab `, remove the line mentioning cryptswap1
5) sudo update-initramfs -u
6) sudo update-grub
7) Reboot

I have no idea whether it's "safe", but it's fairly obvious what it does.
I wonder why the encrypted swap needs to be disabled before updating the initramfs.
Also, it looks to me like this will keep any sort of swap OFF after a reboot,no?

jkcray · 04-19-2020, 05:20 AM

Quote:

Originally Posted by ondoho

I have no idea whether it's "safe", but it's fairly obvious what it does.
I wonder why the encrypted swap needs to be disabled before updating the initramfs.
Also, it looks to me like this will keep any sort of swap OFF after a reboot,no?

I suppose I was asking whether there was any need to follow Joseph Borg's suggestion?

My initramfs for the new kernel was only generated at the very end of a (2 hour) update following multiple errors related to my encrypted swap partition leading to the initramfs not being generated.

Obvious I could have manually generated the initramfs if the updater had not done so at the last minute..

But if encrypted swap partitions are deprecated it would be nice to know!

Many thanks for your comments.

ondoho · 04-21-2020, 12:45 AM

Did you create that encrypted swap manually, or is it something Ubuntu offers to do for you?
Are you aware that swap is encrypted automatically when it resides inside an encrypted volume group?
Why is that line in /etc/fstab apparently edited later?

I use encrypted swap and it does not affect kernel updates or initramfs in any way.
But that's not on Ubuntu.
Are you aware that 19.04 and 19.10 are beta versions?
If you don't feel competent to deal with small problems you shoudl stick to the LTS releases. I'm not saying that condescendingly, I would personally never consider using anything but *buntu LTS.

Quote:

Originally Posted by jkcray

But if encrypted swap partitions are deprecated it would be nice to know!

How could that be "deprecated"? No, they're not.

jkcray · 04-21-2020, 04:00 AM

Quote:

Originally Posted by ondoho

Did you create that encrypted swap manually, or is it something Ubuntu offers to do for you?
Are you aware that swap is encrypted automatically when it resides inside an encrypted volume group?
Why is that line in /etc/fstab apparently edited later?

I use encrypted swap and it does not affect kernel updates or initramfs in any way.
But that's not on Ubuntu.
Are you aware that 19.04 and 19.10 are beta versions?
If you don't feel competent to deal with small problems you shoudl stick to the LTS releases. I'm not saying that condescendingly, I would personally never consider using anything but *buntu LTS.

How could that be "deprecated"? No, they're not.

Thanks for that. No condescension detected! I'm aware of my limitations and am happy to acknowledge them..

I had some difficulty 2-3 years ago getting Ubuntu to install on my old hp (HP8440p) laptop due to UEFI issues.

I should have stayed with 18.04 LTS but (mistake for sure) migrated to 19.04 as it (again a mistake) seemed a good idea at the time.

I updated (not a mistake) to 19.10 as it keeps security up to date, pending release of 20.04 LTS.

Encrypted swap partition seemed a reasonable choice when installing 18.04 and (I don't remember the details) I went for it.

My query boils down to "why did the 19.04->19.10 update have a problem generating an initramfs while complaining that I have (as I do) an encrypted swap partition?"

Here is an early snippet from my apt-term.log: (this is the error that worried me)

Code:

update-initramfs: Generating /boot/initrd.img-5.0.0-38-generic
cryptsetup: ERROR: Couldn't resolve device 
    UUID=efeee2ee-c1e4-45b3-a034-c0ee08ca8947
W: initramfs-tools configuration sets RESUME=UUID=efeee2ee-c1e4-45b3-a034-c0ee08ca8947
W: but no matching swap device is available.
update-initramfs: Generating /boot/initrd.img-5.0.0-37-generic
cryptsetup: ERROR: Couldn't resolve device 
    UUID=efeee2ee-c1e4-45b3-a034-c0ee08ca8947
W: initramfs-tools configuration sets RESUME=UUID=efeee2ee-c1e4-45b3-a034-c0ee08ca8947
W: but no matching swap device is available.

and another snippet later in the install from apt-term.log:

Code:

Setting up linux-image-5.3.0-46-generic (5.3.0-46.38) ...
I: /boot/vmlinuz.old is now a symlink to vmlinuz-5.0.0-38-generic
I: /boot/initrd.img.old is now a symlink to initrd.img-5.0.0-38-generic
I: /boot/vmlinuz is now a symlink to vmlinuz-5.3.0-46-generic
I: /boot/initrd.img is now a symlink to initrd.img-5.3.0-46-generic

I now have initrd.img -> initrd.img-5.3.0-46-generic in /boot and of course uname -a gives

Code:

uname -a
Linux john-HP-EliteBook-8440p 5.3.0-46-generic #38-Ubuntu SMP Fri Mar 27 17:37:05 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

so all OK.

But the error:

Code:

cryptsetup: ERROR: Couldn't resolve device 
    UUID=efeee2ee-c1e4-45b3-a034-c0ee08ca8947
W: initramfs-tools configuration sets RESUME=UUID=efeee2ee-c1e4-45b3-a034-c0ee08ca8947
W: but no matching swap device is available.

maybe suggests that my old initrd.img was looking for the wrong UUID for the encrypted swapfile.

There is no UUID=efeee2ee-c1e4-45b3-a034-c0ee08ca8947 on the system.

Hopefully the newly generated initrd.img has the correct swapfile info?

Is there any way to check this?

Many thanks.

jkcray · 04-21-2020, 05:15 AM

I found that my

/etc/initramfs-tools/conf.d/resume

Code:

# RESUME=UUID=b32871a6-edd9-4523-80c7-03e32543f111
RESUME=UUID=efeee2ee-c1e4-45b3-a034-c0ee08ca8947

contains the UUID to a non-existing device/volume.

This is obviously the problem.

Can anyone advise whether I should delete the above file, edit it or "re-generate" it?

Should the RESUME UUID be my (encrypted) swap partition? (I previously had "file" instead of "partition" in this post.)

Or if not then what?

Many thanks.

ondoho · 04-22-2020, 06:06 AM

Quote:

Originally Posted by jkcray

Can anyone advise whether I should delete the above file, edit it or "re-generate" it?

Edit.
Can't hurt to try.

Quote:

Should the RESUME UUID be my (encrypted) swap file?

Wait what, swap file? I thought we're talking about a partition here?

jkcray · 04-22-2020, 10:43 AM

Quote:

Originally Posted by ondoho

Edit.
Can't hurt to try.

Wait what, swap file? I thought we're talking about a partition here?

Sorry, a slip of the finger.
Yes of course an encrypted swap partition.

Thanks.

ondoho · 04-22-2020, 01:54 PM

In that case the answer's yes.

jkcray · 04-23-2020, 03:59 AM

Quote:

Originally Posted by ondoho

In that case the answer's yes.

Just to tidy up the thread (thanks to ondoho for replies)

I plan to edit my

Code:

/etc/initramfs-tools/conf.d/resume

replacing

Code:

# RESUME=UUID=b32871a6-edd9-4523-80c7-03e32543f111
RESUME=UUID=efeee2ee-c1e4-45b3-a034-c0ee08ca8947

by (this is the UUID for my encrypted swap partition)

Code:

RESUME=UUID=07ebc8c9-dd82-4e61-b64b-160e0b63a811

Then I'll run

Code:

sudo update-initramfs -u
sudo update-grub

And.... done.

I'll post (briefly) here when I've done the above and (all going well) I'll mark the thread as SOLVED.

Update: I hope the mods don't mind but I am very dependent on my laptop for work so will postpone a re-boot (which will confirm that the above procedure has completed satisfactorily) until mid-May when the pressure should have eased.

kendallgreen · 04-23-2020, 05:10 PM

I upgraded my Ubuntu to 20.04 using the do-release-upgrade method. Now I can't login to my encrypted system using grub. I can login going directly to the drive and entering the password. I know that the UUID's for the swap and boot drives are correct and have tried to update-initramfs without success. Any other suggestions.

ondoho · 04-24-2020, 04:52 AM

kendallgreen, please open a new thread with a detailed problem description!