[FIX] no swap on fresh LM19 install with home directory encryption

[Linubi Luinx]

Hi there,

I am new to Linux and Mint was my first install. So far, so good. I have not had serious problems. However, I did detect the warning mentioned in this thread in the terminal when running updates some time ago and started asking myself what it is about.


This is an example that I could later find in a log:

Code: Select all

less /var/log/apt/term.log

Code: Select all

Setting up nemo (4.2.3+tina) ...

Setting up nemo-dbg (4.2.3+tina) ...

Processing triggers for initramfs-tools (0.130ubuntu3.8) ...

update-initramfs: Generating /boot/initrd.img-4.15.0-58-generic

W: initramfs-tools configuration sets RESUME=UUID=975b89bd-218a-4d03-bd1c-504520f97a85

W: but no matching swap device is available.

Processing triggers for linux-image-4.15.0-60-generic (4.15.0-60.67) ...

/etc/kernel/postinst.d/dkms:

* dkms: running auto installation service for kernel 4.15.0-60-generic

   ...done.

/etc/kernel/postinst.d/initramfs-tools:

update-initramfs: Generating /boot/initrd.img-4.15.0-60-generic

W: initramfs-tools configuration sets RESUME=UUID=975b89bd-218a-4d03-bd1c-504520f97a85

W: but no matching swap device is available.

/etc/kernel/postinst.d/zz-update-grub:

Sourcing file `/etc/default/grub'

Sourcing file `/etc/default/grub.d/50_linuxmint.cfg'

Generating grub configuration file ...

I then searched for the warning:

W: but no matching swap device is available.

and found the discussion in this thread.

I then looked at the output of:

Code: Select all

ls /home/.ecryptfs

blkid

cat /etc/fstab

swapon --show

I saw that the UUID was different from the one in the log.


I checked the RESUME=UUID:

Code: Select all

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

[FIX] no swap on fresh LM19 install with home directory encryption


Post by xenopeek » Wed Jul 25, 2018 10:29 am

There is an issue with home directory encryption that causes swap to be misconfigured during installation of Linux Mint 19, if you enabled home directory encryption during installation. This leaves you with swap that doesn't work.


To correct this run the following two commands after logging in to your new Linux Mint 19 installation:

sudo sed -i 's#/target##' /etc/crypttab

sudo sed -i '#^/swapfile#d' /etc/fstab


Finish with the following command:

sudo update-initramfs -u

...did not seem to fix it. I checked the RESUME=UUID again:

Code: Select all

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

It was still the same. So, I did the following, using the correct swap UUID from the previous blkid/fstab output:

Code: Select all

echo RESUME=UUID=0a5c80b4-ae6a-4475-944d-b160529b07be  | sudo tee /etc/initramfs-tools/conf.d/resume

Code: Select all

cat resume

showed me that it had changed. Then I did:

Code: Select all

sudo update-initramfs -c -k 'all'

reboot

So far everything is o.k. I am not really sure if it was necessary to do the fixing, but it seems at least that I did not break anything. Time will tell if that warning reappears. I will try to find out how to check if the swap is working correctly. Maybe someone can give me some advice?

Kind regards,

Linubi

[gm10]

Welcome to Mint!

So far everything is o.k. I am not really sure if it was necessary to do the fixing, but it seems at least that I did not break anything. Time will tell if that warning reappears. I will try to find out how to check if the swap is working correctly. Maybe someone can give me some advice?

That configuration file is only needed to resume from hibernation/hybrid sleep. It would get updated automatically if you ever initiated either of those (they are disabled by default in LM 19.x). So no, this did not need fixing, but you fixed it correctly regardless.

By the way, I see why you posted in this thread but it really has got nothing to do with the thread's topic.

[rene]

So no, this did not need fixing, but you fixed it correctly regardless.

Note, an unknown UUID in /etc/initramfs-tools/conf.d/resume adds 30 seconds to the boot until the initramfs times out on it, so, yes, you do want to have that file list a correct UUID (or simply RESUME=none) and regenerate the initramfs.

[gm10]

So no, this did not need fixing, but you fixed it correctly regardless.

Note, an unknown UUID in /etc/initramfs-tools/conf.d/resume adds 30 seconds to the boot until the initramfs times out on it, so, yes, you do want to have that file list a correct UUID (or simply RESUME=none).

Fair enough, I do have read that before. I could never reproduce it myself though, I experience no delays with a wrong UUID in there. Either way, it certainly cannot hurt to put the correct one in.

[rene]

Actually, after writing I thought I'd better check that and found that my statement is untrue on 19.2 (Cinnamon, 64-bit) upgraded since 19. It certainly was true on 19 or 19.1; ran into that a few times. Not sure what's going on there, but current status seems to be different from back then.

[gm10]

Actually, after writing I thought I'd better check that and found that my statement is untrue on 19.2 (Cinnamon, 64-bit) upgraded since 19. It certainly was true on 19 or 19.1; ran into that a few times. Not sure what's going on there, but current status seems to be different from back then.

Thanks for verifying! I don't know for sure about 19 but I know it wasn't true on 19.1, either, because that's when I wrote my guide for hibernating to a swap file and experimented with that setting a bit. Could have been a bug in the kernel or initramfs-tools though, maybe an earlier version had trouble with this.

[Linubi Luinx]

Thanks for the replies!
Regarding the boot, I did look at this before the fix:

Code: Select all

systemd-analyze

Can I find a log of the output somewhere?

So, I could compare it to the current output...

[rene]

I'm intrigued now so I'll be installing 19 into a VM for a bit now...

[Linubi Luinx]

By the way, I certainly did not mean to post off-topic. I just thought the problem might be related. Now, I do not want to lead astray either, I just feel curious about all this. If deemed necessary, I will create another thread...

[Linubi Luinx]

by rene » Sun Sep 08, 2019 10:24 am
I'm intrigued now

Soulmate?

[catweazel]

By the way, I certainly did not mean to post off-topic. I just thought the problem might be related. Now, I do not want to lead astray either, I just feel curious about all this. If deemed necessary, I will create another thread...

Yes, create a new thread. Also read the forum rules.

[rene]

Yes, recreated the 30-second boot timeout on Mint 19 Xfce in VB. That also immediately means I'm de-intrigued though; wasn't misremembering; apparently just an obscure, since fixed buglet.

[gm10]

Yes, recreated the 30-second boot timeout on Mint 19 Xfce in VB. That also immediately means I'm de-intrigued though; wasn't misremembering; apparently just an obscure, since fixed buglet.

Noted, thanks. For bonus points try to upgrade the kernel and see if the issue goes away. Assuming you are still a little bit intrigued that is.

[rene]

As to 19.1, no, thanks, I'll take your word for it. Also kernel is not going to be of use; it's a (initramfs) userspace thing: if you hit Esc to get the boot splash out of the way you actually see it saying "giving up waiting for resume device to become available" or some such. I vaguely remember checking fuller at the time and finding it to be an explicit 30 second timeout in a script.

[Drygar_2016]

Hello,

Is this issue fixed in 19.3 releases ?


I can see that this "bug" has been mentioned here and in the official release notes of v 19 > https://linuxmint.com/rel_tara_xfce.php
But it is not mentioned in the newer releases like 19.1 , 19.2 and 19.3 - example -> https://linuxmint.com/rel_tricia_xfce.php

Does this mean this bug is no longer present in LM 19.3 (fixed from 19 in later versions) ?

Thanks