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
- reuse the space of your BIOS boot and former
/boot
partitions to create an EFI System Partition, - add a
/etc/fstab
line to mount it to/boot/efi
, - replace
grub-pc
andgrub-pc-bin
packages withgrub-efi-amd64
andgrub-efi-amd64-bin
, - 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