Clean out failed encrypted partition attempts (with YaST) on removable drive

English Install/Boot/Login
1

Using Leap 15.4 and about install Leap 15.5 so my problem may fix itself but I am curious as to how to fix this otherwise.
Using YaST partioner to set up a GPT partition table on a USB disk with one normal and one encrypted EXT4 partition. After a couple of failed attempts setting up the encrypted partition I ended up with both partitions on the removable drive but crypto_LUKS not set up to mount and access the encrypted partition. Note that the output from lsblk -f shows the encrypted partition on sde2 but not the failed attempts that used sdb2 and sdc2. The failed mapper device files still exist. If I plug the drive into another computer, both partitions are available. How do I clean out these failed attempts and hopefully access the encrypted partition as intended? Is it possible to use YaST partitioner to set up access such that the encrypted partition DOES NOT auto mount when the drive is plugged in but mountable by USER? 95% of the time I will only be accessing the non-encrypted partition.

> lsblk -f
NAME          FSTYPE      FSVER LABEL  UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda                                                                                        
└─sda1        crypto_LUKS 1            e0cb72fa-9485-4d50-a6cc-afcea3e84b45                
  └─cr-auto-3 ext4        1.0   ardisk 71c3582a-9194-48dd-8026-9be217da3b16    371G    54% /home
sde                                                                                        
├─sde1        ext4        1.0   ReSt00 a710d6a5-3ff0-4f6c-bfdd-0093bf4b24a9    1.2T    21% /srv
└─sde2        crypto_LUKS 1            87c639dc-39e4-495b-b5a0-7c7353970604                
nvme0n1                                                                                    
├─nvme0n1p1   vfat        FAT32        C257-AB53                             505.8M     1% /boot/efi
├─nvme0n1p2   crypto_LUKS 1            e11908ca-814f-471a-b051-84ca6af8a04d                
│ └─cr_root   btrfs                    c9d9e227-9106-41d9-bf95-e3d4b4fc73eb  424.5G     8% /usr/local
│                                                                                          /tmp
│                                                                                          /root
│                                                                                          /opt
│                                                                                          /var
│                                                                                          /boot/grub2/x86_64-efi
│                                                                                          /boot/grub2/i386-pc
│                                                                                          /.snapshots
│                                                                                          /
└─nvme0n1p3   crypto_LUKS 1            0a0b066c-9ade-45f3-b942-f5a933b911f5                
  └─cr_swap   swap        1            45fdc0be-f8ba-4ad4-96c3-3eb9a67696a4                [SWAP]
2

I’m having trouble understanding this.

Are you referring to the file in “/dev/mapper”? Are those mentioned in “/etc/crypttab”?

If they are mentioned in “/etc/crypttab”, then you can try:

  • comment out those lines (with a “#” char at the beginning)
  • Then reboot your system.

But I’m not sure if that is what you are trying to do.

You mention “sdb2” and “sdc2” but don’t show those. Are those the same as “sde2” after your retry? Or are those different USB drives?

A little more clarity would help.

3

Yes. ls -l /dev/mapper includes:

crw------- 1 root root 10, 236 Nov  6 19:53 control
lrwxrwxrwx 1 root root       7 Nov 14 12:59 cr_run_media_rs_EReST00 -> ../dm-5
lrwxrwxrwx 1 root root       7 Nov 14 11:20 cr_usb-WD_My_Passport_2626_57584A324135334553585358-0:0-part2 -> ../dm-3
lrwxrwxrwx 1 root root       7 Nov 14 11:34 cr_usr_local -> ../dm-4

One of these appears in:

> sudo cat /etc/crypttab
[sudo] password for root: 
cr-auto-3  UUID=e0cb72fa-9485-4d50-a6cc-afcea3e84b45
cr_root    UUID=e11908ca-814f-471a-b051-84ca6af8a04d  none  x-initrd.attach
cr_swap    UUID=0a0b066c-9ade-45f3-b942-f5a933b911f5
cr_run_media_rs_EReST00  UUID=87c639dc-39e4-495b-b5a0-7c7353970604  none  noauto

EReST00 is the volume label for the (to be) encrypted partition.

All three were produced by the failed attempts and by failure, I mean that after editing the (to be) encrypted partition in YaST partitioner to format (EXT4) and encrypt the partition, I was unable to mount that partition.
Device names sdb2, sdc2, sdd2 and sde2 are associated with the same USB disk drive that was un/plugged between set up attempts.

Commenting out the ‘cr_run_media_rs_EReST00’ in crypttab and rebooting is worth a try after lunch.
The surprising part for me is that when I plugged this drive into a different machine (also Leap 15.4) I was asked for a password, super user ID, and the encrypted partition was mounted as expected.

4

That suggests that you did properly setup that partition.

When I use Yast to setup an encrypted partition on a USB device, I check the box “Do not mount”. I think that avoids getting entries in “/etc/fstab” and in “/etc/crypttab”.

If I have been using an encrypted partition from a USB drive, then I make sure it is unmounted before I unplug. And I also use

# cryptsetup luksClose cr_whatever

(changing that “whatever” to the appropriate name) before unplugging. Otherwise the USB port will be seen as busy, and that would be why your device was changing from “/dev/sdb” to “/dev/sdc” to “/dev/sde”.

5

Well, that didn’t end well. After the comment as suggested, restarting sent me into emergency mode. I uncommented and restarted but still in emergency. Poking around it appears that references to the encrypted partition are scattered in few places such as /run/systemd/generator for example and these may be throwing a spanner into the works. I used to mount encrypted partitions and container files with my own cryptsetup scripts but became used to the convenience of YaST (and it worked). I agree with the precautions you mentioned but it is easy to drop the ball and not unmount. I don’t expect that trying to fix this installation is worth the time so I may be upgrading a few days sooner than planned. I wish I had done that backup last night.

6

Saved! I deleted reference to those removable volume names within fstab and the system booted. However, rather than fight this issue further, I may proceed with the upgrade this weekend and go from there. Now I will have a recent backup at the start.
Thank you for the suggestions. If I get this working as desired under Leap 15.5, I’ll reply once again with a conclusion.

1 Like
7

For devices not needed during system startup users may always specify noauto or x-systemd.automount:

erlangen:~ # grep -E 'noauto|systemd' /etc/fstab 
UUID=68BA-53B2                             /GARMIN                 vfat   user,noauto                   0  0
UUID=0267-906F                             /GARMIN-KART            vfat   user,noauto                   0  0
LABEL=FR735                                /FR735                  vfat   user,noauto                   0  0
UUID=2f0030b8-7257-4cba-be3e-b33154cda052  /WD25                   ext4   user,noauto                   0  0
//fritz.box/FRITZ.NAS                      /fritz.box              cifs   noauto,username=mistel        0  0
UUID=0e58bbe5-eff7-4884-bb5d-a0aac3d8a344  /Btrbk                  btrfs  subvolid=5,x-systemd.automount,x-systemd.idle-timeout=10 0  0
UUID=8a723ba5-c46f-45df-b708-0cf9c541da27  /Backup                 btrfs  subvolid=5,x-systemd.automount,x-systemd.idle-timeout=10 0  0
UUID=47e6d9ee-e910-4ea4-8c8f-7ac75f49a4d3  /Crucial                btrfs  subvolid=5,x-systemd.automount,x-systemd.idle-timeout=10 0  0
UUID=2260f160-cc05-47cc-9893-cc32c050177d  /Seagate                btrfs  subvolid=5,x-systemd.automount,x-systemd.idle-timeout=10 0  0
UUID=78383e24-1ed7-45ad-9a6b-65b8b98b93c2  /Sandisk                btrfs  subvolid=5,x-systemd.automount,x-systemd.idle-timeout=10 0  0
erlangen:~ #