How to avoid interference of os-prober with an encrypted partition

Question

On a linux server, I have dedicated a large partition, identified as /dev/sdb1, to an encrypted filesystem. I'm using

losetup /dev/loop0 /dev/sdb1

cryptsetup -c aes -h sha512 create crypto /dev/loop0

mount /dev/mapper/crypto /var/crypto/db/

and a long passphrase to mount the partition and use it. On installation of a new kernel package, /usr/bin/os-prober is run. As far as I can see, it checks each partition for OS installations. Obviously, it fails the hard way on /dev/sdb1, where nothing but noise should live (unless you have the passphrase and make use of dmcrypt, of course).

According to my syslog, immediately after

 running /usr/lib/os-probes/50mounted-tests on /dev/sdb1

a "Buffer I/O error on dev dm-0, ..." is logged, an aborted journal is detected, and the filesystem is remounted r/o. The log continues with a number of failure messages regarding the detection of a file system on /dev/sdb1, e.g.

Aug 17 17:12:59 mibi202 kernel: [1903146.947192] EXT4-fs (sdb1): VFS: Can't find ext4 filesystem

squashfs: SQUASHFS error: Can't find a SQUASHFS superblock on sdb1

FAT-fs (sdb1): invalid media value (0xca)

Obviously, os-prober could not do its magic on the encrypted device and somehow interfered with its proper function.

Unmounting the encrypted filesystem, removing the dmcrypt device and the loop, and starting the stuff again in proper order gets me back to the file system.

Any hint on how to avoid os-prober causing a service interruption on the server would be welcome. Thanks.

score 1 · Answer 1 · answered Aug 18 '16 at 00:17

Unfortunately os-prober is pretty rustic, it does not accept any kind of configuration (file or command line). Yet, it understand LUKS.

If you use LUKS instead of plain cryptsetup it will stop trying to interpret that partition (on the other hand, if the partition is open it will try to find and understand the loop device).

Inside /usr/lib/os-probes/50mounted-tests the test is performed as follows:

types="$(fs_type "$partition")" || types=NOT-DETECTED
# ...
elif [ -z "$types" ]; then
    if type cryptsetup >/dev/null 2>&1 && \
       cryptsetup luksDump "$partition" >/dev/null 2>&1; then
        debug "$1 is a LUKS partition; skipping"
        exit 0
    fi

Therefore using LUKS is the easier solution.

Yet, if you really do not want to use LUKS you can simply hack os-prober and include your encrypted partition into the fs_type check. That check is performed inside /usr/share/os-prober/common.sh and is actually quite trivial:

fs_type () {
    if (export PATH="/lib/udev:$PATH"; type vol_id) >/dev/null 2>&1; then
        PATH="/lib/udev:$PATH" vol_id --type "$1" 2>/dev/null
    elif type blkid >/dev/null 2>&1; then
        blkid -o value -s TYPE "$1" 2>/dev/null
    else
        return 0
    fi
}

And you can hack it to:

fs_type () {
    if [ "x$1" = "x/dev/sdb1" ]; then
        return 0
    elif (export PATH="/lib/udev:$PATH"; type vol_id) >/dev/null 2>&1; then
        PATH="/lib/udev:$PATH" vol_id --type "$1" 2>/dev/null
    elif type blkid >/dev/null 2>&1; then
        blkid -o value -s TYPE "$1" 2>/dev/null
    else
        return 0
    fi
}

os-prober is really just a collection of shell scripts.

Thank you very much, this solved my problem. LUKS is not currently a choice for me, since it's a server running 24x7 and I wouldn't want to cause downtime just to switch over to LUKS. — Ernst M., Aug 18 '16 at 12:35

How to avoid interference of os-prober with an encrypted partition

1 Answers1