[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Change for systemd the UUID of the home partition, how to?



On 10/06/15 09:48 AM, Sven Arvidsson wrote:

What does your /etc/fstab look like?

Like this:

<file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/BDS1-root /               ext4    errors=remount-ro 0       1
/dev/mapper/BDS1-boot /boot           ext2    defaults        0       2
/dev/mapper/BDS1-home_crypt /home ext4 defaults 0 2
/dev/mapper/BDS1-tmp_crypt /tmp            ext2    defaults        0       2
/dev/mapper/BDS1-var /var            ext4    defaults        0       2
/dev/mapper/BDS1-swap_crypt none swap sw 0 0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0
UUID=640F-A4A6  /media/fda      vfat    rw,user,noauto,noatime  0       0
UUID=27AD-9963  /media/fdb      vfat    rw,user,noauto,noatime  0       0
UUID=FC68-7915  /media/fdc      vfat    rw,use,rnoauto,noatime  0       0
UUID=E883-A903  /media/fdd      vfat    rw,user,noauto,noatime  0       0
UUID=9016-4EF8  /media/sdd      vfat    rw,user,noauto,noatime  0       0

The basic construction is a RAID1 (two 1 tb hard drives) which form the only physical volume for LVM2, and there is only one virtual volume BDS1 in this physical volume. This virtual volume has six logical volumes, all beginning with BDS1. Three of these are encrypted; swap with a random passkey, and /tmp and /home with their own passkeys.

When I first installed Jessie in the box, I assigned all the space in the virtual volume to these six logical volumes. At the partitioning phase of the installation the space assigned to the /var partition I based on what I had done for Squeeze and Wheezy. That size proved too small for Jessie.

To enlarge the size for the /var for Jessie I first had to reduce the size for /home. I found on line instructions as to how to do so. Those instructions unfortunately did not tell me that the crypt has to be resized as well as the file system and the logical volume. The result was that the all the data in the /home partition were obliterated. Fortunately I had backed up all of them.

The new encrypted /home partition that I now had to create has a different UUID. I copied it to file /etc/crypttab which now reads as follows:

#BDS1-home_crypt UUID=5ea1826e-2824-4544-a33b-e2c72d65e60e none luks
BDS1-home_crypt UUID=29aeb184-8d5c-4165-824a-2b8a11e477e9 none luks
#BDS1-home_crypt UUID=e59565df-6a23-45fd-af55-5c0b7040eedd none luks
BDS1-swap_crypt /dev/mapper/BDS1-swap /dev/urandom cipher=aes- xts-plain64,size=256,swap
BDS1-tmp_crypt UUID=a9360e7f-7ddb-41c4-9dfe-51a8a41db7e4 none luks

The first line above is commented out because it is the UUID for BSD1-home_crypt which I entered in error. The UUID I entered in the second line is I assume the correct UUID to open BDS1-home_crypt, being in fact the UUID listed by blkid (quoted below) as the UUID for BDS1-home. The third line, commented out, was the UUID of the /home partition before it was resized. The last two lines for swap and /tmp, which I left unchanged.

After resizing the /home and /tmp partitions and rebooting I was not asked to enter the passkeys for these two partitions. Instead the process went to recovery mode. I consequently entered the root password and ran 'journalctl -xb". Here are the major error messages I received:

BSD system-crypt-generator [185]: Failed to create init file /run/systemd/generator.systemd-crypt-setup@BSD1.

BSD systemd [182]: /lib/systemd/system-generator/systemd-cryptsetup-generator failed with error 1.

Then later were two more:

BDS system [1]: Job dev-mapper-BDS1\x2dtmpcrypt.device/start timed out
BDS system [1]: Timed out waiting for device dev-mapper-BDS1\x2dtmp_crypt.device.

These last two were repeated two more times with different device names, \x2dhome_crypt.device and \x2dswap_crypt.device.

So, as I said in my second post, I need to do something to make systemd recognize the UUIDs in the /etc/crypttab file.

The last error message was about something quite different:

BDS system [1]: Failed to start Console System Startup Logging.

Since no logging is being done in a syslog file I take this message to mean that in resizing the /var partition that process was broken. That result may have been caused by the fact that merely booting the computer causes the /var partition to be busy. The only way I could unmount it was by commenting out the /var line in file /etc/fstab and reboot. I could then resize it. Afterwards I commented the /var/ line back in again, thereby causing it to be remounted. So I now also need to know how to reactivate the Console System Startup Logging.

After all these changes I was able to open both the /home and /tmp partitions by running cryptsetup luksOpen. After doing so command blkid produced the following.

/dev/sdb1: UUID="8819eaea-bac1-3907-cbc0-90413f1d9bdb" UUID_SUB="884424dc-ea70-d13c-6c86-4416cb54c39e" LABEL="BDS:0" TYPE="linux_raid_member" PARTUUID="0007499e-01" /dev/sdc1: UUID="8819eaea-bac1-3907-cbc0-90413f1d9bdb" UUID_SUB="7c18a195-38d7-8368-9b1a-6b331cc17620" LABEL="BDS:0" TYPE="linux_raid_member" PARTUUID="0005b623-01"
/dev/md0: UUID="gFyi1a-INIu-YTlD-Rwh2-0oll-KNBV-vpcUQu" TYPE="LVM2_member"
/dev/sdd1: UUID="27AD-9963" TYPE="vfat" PARTUUID="8bd6cc64-01"
/dev/sdi1: UUID="640F-A4A6" TYPE="vfat"
/dev/sde1: UUID="00FF-9E32" TYPE="vfat"
/dev/mapper/BDS1-root: UUID="6689a000-1f11-4908-9704-45aa6999e21d" TYPE="ext4" /dev/mapper/BDS1-var: LABEL="VAR" UUID="6963f032-2b78-479b-9e0e-437f1cc80ff5" TYPE="ext4" /dev/mapper/BDS1-boot: LABEL="BOOT" UUID="9059e019-8a7c-405d-8685-f340609fcff9" TYPE="ext2" /dev/mapper/BDS1-tmp: UUID="a9360e7f-7ddb-41c4-9dfe-51a8a41db7e4" TYPE="crypto_LUKS" /dev/mapper/BDS1-home: UUID="29aeb184-8d5c-4165-824a-2b8a11e477e9" TYPE="crypto_LUKS" /dev/mapper/BSD1-home_crypt: LABEL="HOME" UUID="5ea1826e-2824-4544-a33b-e2c72d65e60e" TYPE="ext4" /dev/mapper/BSD1-home_tmp: LABEL="TMP" UUID="78d0e516-3366-4816-be86-d3cd972e9792" TYPE="ext2"

I was able to compare the UUIDs thereby produced with those in the /etc/fstab and /etc/crypttab files. Unless I made any errors -- always possible -- they are all correct.

One final thought occurred to me -- whether is is necessary to encrypt the /tmp partition. The Lenny installer allowed it to be encrypted with a random key, but subsequent installers do not. Nevertheless, using a random key for it would be easier by eliminating the need to enter two pass keys on boot. It appears that systemd would allow it.

Regards, Ken





Reply to: