Lab22.1 Loop devices - /etc/fstab entry

agnieszka

Hello,
maybe anyone can explain the behaviour of loop devices or point me to some literature in this regard.

Basically, when in /etc/fstab I use UUID for a loop device, my machine does not boot and I am put into the emergency mode.

However, when instead I use the full path to the file, the machine boots with no errors.

I am using Xubuntu 18.

/etc/fstab entry:

UUID=36ab310c-d1eb-4746-9456-9526a3a07552 /mnt/secret ext4 loop 1 2 [my machine won't boot and the journal shows:
mnt-secret.mount: Job mnt-secret.mount/start failed with result 'dependency'.

However, when I enter into /etc/fstab the below line, the machine boots up and the file is being mounted:
/home/aga/encrypted /mnt/secret ext4 loop 1 2

Output of df -Th
/dev/loop0 ext4 976M 4,4M 905M 1% /mnt/secret

For UUID I check sudo blkid
/dev/loop0: UUID="36ab310c-d1eb-4746-9456-9526a3a07552" TYPE="ext4"

losetup -a output
/dev/loop0: []: (/home/aga/encrypted)

file info:
encrypted: Linux rev 1.0 ext4 filesystem data, UUID=36ab310c-d1eb-4746-9456-9526a3a07552 (needs journal recovery) (extents) (64bit) (large files) (huge files)

So I am not sure, why I cannot use UUID in this situation.
Any ideas?
Thank you,
Aga

agnieszka

I would also be very grateful if anyone could instruct me how to set up an encrytpted partition on loop device PERSISTENTLY .
What exactly should be entered into the /etc/crypttab and /etc/fstab files?

My understanding is that after every reboot loop device is lost and no longer attached to the file.
Therefore, my encrypted partition under /dev/mapper/secret-disk also ceases to exist and so cannot be mounted on boot.

systemd[1]: Failed to start Cryptography Setup for secret-disk.
systemd[1]: Dependency failed for dev-mapper-secret\x2ddisk.device.
systemd[1]: Dependency failed for /secret.
systemd[1]: secret.mount: Job secret.mount/start failed with result 'dependency'.
systemd[1]: Dependency failed for File System Check on /dev/mapper/secret-disk.
systemd[1]: systemd-fsck@dev-mapper-secret\x2ddisk.service: Job systemd-fsck@dev-mapper-secret\x2ddisk.service/start failed with result 'dependency'.
systemd[1]: dev-mapper-secret\x2ddisk.device: Job dev-mapper-secret\x2ddisk.device/start failed with result 'dependency'.
systemd[1]: Starting Cryptography Setup for secret-disk...
systemd[1]: systemd-cryptsetup@secret\x2ddisk.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: systemd-cryptsetup@secret\x2ddisk.service: Failed with result 'exit-code'.
systemd[1]: Failed to start Cryptography Setup for secret-disk

Cheers,

luisviveropena

Hi,

I'm a kind of confused here because Lab 22.1 is about Disk Encryption, but your original question is about a loop device and using UUID on /etc/fstab .

Can you clarify, please?

Regards,
Luis.

coop

https://unix.stackexchange.com/questions/513979/mounting-loop-not-working-with-uuid

I believe this is correct -- I have never tried to mount a loopback device by uuid. How would the system know what it is? You have to mount the filesystem, then find the file etc.

As far as the encrypted partition being loaded persistently, I am not sure what the problem is as the instructions in the lab have been working for quite some time. Please read the instructions carefully, and please tell us exactly what distribution and version you are using etc.

agnieszka

I am able to follow the instruction and it works when a 'standard' partition is being used such as eg. /dev/sda4.

I am able to make an encrypted partition on a loop device and mount it, however, everything is lost after reboot. Hence, my question re /etc/fstab: what should be put there when we use a loop device for the encrypted partition.

When I reboot, I am put into the emergency mode and the encrypted partition is not mounted. For me, it seems that after the reboot /dev/mapper/secret-disk does not exist.
I am guessing that the loop device to which the encrypted partition is attached is lost after the reboot and that is why the encrypted partition fails to mount but I am not sure if my conclusion is correct.

coop

Ok, think about what you are trying to do. You can indeed mount a loopback device at boot if you are careful by doing something like:

/pathto/imagefile /place/tomount ext4 loop 0 0

to mount an ext4 loop back device at /place/tomount. Note that this has to be done after whatever partition the mount directory has already been mounted (so late in /etc/fstab) but even that is not guaranteed to work depending
on your system setup and distribution since parallel mounts can be allowed. (There is probably a more complicated way to avoid that I guess.) It will probably show up with *df" as /dev/loop0 on your system. And note the "loop" in the mount option.

However if you wanted this to be encrypted, you would also have to update the /etc/crypttab entry and I don't feel inclined to figure that out at the moment, because I would never do things this way, and it is not an ext4 filesystem you want to look at anyway. If you are going to be prompted for a password at boot why do it this way?

Whenever I have done this sort of thing, I have a a very short lines script (maybe two lines) that can be executed at boot (using systemd would be best) or even better just at the command line. It is pretty useless having an encrypted filesystem that anyone can see at boot without supplying a password. It doesn't seem useful to me except as an academic challenge question. If the whole system is encrypted why bother encrypting the loopback file?

lee42x

Maybe I can help clarify a little:

Can I use a UUID to mount a loop device in fstab?
NOPE. Use the file that contains the file system.
like:
\home\lee\loop.img \home\lee\loopy ext4 loop 0 0

Can I use a loop device as the locked encrypted device?
Yes but not with fstab. The crytptab file is read before the mount and the loop device doesn't exist yet, so it fails.
Why does this work with partitions like "/dev/sda6" ? When the crypttab file is processed it locates the "block device" and attempts a "luksOpen" on the device and registers the "unlocked"device with portmapper. The crypttab file is the connection between the encrypted block device an portmapper name.

The information (filesystem) on the loop.image file and the unencrypted partition is not lost, the components just need reassembly.

Is this a limitation/bug?
No, not really. We use the loop devices in class to reduce the requirement of "un-partitioned" space on the disks and loop devices work well for learning and experimenting. There is a more complex answer as to "how to make it work" involving systemd-generate and pre-executions scripts in the boot/mount sequence but I would not recommend it.

If you are using loop devices because you are out of disk space, try using a USB key as an additional disk.

Lee

luisviveropena

The explanation of Lee is great!

I was researching and I found that cryptsetup (and then dm-crypt) doesn't like loop devices. From man cryptsetup(8):

'In addition, cryptsetup provides limited support for the use of loop-AES volumes and for TrueCrypt compatible volumes'.

I think you need to ask yourself 'why do I want to encrypt a loop device?' and 'why do I want to make it permanent?'. So, loop devices -as Lee said- have been used for testing purposes, as it's easier to make a loop device than make free space in the local storage.

Also, as Coop mentioned, there are some prerequisites that could be difficult to achieve. But it's also a good change to learn and to challenge yourself

Regards,
Luis.

agnieszka

Thank you all for your explanation.
I was trying to use a loop device as I did not have any spare partition and the instruction indicated that a loop device can be used.
I have learnt a lot.
Thanks again

luisviveropena

Hi @agnieszka ,

Ok, I see now. Well, we all continue learning, and it's ok to try to do things that are more complex than others. As you said, you learnt a lot in the process, and that's awesome.

Regards,
Luis.

PRopiy

Can I use a loop device as the locked encrypted device?
Yes but not with fstab. The crytptab file is read before the mount and the loop device doesn't exist yet, so it fails.
Why does this work with partitions like "/dev/sda6" ? When the crypttab file is processed it locates the "block device" and attempts a "luksOpen" on the device and registers the "unlocked" device with portmapper. The crypttab file is the connection between the encrypted block device an portmapper name.

Lee

Thank's a lot for your explanation.