Showing posts with label LUKS. Show all posts
Showing posts with label LUKS. Show all posts

Wednesday, December 30, 2015

Ubuntu and software RAID, getting a device path that won't change from boot to boot

While I love mdadm (software RAID), it's perplexing me at the moment as it keeps changing its device number under Ubuntu.  When I created the array, I created it as "md100", but whenever I restart it ends up as "md127" (and could end up as something else!).  Normally, this doesn't matter, but I'm doing LVM on LUKS, so I need a static (unchanging) path to the array device.

This is a (4) disk array, running mdadm's raid10, and was created with the command:

$ sudo mdadm --create /dev/md100 --raid-devices=3 --spare-devices=1 --level=raid10 /dev/sd[bcde]1

After creating the array, I can check the details with:

$ sudo mdadm --detail --scan /dev/md100

ARRAY /dev/md127 metadata=1.2 spares=1 name=freya:100 UUID=deafbeef:deadbeef:beafdeff:beaffffa

Notice the "name=freya:100".  That's the key to finding a static path to the array.  If I then look under the /dev/md directory, I will see:

$ ls -l /dev/md
total 0
lrwxrwxrwx 1 root root 8 Dec 30 08:15 freya:100 -> ../md127

That means the static path to this array is "/dev/md/freya\:100" and I can use LUKS format on it with:

$ sudo cryptsetup -y -v luksFormat /dev/md/freya\:100

Alternate, I can search for the UUID in the /dev directory and find:

$ sudo find /dev -name '*deafbeef*'
/dev/disk/by-id/md-uuid-deafbeef:deadbeef:beafdeff:beaffffa

I can then add a LUKS keyfile to the device and unlock the device at boot by listing it in the /etc/crypttab file.  Either path will work, but the colons (:) will likely have to be escaped in /etc/crypttab.

PS: Yes I've tried putting the array line in the /etc/mdadm/mdadm.conf file as just "ARRAY /dev/md100 UUID=deafbeef:deadbeef:beafdeff:beaffffa", which is supposed to fix the issue.

PS #2: It's interesting that the mdadm UUID appears in /dev/disk/by-id and not /dev/disk/by-uuid.


Wednesday, August 14, 2013

LUKS: /dev/mapper "read failed after 0 of 4096 at 0: Input/output error"

We're using external USB drives for our backups, protected using LUKS/cryptsetup. On our 3-4 year old Opteron 2210 HE CPU running at 1.8GHz, we estimate that LUKS can perform about 60-70 MB/s per CPU core. We mount the LUKS volumes automatically (at server boot) by listing them in /etc/cryptsetup and using a key-file instead of having to enter a password and autofs handles the automatic mounting/dismounting of the ext4 file system inside the LUKS volume.

It all works very well, until you remove the USB device and then run pvscan/lvscan commands of LVM. Which then throws the following errors:
# pvscan
  /dev/mapper/USBOFFSITE12B: read failed after 0 of 4096 at 999201636352: Input/output error
  /dev/mapper/USBOFFSITE12B: read failed after 0 of 4096 at 999201693696: Input/output error
  /dev/mapper/USBOFFSITE12B: read failed after 0 of 4096 at 0: Input/output error
  /dev/mapper/USBOFFSITE12B: read failed after 0 of 4096 at 4096: Input/output error
  PV /dev/md12   VG vg13   lvm2 [2.67 TiB / 821.62 GiB free]
  Total: 1 [2.67 TiB] / in use: 1 [2.67 TiB] / in no VG: 0 [0   ]

If 'autofs' would allow us to execute a script after it dismounts the drive from inactivity, it might be a good option for us. But I'm not sure that is possible.

Another option would be that at the end of the daily backup script which copies files off to the attached device, we dismount it automatically.

A third option would be to check every hour and see whether the /dev/mapper/NAME is no longer in use, then tell cryptsetup to dismount it. The command to check that might be "dmsetup ls --tree -o uuid,open | grep -i 'CRYPT-LUKS'".

Still exploring options at this point. I need to do some more testing first. I'm also searching for a way to auto-open LUKS volumes upon device insertion.