Arch Linux

RedForallP

Member

Registered: 2022-11-14

Posts: 1

Automatically creating loop-devices on boot

I need a loop device at login time as pam_mount (and its mount.crypt helper) needs a free loop device to mount a luks-encrypted file.
I followed the the wiki to setup pam_mount , the relevant line in /etc/security/pam_mount.conf.xml looks like:

<volume user="redforallp" fstype="crypt" path="/home/redforallp/sensitive.img" mountpoint="/mnt/sensitive" options="rw,fstype=ext4" /> 

After a reboot, the volume does not get mounted, a look in the journal shows that mount.crypt can't find a free loop device.

mount: could not find any free loop device

Once logged logged in,

 ls /dev/loop* 

only shows /dev/loop-control . True, There are no loop devices.
Running losetup -f as root creates a new one, but I want an automated way to do this...

Some Linux Distributions populate loop devices on boot by default, I wanted to reproduce that behavior.
I searched around but only found the rather cumbersome solution to create a systemd-service which runs after local-fs is reached:

File: /usr/lib/systemd/system/new-loop-device.service

[Unit]
Description=Create one loop device
DefaultDependencies=false
After=local-fs.target
[Service]
Type=oneshot
ExecStart=losetup -f

This service simply executes "losetup -f" and exits, I don't like to have a service for that...
Also: invoking losetup -f is a indirect way to get a loop device, and re-running the service won't create a new loop device unless the old one gets used...

Somebody got a better idea ?

pgoetz

Member

From: Austin, Texas

Registered: 2014-02-21

Posts: 341

Re: Automatically creating loop-devices on boot

I think the correct way to do this is using systemd-tmpfiles; in particular the systemd-tmpfiles-setup-dev service.

There's only one simple step involved.  Create a file /etc/tmpfiles.d/loop.conf containing this line:

b! /dev/loop0  0660  root  disk  -  7:0

That's it.  When you reboot, you will now have a loop device:

[root@gecko ~]# ls -l /dev/loop*
brw-rw---- 1 root disk  7,   0 Feb 28 13:34 /dev/loop0
crw-rw---- 1 root disk 10, 237 Feb 28 13:34 /dev/loop-control
[root@gecko ~]# 

Here is a brief explanation of how this works.  Look at the man page for tmpfiles.d for a full explanation.  The fields in the line are

Type   /file/to/create   Mode   User   Group   Cleanup-Age   Argument

separated by white space. The b at the beginning tells systemd-tmpfiles to create a block device with name /dev/loop0, but only if this device doesn't already exist.  The ! following the b indicates that this line is only safe to execute at boot (otherwise udev can't manage the device). The other fields are self-explanatory save for the last two.  Cleanup-Age applies to situations where files/directories are to be deleted after a certain period of time.  Since this isn't applicable, it's represented by a -.  The argument for block device creation are the major:minor device numbers for the device being created.  The cool thing about this is you can set the user/group to be whatever suits your use case.  Want multiple loop devices? Just add additional similar lines to this file.

Last edited by pgoetz (2023-02-28 20:09:35)

frostschutz

Member

Registered: 2013-11-15

Posts: 1,418

Re: Automatically creating loop-devices on boot

The whole point of loop-control is that everyone can create their own loop device (thousands of them)...

So basically you're saying this mount helper does not support loop devices properly. losetup -f should not help since by the time your mount helper comes along, that loop device might already be used by something else. Or you could mount two instead of just one, but losetup -f after all only every creates one. So something else is weird here.

You can set [loop.]max_loop=8 (or similar values) kernel parameter to have some loop devices initialized from the start but it's a workaround for such problems, not a solution. By default this is set to 0 on ArchLinux so all loop devices have to go through loop-control. And all modern programs should support it...

Edit: whoops, seems like this was an old thread... problem solved?

----

Seems like pam_mount libcryptmount does not support loop-control. There's a loop-linux.c that enumerates loop devices and looks for a free one. Uhhh. Yeah that doesn't work anymore.

But it does not have the exact error message quoted above. There's something else in the chain for that. Seems like this is a kpartx message but kpartx should support loop-control. How is kpartx involved here anyway. Maybe something else has the same message but I can't find it.

Last edited by frostschutz (2023-02-28 20:39:09)