Date: Tue, 10 Nov 2026 23:29:27 +0700
From: Nutchanon Wetchasit <[email protected]>
Message-ID: <[email protected]>
| But I'm curious, what was the last NetBSD version that actually
| had been known to run on real i80386?
NetBSD 4 I believe, for actual releases, support for actual 386's was
dropped in 2007, and no longer present in NetBSD 5 when it was released.
(that is, 386 support was still there along the development train leading
from NetBSD 4 to NetBSD 5 - until it wasn't any more).
| 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.
OK.
| 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.
It is still used, and there are systems still being made that have
only 32 bit processors I believe. Not generally intended to be
workstations or the equivalent though.
| 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...
Yes,
| 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?
It is more complex than that, but that's close (not in block 0 usually, as
that might be the MBR). Very approximately, look for the first NetBSD
type partition in the MBR which has a label in it.
| Or... it only read so from block 0 of MBR slice which the NetBSD kernel
| booted from?
No, not that.
| And would that detection work if the slice was a logical type
| rather than a primary type in the MS-DOS disklabel?
I believe so, yes, but I have never made an x86 setup like that (in
any case I prefer to delete everything else and have only NetBSD).
I am not sure that it is possible to boot from an extended partition
however (using standard NetBSD booting) - I think there used to be a
restriction like that, but it might have been removed (I don't know).
| 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.
Typically, on an x86 system, I think the kernel would make a label
with the 'd' partition being the whole drive, and then the MBR
partitions assigned to partitions 'e' upwards I think. Again, I
have never tried to operate like that. For USB drives, typically
with a single FAT inside, that FAT becomes the 'e' partition of the
drive (sd1e or something - assuming sd1 was assigned to that drive).
If it had an MBR, and more than one partition, the remainder would be f g ...
(USB drives like that I have used, though most I use these days have
GPT partitions - either as they come, or I make them be that way.)
| 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?
Sorry, I can't answer that - nothing I am aware of, but that doesn't
mean there is nothing.
| 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)?
Sure, though for a typical (actual) i386 port, more than 4GiB is
going to be wasted isn't it, you'd need to be using i386pae to be
able to access more than 4GiB (32 bit pointers can only reference
so much) - and given the x86 architecture, some of that needs to be
reserved for bus access, etc.
You can use a tmpfs /tmp with anything (it uses VM, not physical ram).
How effective it is depends upon how big you need, and how big you can
make it (which can depend upon how much swap space you allocate.)
| ^ And does the default set of RC script still contain code to clear
| "/tmp" contents on startup?
Yes. It doesn't have a lot to do with a mounted tmpfs, but it does
it anyway.
| By mounting filesystem directly in such directories,
| it'd require 1 filesystem for each of such mount point (4 total).
Yes ... as I said, I like LOTS of filesystems.
| 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:
OK, yes, and yes, you can do that. /libexec /sbin /bin /lib /etc and /stand
(and I expect to be useful, /rescue) need to be on the root filesystem.
Beyond that, where things actually are shouldn't matter, though being
accessible via the normal paths certainly makes things easier.
| (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.
Yes, we have unionfs. It isn't guaranteed to be 100% bug free (but I use
it quite a bit). We also have mount -o union, but that is a quite
different thing.
| > 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",
s/wintrash/linux/ and that's about what I think of grub...
And sure, anything new is likely to have bugs, particularly in the
commodity market, and particularly with vendors attempting to make
things "just work" for users, despite most of the users having no
idea what is needed for that to happen.
| 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.
Note that disklabels, like MBR, can only address up to 4G sectors (typically
2TB drives, given 1/2KB sector size - 512B). Drives with a bigger
(exposed) sector size can be bigger, but those are very rare now, though
they were around in the early days of bigger than 2TB drives.
| It's PC/AT keyboard interface; originally used with a big thumb-sized
| cylindrical DIN plug.
I remember them. Ugly thing.
| Its modern form a.k.a. purple-colored PS/2 keyboard port which continued
| to be seen on mainboards today,
Not on my current ones, but I am sure it is still on many.
| 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.
See the sysctl hw.cnmagic (look at sysctl(7)).
| 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?
I'm not going to answer about OpenBSD - but assuming that was a thinko
for NetBSD, then kind of - I doubt anyone has ever attempted to dd it
out to a real floppy (and it is probably too big these days to fit on
one - 128KB doesn't hold much, and even the bigger, non-floppy floppy
discs are quite limited).
But there are (or were, not sure if anyone is bothering to keep them
alive - just like actual floppy drives) versions of NetBSD that booted
from floppy images (I think it needed more than one). I never did that,
CDs existed before I started using NetBSD on x86 type systems.
| 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 the kernel finds a label on the disk in a NetBSD "slice" it will
set the c partition of the label to be that slice. After that, I doubt
it is used for anything - but that it would get clobbered (in core)
every time you boot, would make assigning it to some other purpose,
other than temporarily, annoying at best.
| If so, are the non-reserved partition letters being /[a-be-p]/ ?
Practically, yes.
| 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?
It is reserved in the sense that the kernel seems not to care what you
write into the c slot in the label, and simply overwrites it with the
start/size of the MBR slice the label was found in. Beyond that, I can't
think of anything that cares about it.
'd' however is truly reserved (on x86's and other MBR using systems, on
other ports (sun, vax, alpha, ...) the reserved one this way is 'c' and
'd' is just general use.
| And also, are primary-type MBR slices always occupied first 4 non-reserved
| letters like kernel Linux do it?
No. It is very common for most MBR slices to not appear in a disklabel
at all (those parts of the disk are just ignored by NetBSD unless accessed
via the 'd' partition).
| 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?
I haven't looked into the parts of the kernel that do that enough to
answer.
| (If the answer could only be found by RTFS, any idea which source file/
| directory is responsible for this part?)
src/sys/kern/
subr_disk_mbr.c
subr_disklabel.c
subr_disk.c
init_main.c (just for the initial startup code).
There are more places that you may end up wanting to look at, but
I think most of it is in there. src/sys/arch/x86 and src/sys/arch/i386
might also contain something relevant (arch/amd64 for the 64 bit specifics).
You're also likely to need headers, the global ones
src/sys/sys (aka /usr/include/sys once installed)
disk.h
disklabel.h
bootblock.h (might also be interesting, but isn't about
labels)
but you will find more in the various src/sys/arch/*/include directories
(for the '*' elements that are relevant).
And actual boot code (for x86) is mostly in src/sys/arch/i386/stand/*
(not all of the '*'). (there's also src/sys/stand but I have no idea what
uses the efiboot code which is in there).
| 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.
I don't think we have one of those, but not knowing something exists
doesn't mean it doesn't.
| 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?
Probably, but I have never used puffs, so ...
kre
