I’ve got encrypted swap with protective tiny ext2fs (to provide
an anchor for LABEL=) set up, and today, my swapcycle script
complained. Manual checks confirm that…

tg@x61p:~ $ sudo cryptdisks_start cswp2
Starting crypto disk...cswp2 (starting)...cswp2: the precheck for '/dev/sda3' failed: - The device /dev/sda3 contains a filesystem type jbd at offset 65536. ... (warning).
failed.

… the device no longer comes up.

What happens here is that the encrypted part of the PREVIOUS
swap session (no longer readable due to random encryption key)
happens to mimic the magic of a jbd triggering these lines…

    local out tmpdev
    if [ "$CRYPTTAB_TYPE" != "luks" ] && [ "$CRYPTTAB_TYPE" != "bitlk" ]; then
        # fail if the device has a filesystem and the disk encryption format doesn't
        # verify the key digest (unlike LUKS); unless it's swap, otherwise people can't
        # easily convert an existing plainttext swap partition to an encrypted one
        if ! out="$(/lib/cryptsetup/checks/un_blkid "$CRYPTTAB_SOURCE" "" ${CRYPTTAB_OPTION_offset+"$offset_bytes"} 2>/dev/null)" &&
                ! /lib/cryptsetup/checks/blkid "$CRYPTTAB_SOURCE" swap ${CRYPTTAB_OPTION_offset+"$offset_bytes"} >/dev/null; then
            log_warning_msg "$CRYPTTAB_NAME: the precheck for '$CRYPTTAB_SOURCE' failed: $out"
            return 1
        fi
    fi

… from /lib/cryptsetup/cryptdisks-functions.

I’m a bit puzzled about how to proceed here. I mean, a dd(1) command
will make this work again for me, but there is a systematic bug: the
cryptsetup integration seems to have a hardcoded check for existing
(unencrypted) filesystems on the part of the storage that is later
encrypted, so if the encrypted value of what is actually written to
there after starting happens to match the magic of some known fs, it
won’t come up any more, AND there is no way to work around this with
a setting in crypttab(5) or a command-line option.

And, the more I read this, the more I believe that this can also happen
with real filesystems, not just encrypted swap; real filesystems will
of course use a consistent encryption key, not a random one.

So… while I understand the intent behind this check, I believe it is
completely bogus. I’m not even sure it can be rescued into something
that can stay without impacting normal operation. It just takes certain
conditions, rare at that, to trigger that.

So, well… let’s see… the cleaning needs to take the offset into account…
so maybe not a dd but given I have an SSD this works:

tg@x61p:~ $ sudo blkdiscard -o 65536 -f /dev/sda3
blkdiscard: /dev/sda3 contains existing file system (ext2).
blkdiscard: Operation forced, data will be lost!
tg@x61p:~ $ sudo cryptdisks_start cswp2
Starting crypto disk...cswp2 (starting)...cswp2 (started)...done.
tg@x61p:~ $ sudo swapon /dev/mapper/cswp2

(blkdiscard complains because the first 64 KiB of /dev/sda3 do indeed
contain an ext2fs… except it is only 64 KiB long, not the rest of the
partition, but it cannot easily know that.)

For more information on the setup of encrypted swap with protective
ext2fs and swapcycling to destroy old encryption keys, see:
https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=shellsnippets/shellsnippets.git;a=blob;f=posix/sysadmin/swapcycle;hb=HEAD
(user=pass public due to “AI” scrapers) (and I need to update that to
suggest using multiple partitions, so some swap is always kept)

Full disclosure, I’m running a version of cryptsetup with the backports
to make offset= work applied, but I am 100% confident that they are not
part of the problem.