You are not logged in.
Pages: 1
I've installed Arch a few years ago, but previously used ext4. This time around I thought I'd expand my knowledge and try Btrfs. I'm using an existing partition that was previously used with another distro (ext4).
This time around, when installing grub, I get the following error message:
grub-install: warning: your core.img is unusually large. It won't fit in the embedding area.
grub-install: error: filesystem 'Btrfs' doesn't support blocklists.
I thought I'd try to fix the first item by following the instructions here (https://wiki.archlinux.org/index.php/Bt … Btrfs_disk) to use --alloc-start when running mkfs.btrfs to give more space for core.img. I set it at 2048, thinking this was enough space.
lsblk -f also shows my drive with the correct file system and label.
Any thoughts on why that didn't work? What am I missing?
Last edited by BelowZero (2019-11-30 22:26:17)
Offline
a) 2048 - what unit has it ? Bytes ? Usually a bios grup partiton has 1M.
b) maybe the option is misleading - see https://patchwork.kernel.org/patch/4170421/
c) from man: --alloc-start <offset> deprecated, will be removed ...
This sounds like you should not use it at all.
Offline
If you are reusing an existing partition, why are you following instructions explicitly not using a partition?
Offline
I ended up using ext4 and it worked, as expected. I’ll save trying Btrfs for another time.
Offline
The central problem here is this old bad habit of installing bootloaders to partitions that contain file systems, rather than properly installing the bootloader to a dedicated partitioning designed and maintained for that purpose. The grub-install command wasn't provided, but I'm guessing it was something like 'grub-install /dev/sdXY' rather than 'grub-install /dev/sdX' - the former having always been a bad idea from day 1 back in 1995, but is proven to be fragile and a PITA a decade ago, let alone as we're about to enter 2020.
Stop installing a bootloader into each partition you want to boot, and stop using the GRUB chainloader command. Use the GRUB configfile command instead.
And also, the wiki contains bad advice: partitionless installations with an insufficient warning to detour casual users. Instead, install the bootloader to a proper dedicated partition for this purpose: EFI System partition, BIOS Boot, or "MBR gap".
Last edited by cmurf (2019-12-30 18:25:49)
Offline
Some time ago a bug in grub related to btrfs was discussed https://lists.gnu.org/archive/html/grub … 00025.html.
Tl;dr because of btrfs dependency of zstd, the resulting core image cannot fit into 'core.img' size. The post in the mailing list above provided a patch to disable zstd support on 'pc-bios' platform.
Does your btrfs partition has zstd compression?
Offline
Does your btrfs partition has zstd compression?
Good catch! However if this is the case, it makes it too big for a core.img embedded in the Btrfs 64KiB bootloader pad before the first superblock. It's not too big for a core.img embedded a proper location: MBR gap or GPT BIOS Boot partition. For nearly a decade the partitioning tools have made both of them 1MiB by default. And I note in the thread you cite, they also acknowledge the idea that small embed sizes are unrealistic for this use case. The legacy hardware that insists on MBR gap ending at LBA 63 is an unusual firmware bug, suffice to say it's unlikely to ever get fixed. But in that case, excluding the GRUB modules location from zstd compression, by `chattr +C` on the containing directory before populating it with GRUB modules, will ensure they aren't compressed, and now the GRUB core.img can exclude the too large zstd module. It's true as a consequence those files also aren't checksummed. But that's no worse than a $BOOT volume using ext4.
Offline
mxfm wrote:Does your btrfs partition has zstd compression?
Good catch! However if this is the case, it makes it too big for a core.img embedded in the Btrfs 64KiB bootloader pad before the first superblock. It's not too big for a core.img embedded a proper location: MBR gap or GPT BIOS Boot partition. For nearly a decade the partitioning tools have made both of them 1MiB by default. And I note in the thread you cite, they also acknowledge the idea that small embed sizes are unrealistic for this use case. The legacy hardware that insists on MBR gap ending at LBA 63 is an unusual firmware bug, suffice to say it's unlikely to ever get fixed. But in that case, excluding the GRUB modules location from zstd compression, by `chattr +C` on the containing directory before populating it with GRUB modules, will ensure they aren't compressed, and now the GRUB core.img can exclude the too large zstd module. It's true as a consequence those files also aren't checksummed. But that's no worse than a $BOOT volume using ext4.
Which boot type do you use? MBR gap or 'BIOS boot partition'? In the latter case 1MiB of hole before the first 4096 sector aligned partition should be sufficient.
The issue with disabling ztd compression for grub files hoping that grub-mkconfing is smart enough to not pull it as dependency relies on assumptions about technical implementations. You can play with separate btrfs partition dedicated for boot files to test this issue with zstd dependency and core.img size. If you are really interest in implementation details, you can get more info from btrfs/grub mailing lists.
Last edited by mxfm (2019-12-31 10:41:17)
Offline
Which boot type do you use? MBR gap or 'BIOS boot partition'? In the latter case 1MiB of hole before the first 4096 sector aligned partition should be sufficient.
I'm not the OP, and also I'm only using UEFI so grubx64.efi goes on the ESP. At least in qemu-kvm, GRUB seems to not care where the BIOS Boot is, it uses it.
The issue with disabling ztd compression for grub files hoping that grub-mkconfing is smart enough to not pull it as dependency relies on assumptions about technical implementations. You can play with separate btrfs partition dedicated for boot files to test this issue with zstd dependency and core.img size. If you are really interest in implementation details, you can get more info from btrfs/grub mailing lists.
Perhaps a future GRUB's grub-install includes zstd.mod when embedding in a dedicated partition: MBR gap or BIOS Boot, and doesn't include it (but with warning that it's not included) when embedding in the Btrfs 64KiB bootloader pad. The alternative is to abandon the esoteric file system specific embed locations.
Last edited by cmurf (2020-01-01 00:44:18)
Offline
Pages: 1