Partition sda14 and sda15

Bare Metal and VPS
1

Hi,

On my brand‑new first VPS, I wanted to create a partition for /var.

So in rescue mode I shrink the root partition and create my /var partition. And bothered by sda14 (BIOS BOOT) and sda15 (EFI), I reordered the partitions (cfdisk’s sort option).

Then I boot in normal mode… nothing.

grub in the KVM says "unknown filesystem". That shouldn’t happen, right?

I had forgotten to run update-grub, so I did, thinking it would fix the problem, but it didn’t.

I had to put the partitions back in order (root as #1, with sda14 and sda15 after it) for it to boot again.

I did this with sfdisk …

I haven’t seen the right documentation, or it’s nowhere written? And why does it matter?

[Edit]

Is it important that root be the first partition, or that the BIOS BOOT and EFI partitions be the last ones? And why?

2

Hi @TTxJyK9A38

The procedure you followed with sfdisk is correct :+1:

To create a /var partition safely and reliably, the recommended method is:

  1. As you already did, activate rescue mode for your VPS from the client area.
  2. Use lsblk to view the current partitions and their sizes.
  3. Use resize2fs /dev/sdb1 and resize2fs /dev/sdb1 to shrink the filesystem, then use fdisk or parted to reduce the partition size and free space.
    :warning: It's important that the root partition is not mounted, so you must run these commands on the /dev/sdb1 device without mounting it in rescue mode.
  4. With the freed space, use fdisk to create a new partition (e.g., /dev/sdb2) that will be mounted on /var.
  5. Once the partition is created, reorder the partitions with sfdisk so that the root and the new /var partition are in order. This will ensure GRUB finds the bootloader on the correct partition.

I think you did it correctly; you only missed the step of reinstalling GRUB.

Hope I helped you, best regards.
Sergio Turpín

3

My question is:

It seems that after reordering the partitions (cfdisk's sort option), my disk ended up like this:

sda1: BIOS BOOT

sda2: EFI

sda3: /

sda4 /var

and the VPS no longer booted, as far as I can tell. Why?

4

Hello @TTxJyK9A38, is your VPS using UEFI or legacy boot (BIOS)?

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
5

in boot legacy. I haven't changed anything, if we can change it.

6

What matters is whether root must be the first partition, or whether the BIOS BOOT and EFI partitions must be the last? And why?

I did some tests and learned that for legacy boot the partition numbering is what really matters, which your sort changed.

Run grub-install /dev/sda and you should no longer have any problem.

The BIOS GRUB partition contains the number of the partition that holds grub.cfg, so if it changes you need to reinstall GRUB to update that number.

Example on a bare‑metal system with Debian 12 and grub.cfg in /dev/sda2:

# sudo python3 - "$(lsblk -nro PATH,PARTTYPE | awk '$2=="21686148-6449-6e6f-744e-656564454649"{print $1; exit}')"
import lzma, re, struct, sys
dev = sys.argv[1]
data = open(dev,'rb').read()
comp, uncomp = struct.unpack_from('<II', data, 520)
flt = [{"id": lzma.FILTER_LZMA1, "lc":3, "lp":0, "pb":2, "dict_size":1<<26}]
for off in range(512, 16384):
    try:
        d = lzma.LZMADecompressor(format=lzma.FORMAT_RAW, filters=flt)
        out = d.decompress(data[off:off+comp+4096], max_length=uncomp)
    except lzma.LZMAError:
        continue
    if len(out) == uncomp:
        break
else:
    raise SystemExit("core.img payload not found in " + dev)
m = re.findall(rb'\((?:hd[0-9]+)?,[a-z0-9_]+\)[\x21-\x7e]*', out)
print("BIOS boot partition:", dev)
print("embedded prefix:", b' '.join(m).decode() if m else "none found")
EOF
BIOS boot partition: /dev/sda1
embedded prefix: (,gpt2)/grub

If you run sort again, you can run this command before grub-install and afterwards you should see the number after gpt change.

I forgot to run update-grub, so I did it thinking it would fix the problem, but nope

That command only regenerates grub.cfg. Your issue was upstream, in the image that GRUB embeds in the BIOS GRUB partition, because it can no longer find your grub.cfg.

7

ah ok. Thanks. I thought it was something specific to OVH and its VPS. I hadn't realized that GRUB hard‑coded the partition number like that at its first level.

It's been a long time since I used GRUB, and even less in BIOS legacy mode.

8

I didn't know either, it was very instructive to debug :smiley:

Indeed, in UEFI, it's the UUID of the partition containing the configuration that matters, not its number:

# cat /boot/efi/EFI/debian/grub.cfg 
search.fs_uuid 6d1bd696-738f-4565-8c0c-b1b51bc7c3d7 root 
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg
9

PS: Is there a reason why the BIOS BOOT and EFI partitions are numbered 14 and 15 like that?

10

It comes from the upstream Debian image we are based on: https://salsa.debian.org/cloud-team/debian-cloud-images/-/commit/a1bbc062bc7ba9dcaa70b2f169b2070c7ad9be6c#line_bea68894e_A15

I don’t know the justification. Maybe to let the user create multiple partitions before 14 and 15?

In any case, the early Ubuntu Cloud images had actually used 127 and 128: https://lists.ubuntu.com/archives/ubuntu-cloud/2013-December/000929.html. It was changed to 14 and 15 because of a bug (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1258631). I imagine Debian adopted this topology.