Re: kern/59913: NetBSD bootblocks don't pass long volume names

["Michael van Elst via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/59913; it has been noted by GNATS.

From: mlelstv%serpens.de@localhost (Michael van Elst)
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/59913: NetBSD bootblocks don't pass long volume names
Date: Mon, 12 Jan 2026 22:21:38 -0000 (UTC)

 gnats-admin%NetBSD.org@localhost ("john%ziaspace.com@localhost via gnats") writes:
 
 >When using boot.cfg to tell the kernel where to root, old fashioned
 >BIOS boot blocks don't pass names longer than ten characters.
 
 That is a limitation of our x86 bootloader protocol.
 
 struct btinfo_rootdevice {
         struct btinfo_common common;
         char devname[16];
 };
 
 which is also passed (for compatibility) by the EFI bootloader.
 
 The field isn't used by default. Instead, the bootloader passes a
 reference to a BIOS device number and either a disklabel partition
 or the offset/length pair of a wedge that was used to fetch the boot
 program and the kernel. The bootloader understands longer wedge
 names, as only the disk offset is passed to the kernel.
 
 This works fine if the kernel resides on the root partition and
 if the boot disk is actually known by the BIOS (even for EFI).
 There is some validation (a bootblock checksum) to deduce the
 boot disk if it is ambiguous.
 
 For other cases, a root specification can be passed as a literal
 string (and is truncated). Unlike the regular partition/wedge
 information, this is not interpreted by the bootloader but only
 passed to the kernel. It's equivalent to a root specification
 that is embedded into the kernel (via config(5)).
 
 Even multiboot (which passes a longer kernel commandline) is
 translated into the regular bootloader protocol and a "root"
 parameter is truncated.
 
 Other archs have their own pecularities.
 
 
 
 >1) pass a longer string for root and boot, if possible
 
 There is no "boot" string. "boot" disk information is
 passed as BIOS device and either partition number or
 offset/length pair.
 
 You may extend the boot protocol. The various bootloaders
 need to support a new BTINFO element and the kernel needs
 matching code to accept it. Which also means that old kernels
 will ignore it.
 
 
 
 >2) when evaluating the boot device from what's passed from bootblocks with
 >string limits, perhaps match with the first NAME that matches (although this 
 >could be problematic if people use longvolumenamea, longvolumenameb, et cetera)
 
 It is problematic.
 
 
 
 >3) perhaps make a hash of the NAME and compare it with hashes of all available
 >volume names and match based on that, if the 10 character limit can't be fixed
 
 It's a 15 character limit (plus terminating NUL) minus either a
 leading "NAME=" or a more historical "wedge:" prefix.
 
 Using a hash when the name gets truncated is an interesting idea,
 it is also easy to implement. A string like "#hash" would get 56 bits
 in hex encoding, or even 84 bits with a base64 encoding. But it
 would add another bizarre element to the boot protocol.
 
 
 
 >4) document the limitation in (5) boot.cfg
 
 Maybe also in x86/boot(8) which describes BTINFO_ROOTDEVICE but
 doesn't mention the size limitation.