NetBSD Problem Report #59913

From john@klos.com  Mon Jan 12 20:13:50 2026
Return-Path: <john@klos.com>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.netbsd.org", Issuer "R13" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id CB5FF1A9244
	for <gnats-bugs@gnats.NetBSD.org>; Mon, 12 Jan 2026 20:13:50 +0000 (UTC)
Message-Id: <202601122013.60CKDeRk028247@bunny.zia.io>
Date: Mon, 12 Jan 2026 20:13:40 GMT
From: john@ziaspace.com
Reply-To: john@ziaspace.com
To: gnats-bugs@NetBSD.org
Subject: NetBSD bootblocks don't pass long volume names
X-Send-Pr-Version: 3.95
X-From4GNATS: "john@ziaspace.com via gnats" <gnats-admin@NetBSD.org>

>Number:         59913
>Category:       kern
>Synopsis:       NetBSD bootblocks don't pass long volume names
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jan 12 20:15:00 +0000 2026
>Last-Modified:  Mon Jan 12 22:25:02 +0000 2026
>Originator:     John Klos
>Release:        NetBSD 11.0_BETA
>Organization:

>Environment:


System: NetBSD bunny.zia.io 11.0_BETA NetBSD 11.0_BETA (BUNNY) #0: Wed Oct 15 11:51:33 UTC 2025 john@bunny.zia.io:/usr/obj-amd64/sys/arch/amd64/compile/BUNNY amd64
Architecture: x86_64
Machine: amd64
>Description:

When using boot.cfg to tell the kernel where to root, old fashioned
BIOS boot blocks don't pass names longer than ten characters.
>How-To-Repeat:

On a system with MBR / BIOS bootblocks, edit /boot.cfg and add
something like this:

menu=Boot normally:rndseed /var/db/entropy-file;root NAME=longvolumename;boot

While booting, before the kernel loads, the bootblock reports:

truncated to NAME=longvolume

The kernel reports:

boot device: <unknown>
>Fix:

1) pass a longer string for root and boot, if possible

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)

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

4) document the limitation in (5) boot.cfg

>Audit-Trail:
From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
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 ("john@ziaspace.com 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.


>Unformatted:

Home	PR Database Search