Improve suggested/auto disk layout with BTRFS for snapshots

[karnkaul]

describe the request

As of 2026-02, archinstall's default/recommended disk layout when using BTRFS is essentially:

/boot  FAT32  1G
/ (@, @home, @cache, @log)  btrfs  rest

If I'm not mistaken, with this layout, the kernel, initramfs, and microcode reside in /boot, which is not part of the BTRFS filesystem, and thus will not be part of its snapshots.

Per the Arch Wiki, mounting esp to /efi and leaving /boot be part of /@ should resolve this. I've tried a couple of setups using archinstall and a manual partitioning scheme with such a layout, marking theboot and ESP flags on /efi. This ends up putting grub/ config etc inside /efi however, instead of /boot, which ends up breaking some things like grub-btrfs. (I fixed that by simply reinstalling grub via grub-install and getting rid of /efi/grub.)

My understanding around this stuff is still relatively shallow and high-level, but if anything here seems worth taking action on, I'd be happy to learn and contribute.

[codefiles]

I agree with your assessment. This is pretty much covered in #3717.

archinstall has been using the GRUB alternative install method from the ArchWiki since ad6cbcf, with the addition of the grub-install option --boot-directory. This should not be the default and should be removed or maybe made configurable.

When looking at #3717 I came up with this but never submitted it:

commit a48cc7620144aa6583c038b3cf4620a71f62f2dd (grub-rm-boot-dir)
Author: codefiles <11915375+codefiles@users.noreply.github.com>
Date:   Mon Jan 19 06:53:09 2026 -0500

    Remove GRUB boot_dir

diff --git a/archinstall/lib/installer.py b/archinstall/lib/installer.py
index 1b96c155..4d53832f 100644
--- a/archinstall/lib/installer.py
+++ b/archinstall/lib/installer.py
@@ -1332,8 +1332,6 @@ class Installer:

                info(f'GRUB boot partition: {boot_partition.dev_path}')

-               boot_dir = Path('/boot')
-
                command = [
                        'arch-chroot',
                        '-S',
@@ -1350,15 +1348,9 @@ class Installer:

                        self.pacman.strap('efibootmgr')  # TODO: Do we need? Yes, but remove from minimal_installation() instead?

-                       boot_dir_arg = []
-                       if boot_partition.mountpoint and boot_partition.mountpoint != boot_dir:
-                               boot_dir_arg.append(f'--boot-directory={boot_partition.mountpoint}')
-                               boot_dir = boot_partition.mountpoint
-
                        add_options = [
                                f'--target={platform.machine()}-efi',
                                f'--efi-directory={efi_partition.mountpoint}',
-                               *boot_dir_arg,
                                '--bootloader-id=GRUB',
                        ]

@@ -1432,9 +1424,7 @@ class Installer:
                        grub_default.write_text(config)

                try:
-                       self.arch_chroot(
-                               f'grub-mkconfig -o {boot_dir}/grub/grub.cfg',
-                       )
+                       self.arch_chroot('grub-mkconfig -o /boot/grub/grub.cfg')
                except SysCallError as err:
                        raise DiskError(f'Could not configure GRUB: {err}')

[karnkaul]

Interesting, thanks for all the invaluable context! The diff you posted looks good to me, but looks incompatible with what you pointed out about the alternative install method (https://github.com/archlinux/archinstall/blob/master/archinstall/lib/installer.py#L1401 when boot_partition.mountpoint != '/boot'). EDIT: oh dang it's the same file/code lol, my bad.

I went through the comments on the issue and the PR for it, but can't really understand why it was failing before the fixes to begin with. It also appears that /efi/grub is desirable to some subset of users, that complicates matters.

I think there's good precedent to mount ESP to /efi, but am not sure if that's true for GRUB's "boot directory" (for either option I mean, be it /boot/grub or /efi/grub). Considering that most people would default to grub-mkconfig -o /boot/grub/grub.cfg and there's no update-grub wrapper in core Arch, IMO /boot/grub makes the most sense, unless explicitly overridden - and not implicitly inferred from ESP not being /boot.

[h8d13]

I don't see how hardcoding

+                       self.arch_chroot('grub-mkconfig -o /boot/grub/grub.cfg')

would ever be better. user can also use this command with his adapted paths (another strategy is symlinks for specific scenarios, but that is "hacky")

related to #4147

The idea is also that the user could have following scenarios:

• Just /efi (newer default standard for UEFI) (manual way)
  • Here one issue I found is that we have mark as ESP and BOOTABLE but for UEFI systems this is synonymous
• /efi and /boot (usually for encryption, we do not permit this currently I believe, but in my fork it kind of works)
• Just /boot (our current default)

And the related defs should respect any of these patterns

Some things I've observed with this to make it work:

When there's no /boot partition, it falls back to using the EFI partition as boot_partition (then creates /boot/ on the created root FS)

		if boot_partition is None:
			if SysInfo.has_uefi() and efi_partition is not None:
				boot_partition = efi_partition
			else:
				raise ValueError(f'Could not detect boot at mountpoint {self.target}')

The issue with these changes is that it would involve a lot of testing different scenarios.