Messing around with swap and encrypted swap made my system boot 1 minute and 40 seconds longer

I've been experimenting with swaps and I have reformatted my swap drive to include encryption for it so my system do not need to leak encrypted data while unencrypted on the swap partition. I have made the reformatting with Gnome Disk and everything seemed to work, except it didn't. First I made a swap-enc partition, then when I experienced it doesn't get mounted automatically at boot as dev/sda3, I have decided to just simply disable the mounting of the swap. I have head to Gnome Disks, and reformatted again, the only difference now it is unencrypted (not secured by LUKS). It was all good and everything, it doesn't mount automatically except systemd seems to search for the old partition which doesn't exist anymore. I was left with no clues since fstab indeed contained swap-enc, but after I removed it, I don't know what to do. It's still the same. I can't find anything where to change or remove things, systemd seemingly wants to mount non-existent volumes. Please help me as my boot is very slow right now.

Logs:

 Timed out waiting for device /dev/disk/by-uuid/dab49aea-e556-4b17-adcb-042555cbdb67.
 Dependency failed for Cryptography Setup for swap-enc.
 Dependency failed for Local Encrypted Volumes.
 cryptsetup.target: Job cryptsetup.target/start failed with result 'dependency'.
 systemd-cryptsetup@swap\x2denc.service: Job systemd-cryptsetup@swap\x2denc.service/start failed with result 'dependency'.
 dev-disk-by\x2duuid-dab49aea\x2de556\x2d4b17\x2dadcb\x2d042555cbdb67.device: Job dev-disk-by\x2duuid-dab49aea\x2de556\x2d4b17\x2dadcb\x2d042555cbdb67.device/start failed with result 'timeout'.
 Reached target Block Device Preparation for /dev/mapper/swap-enc.
 Reached target System Initialization.

blkid shows the swap uuid and fstab uuid match.

What is the output of

sudo nano /etc/fstab

#
# 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/vgzorin-root /               ext4    errors=remount-ro 0       1
# /boot was on /dev/sda2 during installation
UUID=c4ef9df9-7dc6-4a6c-9249-e404e7488e31 /boot           ext4    defaults        0       2
# /boot/efi was on /dev/sda1 during installation
#UUID=61F9-B11A  /boot/efi       vfat    umask=0077      0       1
UUID=92D5-376E  /boot/efi       vfat    defaults      0       1
/dev/disk/by-uuid/EEB46F25B46EF00F /mnt/EEB46F25B46EF00F ntfs nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=Adat,rw,user,exec 0 0

I don't see a swap mount in your fstab, which indicates that it is not attempting to mount it. What is device uuid: EEB46G25B46EF00F? If that was your swap partition, simply comment out that entry by adding # to the front of that line (the last line). Using an NTFS partition is not recommended for swap.

A look at your partitions in Gnome Disks or Gparted may give us a better understanding of how things are configured.

1 Like

EEB46G25B46EF00F is another hard drive used by me to store my old files.
The thing is which confuses me, swap has the UUID: a40e7bdd-245b-4d89-98a7-f96fd58b05fa and /dev/disk/by-uuid/dab49aea-e556-4b17-adcb-042555cbdb67 seem to be non-existent anywhere I go. Not in fstab, not in grub files, systemd files, not in /dev/disk..
Seems like there is no trace to it. I have removed swap-enc from fstab however back then when I was reformatting (and deleting it).

Gnome Disks shows the swap, but Gparted doesn't even seem to pick it up at all.

It seems to me as systemd / cryptsetup wants to mount this something out of nothing but thin air.

You can try to delete the swap partition and recreate it. This will force Zorin to create a new UUID. You could also manually add the entry to the fstab. As I neither use encryption nor a swap partition, I'm afraid I will be of little help without further investigation into both.

Your NTFS drive may be less problematic with the ntfs-3g driver rather than the ntfs (right after the mount point in the fstab). Though, if the drive isn't giving you any issues, you have no need to change it.

Already tried, didn't help. As I was digging through stuff, I've found some things but those seems overly complicated to me and not even sure it works on my system. (Arch forums)

1 Like

Does the swap have to be encrypted, or are you ok with a script that would overwrite the partition on shutdown instead?

Are you using hibernation on this computer? I ask as this is, really, the only need for a swap partition. Otherwise, the system created swap file should be more than adequate to handle anything beyond your RAM capacity.

In fact, I don't need swap at all. It seems to only freeze my systems occasionally when I run out of ram instead of the kernel terminating the processes. Without swap it seem to terminate correctly as far as I've seen it. And in fact, I don't even use the swap anymore, but that is unrelated since the swap-enc should not be mounted anymore at all, because it is NON-EXISTENT.

When I still have had the swap-enc partition it was done by Gnome Disks. I had added to the arguments (fstab) LUKS because it was an encrypted partition with a swap partition inside it. It got also nofail argument and was set to automatically mount at system start. However, systemd never asked for that one's password and was eventually timed out. Okay, fine. Then I head to reformatting that partition to non-encrypted non-LUKS bare bones swap. And the thing is mounting that exact same drive didn't disappear. I tried to remove it from fstab, and I indeed did remove it, however, systemd is still trying to mount it. This may be a case, because I did not remove the luks entry in fstab aka Gnome Disks arguments and haven't restarded my machine to fix it, but I am not sure.

I have tried getting into root dir with chroot and running mkinitrd but Zorin did not seem to recognize the command.

I have SOLVED IT!

The elephant in the room was cryptsetup. While I was reformatting the partition in Gnome Disks, apparently GD forgot to detach it from cryptsetup, and systemd wanted to mounted like it was still there. I've found the corresponding files in /etc/crypttab and there it was, the error.

# Output of /etc/crypttab
sda3_crypt UUID=46c7f116-6331-4d13-875e-daf3a1c1decb none luks,discard
swap-enc UUID=dab49aea-e556-4b17-adcb-042555cbdb67 none luks,discard

I have removed swap-enc UUID=dab49aea-e556-4b17-adcb-042555cbdb67 none luks,discard and everything went fine again. Systemd does not want to mount that anymore. The boot procedure is fine again, it is super fast. :slight_smile:

I recommend the Zorin OS developers taking a look at this issue, because this is one of the many things why Linux is not suitable yet for beginners.

Anyways thanks to everyone who helped me, even a little bit. I appreciate you.

2 Likes

I'm glad you got it sorted. As many of us don't use luks, zfs, btrfs or the like, it is a bit of trial and error. I didn't consider it, but it makes sense that luks keeps a config file for a list of encrypted partitions and that gnome disks may not access or remove this entry, only really concerned with the fstab since it's a system file necessary for boot.

If luks was integrated more and more commonly used, this would be less of an issue.

Unfortunately, this is beyond the Zorin Group's ability to fix programmatically as the gnome desktop and integrated software is the issue.

The only bad thing about Linux is that so many have contributed and not all other software is considered. Maybe a mention to gnome developers may help, though the way they respond to most user feedback, I doubt it.

1 Like

Zorin Group stated they do upstream merges :wink:

Contribute more upstream.

When Zorin OS improves, so should the Linux desktop ecosystem as a whole. As we upgrade the underlying technologies, we endeavor to submit our patches to the original developers so all users benefit.

source: Why pay for Zorin OS - Zorin OS
1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.