Re: i386-Misc questions: [non-]disklabel'd wd1X, initrd-floppy, PUFFS-vnconfig

[Nutchanon Wetchasit <xwindows%xwindows.in.th@localhost>]

On Tue, 5 Nov 2026, Robert Elz wrote:

> though its label is "i386" we no longer support actual 386
> processors, 486 is the earliest of the intel range supported

It's kinda expected that I wouldn't be able to dust up my old 24 MHz
i80386DX-based [11 MiB DRAM] PC-compatible in my storeroom
and run the latest NetBSD on it, yeah. But I'm curious, what was
the last NetBSD version that actually had been known to run on real i80386?

> i386?  Really?   That is the 32 bit system - unless your hardware is
> very old, you'd be better off using the amd64 port.

The machine I'm using does support AMD64 [x86-64] instruction set.
However, running and actually daily-driving x86-32 OSes (notice "es")
has been an intentional choice on my part for the entire 13 years existence
of this machine.

I practice what I have been calling "legacy-first design", i.e. developing
software targeting configuration of the past. I would like to make sure
that software I write, use, or test could compile and run properly
in 32-bit environment; meaning they would work with few other machines
in my storeroom that're actually not supporting AMD64, as well as on other
vintage computers owned by people who actually maintain their gears
as opposed to throwing away computer after every few years
like unwashed masses are brainwa^H^H^H^H^H^H^H^H trained to do. [1]

And to make sure that I truly dogfood all the "legacy support" I wrote
in as realistic way as I could have [with my daily-driver portable hardware],
I need to actually live inside such test setup too. I'm aware of
limitations such setup is going to impose on me.

Apart from above, I also tinker with 16-bit/VM86 facility sometimes
(on GNU/Linux, I run DOSEMU backed by VM86-- meaning DOS programs
actually run on a real CPU); which, from what I know, that would not
be available under AMD64's long-mode which full 64-bit OSes would run under.

The existence of official i386 port is actually what made me come
straight here to NetBSD; without even thinking about "distro-hopping"
to test the water with any other flavors of BSD Unices.

> NetBSD's disklabel is different that how FreeBSD does it.
> In FreeBSD any FreeBSD "slice" can (or should, or perhaps must) have
> a disklabel, which describes how that slice is divided up.
>
> In NetBSD, the primary NetBSD partition has a disklabel which describes
> how NetBSD divides up the disk, which need not be in any way related to
> how the MBR does it.

I see, so NetBSD disklabel was not about sub-partition of a MBR slice;
but rather being a complete "shadow partition table" that could only
be seen under NetBSD... in the same manner that GPT was being
a shadow partition table in a MBR-GPT hybrid disk-- which could be seen
only under GPT-supporting OS, and must be manually kept in sync...

But how exactly NetBSD find a disklabel on a disk tho? I imagine it
would read from block 0 of a specific MBR slice with type value 0xA9?
Or... it only read so from block 0 of MBR slice which the NetBSD kernel
booted from?

And would that detection work if the slice was a logical type
rather than a primary type in the MS-DOS disklabel?

> the kernel would create a disklabel for its internal use anyway.
[...]
> Whether that was read from the drive, or the kernel just invented one
> from what it could work out from what it can find from the MBR
[...]
> randomly change from boot to boot, just because something else
> wasn't quite the same

That is exactly the part I hoped to hear! So that's what'd happen
when user inserted a MBR data disk that didn't have any NetBSD disklabel
like USB flash drive, then.

Is there any official documentation about what the exact process/rules
that i386 port use in enumerating the MBR [primary/logical] slices
into that made-up in-memory NetBSD disklabel?

> (and in any case, /tmp should normally be a tmpfs (in memory filesystem)).

Okay, but would it be appropriate to do so even when the hypervisor
was set to provide RAM as low as 128 MiB (or even 64 MiB)?

^ And does the default set of RC script still contain code to clear
  "/tmp" contents on startup?

> making ext2fs systems on linux is
> the best way, provided they are really ext2 (not 3 or 4) and only have the
> most basic features enabled, nothing at all fancy.  Then they should be
> able to be mounted on NetBSD, have files copied on or off, etc.  If repairs
> are needed (like after a crash) better to do that on linux too probably.

Acknowledged. Though one day I might also try "the third way",
of compiling/porting Linux e2fsprogs utilities (especially "mke2fs",
and "e2fsck") on/to NetBSD, and use that...

>> And would it okay for the `/home`, `/usr`, `/tmp`, and `/var`
>> on NetBSD root filesystem to be symlinks to other mounted filesystems?
>
> Yes, but why?   Rather than mounting a different filesystem elsewhere,
> and making a symlink, why not just mount the other filesystem on /home
> /usr /var (etc).   That's what I (and anyone else who doesn't believe in
> the "one huge root to use for everything" model is the best way) do.

By mounting filesystem directly in such directories,
it'd require 1 filesystem for each of such mount point (4 total).
Since I would like to get close to "one huge root to use for everything"
and "all readable under GNU/Linux" as possible; the franken-setup
I tried to ask about was more like the following 2-partition scheme:

1. Single NetBSD FFS boot+root partition; containing the bare minimum
   base system; with "/home", "/usr", "/tmp", "/var", symlinked
   into the second partition.

2. Single ext2fs "everything else" partition; containing the actual
   "home/", "usr/", "tmp/", "var/", directory which counterparts
   in the first partition symlink into.

I think people might be more familiar with this kind of scheme
when some sort of overlay/union-mount filesystem was involved
(does NetBSD have a counterpart of Kernel Linux's OverlayFS/AuFS/UnionFS?);
but I don't plan to involve such thing as a newbie yet, so... symlinks.

> Given that restriction, if you remain running the normal installed (big)
> generic kernel, the kernel will run on anything (supported) of the same
> architecture

Glad that it is the case.

> But there is also user level configuration, such as network setup, which
> can need changing when moving from one system to another - network
> interfaces on NetBSD (unlike linux) have hardware specific names.
[...]
> Graphics can differ as well, though how much of that needs any specific
> config isn't clear to me.

Yeah, I figure so. I think Xorg actually does autodetect many things nowadays,
but I accept that editing "xorg.conf" (or running "X -configure")
and correcting network configuration would be things I'd need to do
after such migration.

> If your systems support EFI, and GPT, then EFI booting,
> using the firmware's boot manager, is a much better way

As a user, I have a very-low opinion of UEFI and associated technologies
from the start; and I have heard many horror stories of people using
commodity hardware and found that their UEFI "firmware's boot manager"
were being non-existent, dog$#!+-buggy, rigged to boot to any OS
as long as it was "Microsoft Windows", or required poking pin
into random nondescript hole on the chassis on power-up to configure
(I have dealt with this latter one personally), etc.

But like you said: "To each their own"; I will stick
with Freedom Boot [16-bit BIOS/UEFI-CSM] like I have always done,
and deal with NetBSD disklabel/bootblock quirks that entails.

> I believe there are several ways to make GRUB boot NetBSD, and that is
> one of them.  What the others are, no idea

Okay, will go to ask on the GNU side about that.

>> 9. I saw mentions of the term "bootblock" in the user guide, which
>>    I take it to mean "bootloader"
[...]
> I'd need more context to understand what that is all about.

I saw this screenshot on NetBSD user guide, at the step after confirming
disk layouts:

https://www.netbsd.org/docs/guide/en/netbsd.html#inst-bootblocks

So I was like, "wait, was console actually a NetBSD's bootloader's
business or NetBSD's 'bootblock' didn't mean the thing I assumed
it to mean?", thus the question. Your explanation does make it clear though,
thanks.

>> serial console a last-ditch emergency backchannel
>> for administrator to X/Y/Zmodem files onto/from the remote host
>
> You're planning to do that via a PS1 (or whatever it is called) keyboard
> interface?

It's PC/AT keyboard interface; originally used with a big thumb-sized
cylindrical DIN plug. The old i80386DX-based machine I mentioned earlier
used exactly that.

Its modern form a.k.a. purple-colored PS/2 keyboard port which continued
to be seen on mainboards today, is actually the same thing at the controller,
protocol, and electrical level; just with a smaller pinky-sized mini-DIN
connector. As a kid, I had been using keyboard with original PC/AT connector
connected to a PC's PS/2 port through passive adapter, for several years.

But yeah; binary-banging through it wouldn't work; I asked about that
for uses in serial console.

>> 10. Is NetBSD console I/O (especially serial console) 8-bit clean
>>     and binary-safe?
>
> Almost.   Most x86 systems at least have a magic console sequence (or
> several) akin to Ctl-Alt-Del (on serial consoles, +++++ or something
> like that I think) to get into the in-kernel debugger, in case of problems.
> You can turn those off however.

Oh, so it doesn't involve serial BREAK signal like kernel Linux's
serial console SysRq; okay, that's interesting to know.
If that could be turned off in NetBSD, then it's not going to be
a real problem.

> The kernel (which can be /netbsd (or almost any name you like) or on some
> newer systems optionally /kernel/netbsd) is just the kernel, has no user
> space code baked in

Thanks.

> (except for some installation systems with a memory filesystem
> included in the image, in which case the whole (minimal) root
> filesys is in there).

Oh, so that is NetBSD's analog of kernel Linux's initrd... wait a minute,
that reminds me of certain capability that used to exist in kernel Linux:

Does it mean a floppy boot disk version of OpenBSD could be made by
prepending said filesystem with a copy of "/netbsd" kernel file,
and "dd" the whole thing into a floppy disk's device node?

> Modern disklabels can have up to 16 partitions (so
> NetBSD can see at most 16 partitions on an MBR drive) which are identified
> by a one character (letter) suffix, from a to p.   In those, in x86 systems,
> the 'd' partition is reserved to refer to the whole drive (ie: /dev/wd0
> and /dev/wd0d are the same thing), and the 'c' partition is nominally
> reserved to be "the" NetBSD MBR parition.

So it's more like 15 MBR slices max? (Because "d" suffix is reserved)
And suffix "c" *always* refer the MBR slice which contains
the with NetBSD disklabel itself; is this right? (Or the latter was
merely customary?)

If so, are the non-reserved partition letters being /[a-be-p]/ ?
Or that was rather /[a-ce-p]/ because "c" _technically_ wasn't reserved
as it refers to a real MBR slice (that contain BSD disklabel) that isn't
enumerated as any other letter, and doesn't necessarily need to be
the third primary entry in MS-DOS disklabel?

And also, are primary-type MBR slices always occupied first 4 non-reserved
letters like kernel Linux do it? Or the partitions got enumerated
[by first-time NetBSD disklabel creation] in by-LBA or by-table order
regardless of them being primary or secondary type?

(If the answer could only be found by RTFS, any idea which source file/
directory is responsible for this part?)

> in new ports, from after the change, there are just more low order bits
> for the partition identifier.   Care is needed (usually best to
> 	cd /dev; rm [a-z]*; ./MAKEDEV all
> if there's a need to switch between i386 and amd64 for example - sometimes
> MAKEDEV is in /etc rather than /dev, just in case someone does "rm *"
> instead of retaining the upper case names - which should be just MAKEDEV
> and MAKEDEV.local

Right, that's indeed an important gotcha to know.

>>  14. Does NetBSD have special driver which allow user to create custom
>>      block device which its I/O go to a userspace daemon
>>      instead of backing storage/files, which would allow administrator
>>      to write his own facility if the answer to #13 was no?
>
> yes, puffs.  or at least I think that does what you want, perhaps.

Erm, not quite that? I kinda already know that NetBSD supports FUSE
[PUFFS-reFUSE] at source level, but what I wanted was not an entire
daemon-backed filesystem-- I only wanted a single daemon-backed
block device node, which I could `mount` the kernel's own filesystem
driver upon.

And even if I'd actually implement a whole PUFFS filesystem
which would show up as a directory with lone block device node within;
wouldn't open()'ing such device node make block level I/O
go to a real device instead of being handled by a PUFFS daemon?

Or... you were rather suggesting that my theoretical PUFFS filesystem should
be designed to present a directory containing large virtual-image
[*regular*] file which could then be losetup^H^H^H^H^H^H^H "vnconfig"'d
into a block device; similar to how iSCSI has been implemented under NetBSD?

If that was the case... that's doable, I think.

Cheers,
Nutchanon Wetchasit

-----

[1] To others reading: as you probably already know, Thailand has been one
    of the places that the first-world west illicitly ship their e-trash to,
    to offload hazardous toxic-spewing guerrilla "recycling" process
    off their hands:

    https://www.nytimes.com/2019/12/08/world/asia/e-waste-thailand-southeast-asia.html

    ^ If paywalled, see:
      https://web.archive.org/web/20250425114411/https://www.nytimes.com/2019/12/08/world/asia/e-waste-thailand-southeast-asia.html

    E-trash "recycling" is a black joke no matter where you are;
    so for the love of land and sky, don't put still-functioning computers
    through such thing. Use your computer until it unrepairably break
    in your hand. Or if you have no use for it, give it to someone,
    donate it, eBay/Craiglist/classify-trade it, strip and sell/reuse
    each board/parts/cards: anything you can do to find new life for it;
    just DON'T "trade-in" or "recycle".