grub – How to merge /boot partition into root partition

update-grub will actually only update the GRUB configuration file at /boot/grub/grub.cfg.

The GRUB core image (which is mostly within your BIOS boot partition) contains a partition number and a pathname. Those tell GRUB how to find the /boot/grub directory, and thus the GRUB configuration file and the GRUB modules like normal.mod.

Unmounting the /boot partition had no effect on GRUB, as GRUB does its job before the Linux kernel even starts. Since you did not update the information encoded into the GRUB core image (by re-running grub-install /dev/sda after unmounting the old /boot filesystem and moving /boot.bak in its place), GRUB simply kept using the old /boot partition until you removed it. If you had made any changes to the GRUB configuration before running update-grub in your procedure, you would have noticed that the changes did not actually take effect.

So, the thing to do after mv /boot.bak /boot should not be update-grub, but:

grub-install /dev/sda

You achieved effectively the same by running apt-get install --reinstall grub-pc. But now the error message is attempt to read or write outside of disk 'hd0'. That tells me GRUB is using BIOS routines to access the disk, and apparently QEMU’s BIOS emulation routines have not been updated to handle >2TB disks, so you are hitting the 2 TB limit.

(And yes, I’ve analyzed a vanilla Debian 12 grub-pc installation. The only modules embedded within the GRUB core image in a simple installation like this are fshelp.mod, the appropriate filesystem driver module (e.g. ext2.mod), the appropriate partition table type module (e.g. part_msdos.mod or part_gpt.mod) and the biosdisk.mod. Although there would be a BIOS-independent ahci.mod or ata.mod available, they are not used by the default installation.)

Unfortunately, when your root filesystem is sized at ~4 TB, you really should switch to booting in UEFI mode. To do that with Debian’s QEMU (without Secure Boot support), you’ll need to have the ovmf package installed, and to change the <os> section of your VM’s XML configuration file to something like:

<os>
  <type arch="x86_64" machine="pc-q35-5.2">hvm</type>
  <loader readonly='yes' type="pflash">/usr/share/OVMF/OVMF_CODE_4M.fd</loader>
  <nvram template="/usr/share/OVMF/OVMF_VARS_4M.fd">/wherever/you/keep/your/VMs/vmname.nvram.fd</nvram>
  <boot dev='hd'/>
</os>

Then you could

  1. reuse the space of your BIOS boot and former /boot partitions to create an EFI System Partition,
  2. add a /etc/fstab line to mount it to /boot/efi,
  3. replace grub-pc and grub-pc-bin packages with grub-efi-amd64 and grub-efi-amd64-bin,
  4. run grub-install --target=x86_64-efi --force-extra-removable /dev/sda

and once successfully booted in UEFI mode, run grub-install /dev/sda again to ensure the UEFI NVRAM boot variable is set correctly. Then install and learn to use efibootmgr to manage your boot settings from within a running OS in a standardized way.

If you are not yet running in UEFI mode when running grub-install --target=x86_64-efi, the --force-extra-removable will install a second copy of the UEFI GRUB at /boot/efi/EFI/boot/bootx64.efi: the removable media/fallback location.

In case you want Secure Boot too, replace OVMF_CODE_4M.fd with OVMF_CODE_4M.ms.fd and the NVRAM template OVMF_VARS_4M.fd with OVMF_VARS_4M.ms.fd. Add the grub-efi-amd64-signed and shim-signed packages, and re-run grub-install --target=x86_64-efi --force-extra-removable /dev/sda.

Read more here: Source link