1

I was trying to dual boot Arch on my MacBook. At first, I tried to install Arch with LUKS encryption. Unfortunately, in the middle of a guide, I understood that it was a bit outdated and I didn't have the knowledge to proceed with installation without a guide, so I erased everything and started from scratch, this time without encryption. It was good until I was unable to mount /dev/<appleEFIpartition> /mnt/boot (as in this guide) because of the wrong filesystem, namely, crypto_LUKS. I was really surprised at how this was possible as I didn't encrypt my mac bootloader, and it still works flawlessly, I can boot into macOS and use it without any problems (I would expect my computer to break if I encrypted my bootloader). I decided to double-check and mac's diskutil says that my EFI is FAT32 (no mention of crypto_LUKS for any volume).

I am super confused about how this is possible. Here are screenshots of me checking the filesystem first on the arch installation medium and then using diskutil from macOS.

Martian
  • 123
  • 4
  • I see msdos (MBR) mentioned? Did you convert gpt to MBR? UEFI uses gpt and Macs have used gpt for years. Or did you convert to hybrid MBR/gpt which is not recommended. http://www.rodsbooks.com/gdisk/hybrid.html What does gdisk show? – oldfred Aug 27 '22 at 18:37
  • @oldfred ‘Found valid GPT with protective MBR; using GPT’ – Martian Aug 27 '22 at 18:48
  • @oldfred it also shows efi as “EFI System Partition”. Was unable to check filesystem using gdisk – Martian Aug 27 '22 at 18:52
  • Really only know PC, not Mac. but valid gpt and ESP would be correct with a PC. UEFI cannot boot a FAT32 encrypted partition. I have this in my old notes. LUKS is designed for fast and secure wiping by just overwriting header and key-slot area. So is there left over meta-data for LUKS somewhere? – oldfred Aug 27 '22 at 19:43

1 Answers1

2

Normally, LUKS header does not survive formatting.

Setup:

# truncate -s 100M foobar.img
# losetup --find --show foobar.img
/dev/loop0
# parted /dev/loop0 mklabel gpt mkpart boot 1MiB 100%

LUKS:

# cryptsetup luksFormat /dev/loop0p1
# wipefs /dev/loop0p1
DEVICE  OFFSET TYPE        UUID                                 LABEL
loop0p1 0x0    crypto_LUKS d9a4c128-1cb9-4252-a7ec-697ae4c35535
loop0p1 0x4000 crypto_LUKS d9a4c128-1cb9-4252-a7ec-697ae4c35535

FAT:

# mkfs.vfat /dev/loop0p1
# wipefs /dev/loop0p1
DEVICE  OFFSET TYPE UUID      LABEL
loop0p1 0x36   vfat 524F-02F3
loop0p1 0x0    vfat 524F-02F3
loop0p1 0x1fe  vfat 524F-02F3

So, after mkfs.vfat, the crypto_LUKS header signature is gone.

However, this is after all Linux... where the LUKS header is a known thing, so it stands to reason that it will be wiped. In another OS that does not use LUKS, it might be a different matter.

After repairing the wiped LUKS header, it's possible to have both:

# wipefs /dev/loop0p1
DEVICE  OFFSET TYPE        UUID                 LABEL
loop0p1 0x0    crypto_LUKS key to try again ...
loop0p1 0x4000 crypto_LUKS
loop0p1 0x36   vfat        615E-AF44
loop0p1 0x1fe  vfat        615E-AF44

At this point, the filesystem still mounts fine, if specified:

# mount /dev/loop0p1 /mnt/foobar
mount: /mnt/foobar: unknown filesystem type 'crypto_LUKS'.
       dmesg(1) may have more information after failed mount system call.
# mount -t vfat /dev/loop0p1 /mnt/foobar
# grep foobar /proc/mounts
/dev/loop0p1 /mnt/foobar vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro 0 0

So we have both LUKS and vfat magics on the same device.

At this point, you can use wipefs to remove just the LUKS headers:

# umount /mnt/foobar
# wipefs -a -t crypto_LUKS /dev/loop0p1
/dev/loop0p1: 6 bytes were erased at offset 0x00000000 (crypto_LUKS): 4c 55 4b 53 ba be
/dev/loop0p1: 6 bytes were erased at offset 0x00004000 (crypto_LUKS): 53 4b 55 4c ba be

And it's back to vfat only:

# wipefs /dev/loop0p1
DEVICE  OFFSET TYPE UUID      LABEL
loop0p1 0x36   vfat 615E-AF44
loop0p1 0x1fe  vfat 615E-AF44

and it's detected as such

# file -s /dev/loop0p1
/dev/loop0p1: DOS/MBR boot sector
# blkid /dev/loop0p1
/dev/loop0p1: SEC_TYPE="msdos" UUID="615E-AF44" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="boot" PARTUUID="e3d8e408-2e48-45c4-bd6d-9be685d95ed5"

and it mounts with filesystem auto detection again so -t vfat is no longer necessary

# mount /dev/loop0p1 /mnt/foobar
frostschutz
  • 47,228
  • 5
  • 112
  • 159