0

The backstory to this question.

After erasing crypto_LUKS headers as specified in frostschutz's answer, I tried following this guide again. I got stuck at mounting Mac's EFI partition to /mnt/boot again, but now with a different error, namely wrong fs type, bad option, bad superblock (see 1st screenshot here). Also, while lsblk showed my partition as crypto_LUKS before erasing the headers, now it shows nothing about it (see 2nd screenshot here). I tried to check it with other tools, and cgdisk, on contrary to lsblk, shows the UUID of the EFI partition (see 3rd screenshot here). Also, fsck doesn't show anything about /dev/sda, it says something about MBR (see 5th screenshot here). Could it be the problem with MBR/GPT tables?

Mac's diskutil shows the same info about EFI partition as in the previous question (2nd screenshot here).

Martian
  • 123
  • 4
  • While ESP - efi system partition must be FAT32, a /boot partition cannot be. Most desktops do not need /boot, but if using LVM, you may need a separate /boot. Better to use standard ext4. https://askubuntu.com/questions/655440/refind-cant-find-lubuntu-kernel-on-lubuntu-partition – oldfred Aug 28 '22 at 14:28
  • @oldfred it seemed weird to me too, but 2 guides that I found for macs (here’s the second one: https://mchladek.me/post/arch-mbp/) mounted esp at /mnt/boot. I’ll try to install arch without it and hopefully will be back with results – Martian Aug 28 '22 at 16:32
  • @oldfred Also I’m curious if my problem is caused by using btrfs like in the question you linked. It just struck me that in both guides for Macs they’re using ext4 – Martian Aug 28 '22 at 16:34
  • The kernel seems to be reporting a `FAT-fs (sda1): bogus number of FAT structure` error on the mount attempt. Are you aware that the UEFI firmware on Macs can also read HFS(+) filesystems, and so a MacOS-created ESP partition might contain a HFS+ filesystem? – telcoM Aug 28 '22 at 17:01
  • Since your `sda` disk is partitioned, running a `fsck` on `/dev/sda` is not a good idea: in your case, it assumed that the **entire disk** was supposed to be a single ext2/3/4 filesystem, and since that isn't actually the case, its sanity checks stopped it before trying to make any inappropriate repairs. A GPT-partitioned disk always contains a "protective MBR" in block #0, to prevent accidents of the "this disk seems to be unformatted, click just once here to automatically partition & format it" variety. – telcoM Aug 28 '22 at 17:12
  • Also, note that the second guide you linked is from year 2015, and your `lsblk` indicates the filesystem type of `sda2` is `apfs`. That filesystem type was introduced to macOS in September 2017, and its introduction caused some changes in the macOS boot process. So you should consider any Mac dualboot installation instructions that are older than September 2017 as **outdated** for your purposes. – telcoM Aug 28 '22 at 17:23

0 Answers0