Re: i386 Installer questions: MBR slices, ext2fs root, bootblock location

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 4 Nov 2026 22:17:14 +0700
    From:        Nutchanon Wetchasit <xwindows%xwindows.in.th@localhost>
    Message-ID:  <7687cb0f-2bcb-7479-773e-9a8e2376ecf0%xwindows.in.th@localhost>

Khun Nutchanon:

Nice to see someone else in TH using (or planning on using) NetBSD.
(munnari.oz.au is an AU domain name, but it is located in Hat Yai).

  | I'm new to NetBSD, and I plan to experiment with NetBSD i386

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

  | in a (VirtualBox) VM

I have done that in the past, in general, it works fairly well
(using amd64 - I don't think VirtualBox existed when i386 was the
port to use for anything other than small dedicated single purpose
type systems).

  |  1. Is it possible to install NetBSD root filesystem _directly_
  |     as a MS-DOS disklabel slice (primary or logical type)
  |     without having to create a nested disklabel like FreeBSD did?

Not really, though I'm not sure it couldn't be made to work - the kernel
would create a disklabel for its internal use anyway.   NetBSD doesn't
really use the MBR at all, after booting, and finding the (primary) NetBSD
slice - everything else uses the disklabel.

Note that 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.   Of course, by default it will be related, the
disklabel will have partitions for whatever NetBSD pieces of the drive
exist (whole MBR slides, or pieces of NetBSD slices), and others for any
other MBR partitions that exist (usually).  But once created it can be
modified however you desire.

  |       And if the NetBSD disklabel was really required, was that an
  |       installer-level (i.e. the TUI installer won't allow proceeding
  |       in other way),

That for sure.

  |       kernel-level (i.e. the kernel won't find its root without BSD
  |       disklabel),

Not sure about that one, the kernel might have created its own
label if one doesn't exist, before that becomes an issue.   But inside
the kernel, if GPT "wedges" (instead of "slices") are not being used,
there must be an in-kernel disklabel for each drive.   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 doesn't really matter, it
must exist (and to be useful for the system admin, it really needs to
be recorded in the primary NetBSD slice, so it doesn't just randomly
change from boot to boot, just because something else wasn't quite the
same.)

  |       or bootloader-level limitation (i.e. the stock
  |       bootloader won't read the file system without BSD diskabel)?

No idea on that one.

  |     I have an unusual on-disk partitioning, and tinker with disks
  |     and partitions at block level from time to time; so I would like
  |	to avoid the complexity of nested partitions if doing so was possible.

If you can do GPT partitioning, as Greg suggested, instead of MBR, then
that won't be an issue, with any system, one GPT partition is one OS partition,
always (of course, you can then supply that partition to a virtual OS, which
will treat it as a drive, and if it wants, partition it).

But if you're using i386 because the hardware you want to use is really
that old (and it still works??) then it probably won't support GPT in
the BIOS, and require MBR partitioning.   Even some of the older amd64
systems are too old for GPT.   (nb: "amd64" applies to 64 bit x86 type
systems, regardless of who makes the processor chip, not only for
AMD chip systems - the only thing it won't work with is Intel's ia64
architecture, but the chances that you have one of those are so close
to zero, I'm just going to ignore it ... but if I'm wrong, you definitely
need the ia64 port for that, neither i386 nor amd64 will work - on the
other hand, i386 probably might kind of work on a 64 bit processor, just
using it in 32bit only mode).

  |  2. Is it possible to install NetBSD in a manner which everything
  |     (root, home, dev, usr, tmp, var, etc) were confined in a single
  |     root filesystem, with *NO* swap space? If so, would it require
  |	completing some parts of the installation outside of a TUI installer
  |     in order to make it so?

Definitely possible.   And the installer should allow that setup.

  |     Note that the single-root scheme is actually my preferred filesystem

I prefer the exact opposite, lots of separate filesystems, that way I can
have any not in current use unmounted, and any that are just there to be
looked at, mounted read only.   Vastly speeds up boot time when it isn't
necessary to fsck everything after a crash or power failure - but I
probably have more NetBSD filesystems (like 80TB or something approaching
that) than you're likely to be using.

  |  3. Is it possible to use Linux ext2fs filesystem type as a NetBSD
  |     *root* partition?

Perhaps, but not a good idea as Greg mentioned, NetBSD's ext2fs support
is not great, it really needs someone to spend some time working on it.

It works OK when only used to hold files for transfer between systems,
that is, the actual file is elsewhere, so if the NetBSD shared extfs
gets corrupted, you can just make it again, without losing anything
except some time.

  | If it was, could it be partitioned/formatted/chosen
  | directly from TUI installer;

I don't believe that is supported.

  | or such partition had to be manually created
  | and formatted on command line (or from GNU/Linux system) beforehand,

I believe the general wisdom is that 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.

  |     then chosen as a root in the installer afterward?

Even that might not work (but it is really easy to install NetBSD
by hand, takes longer than using sysinst, because you have to type in
all the steps, but it isn't at all difficult to do, you just need to make
sure all the right things get done, which in general sysinst does for you).

  |     If not, would it be okay to use Linux ext2fs as NetBSD home, usr, tmp,
  |     and var?

OK, yes; but a good idea, almost certainly not (and in any case, /tmp should
normally be a tmpfs (in memory filesystem)).

  | 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.

You can have multiple "/home" type filesystems (or any of the others)
and just mount whichever one you need right now as /home (and if you
want to access the others, mount them elsewhere).

  |     (I understand that the installer itself likely won't allow doing this,
  |     but I'll do so manually when needed)

It won't set up symlinks for you, it will allow you to make separate
partitions for all of those things, and arrange for them to be mounted
in the proper places (which you can change later if you like, mount
what would be /usr as /mount/drive3/partition7 if you like, then symlink
/usr to that, but again, why?)

  |  4. Is there any inherent system (mainboard/pheripheral)-specific
  |     information or driver binding/loading configuration that is
  |     recorded as a part of installation process, that would make a
  |     NetBSD installation _not_ work with other (NetBSD-compatible) computer?

"Any other" yes sure, but later you said "same CPU architecture", so you
obviously know an i386 system isn't going to run on an ARM processor
(or a 68k, vax, sparc, ...).

Given that restriction, if you remain running the normal installed (big)
generic kernel, the kernel will run on anything (supported) of the same
architecture (though its label is "i386" we no longer support actual 386
processors, 486 is the earliest of the intel range supported).

However, you can also configure a (usually turns out to be quite a bit
smaller) kernel which supports just the hardware that exists on your
system, and not everything that anyone anywhere might have on theirs,
in which case that kernel would only work on systems with the same
hardware.  You can also compromise on the config - include everything
that is likely to be needed, exclude everything that you cannot imagine
ever having on one of your systems (tape drives?  Firewire?)
Doing all this is for after the system is running using the generic kernel
however.

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.
If you install on a system with wm interfaces (Intel chips) and move
to a system with rge (Realtek chipset) interfaces, then the network
configuration set up for the wm0 interface will be ignored (as that
doesn't exist) and no config will be found for the rge0 interface which
the original system didn't have.   Of course, you can provide config
for all of the interface types you're likely to ever see if you want to.
(That is just one of many network related config issues - some of it
can be avoided if you just allow everything to be auto configured, ie:
start the dhcp client and allow it to configure everything it finds,
with no overrides, or anything needed, but I suspect not all, firewall
configs, etc, tend to also have interface names built in).

Graphics can differ as well, though how much of that needs any specific
config isn't clear to me.

There is probably more.

  |  5. Is it possible to install and boot NetBSD without changing MBR code,
  |     by putting NetBSD bootloader at the BSD disklabel (or root filesystem)'s
  |     block 0?

Yes.   In fact, that's where it goes.  There needs to be a bootloader
in the MBR, or the system won't boot at all, but that is a VERY simple piece
of code - NetBSD will install one if needed (maybe even most times) but
anything able to get the NetBSD 2nd stage boot will work for that.
(netBSD boot has three stages on legacy (MBR) systems, the mbr boot
block, the 2nd stage boot loader, in the NetBSD partition near the disklabel,
and then /boot - each of the first two just gets to the next).

EFI booting is different however.

  |     ^ I have to ask this because if/when I decided to make NetBSD
  |       go bare-metal, I intend to continue using GNU GRUB 0.9x

To each their own.   The only thing I would ever do with GRUB is attempt
to make it vanish, which (the last time I needed to do that, some time
ago now) was astounding difficult to do, it seemed to be like a very
determined virus, just would not go away!

  |       as the MBR-level boot manager.

If your systems support EFI, and GPT, then EFI booting, using the firmware's
boot manager, is a much better way (that can be made to boot GRUB if you
happen to need it, but it can also just boot systems as desired, without
all of GRUB's nonsense.)

  |        Which if the answer was not,
  |       I would then workaround by having GRUB chain-load to a detached
  |       NetBSD bootloader/bootblock file instead.

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

  |  6. If #5 was true, is it possible to make BSD disklabel
  |     (or root filesystem) a MBR-level logical partition;

If you can make booting work somehow, NetBSD simply doesn't care what
kind of MBR partition it exists in (if any at all).   As above, it uses
the disklabel for everything.

  |  7. Would the stock NetBSD bootloader continue to work if I backed up
  |     the entire disklabel or root partition at block level,
  |     then restore it verbatim as a different active primary MBR partition
  |     that wasn't the same Nth parition it originally was,
  |     and located at a *different LBA start address*?

It should, at least using FFS filesystems - all block numbers in those
are relative to the start of the (disklabel) partition - you would need
to update the disklabel however.   Yet another reason why GPT is better,
with that, there is no disklabel involved any more, the GPT partitioning
info supplies everything needed.

  |  8. Is NetBSD kernel bootable from GNU GRUB 0.9x (GRUB1) in any method

Can't answer that one, I simply don't know.   (For any GRUB version).

  |  9. I saw mentions of the term "bootblock" in the user guide, which
  |     I take it to mean "bootloader"; but what I did not expect
  |     was it to appear in the TUI installer step where the administrator
  |     chose which type of text console to use.

I'd need more context to understand what that is all about.

  |     Does this mean that under NetBSD, it was the bootloader's actual duty
  |     to handle console I/O?

I/O while it is booting, certainly - once the kernel is running, the
bootloader is gone, it can't do anything any more.  The kernel takes
care of its own I/O - initially using firmware services (different ones
for old ("legacy") systems then EFI) for console I/O, then eventually
(during the early boot sequence, once the relevant hardware has been
identified) switches to doing everything itself, directly to the hardware.

  | 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.

  |     It's one of the weirder to questions ask,
  |     but I deem 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?   Seems unlikely to work, but that is the traditional console
for i386 type systems (keyboard, mouse, and monitor, all separate objects).

If you're using a serial console, that kind of thing should be able to
be made to work, if needed.

  | 11. Is NetBSD kernel (at the most basic level that could still properly
  |     start init process/PID 1 process) a single file? If so, what
  |     is the default path of that file within the root filesystem?

You mean /sbin/init (see init(8) man page), but that's just init (pid 1).
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 (except for some installation systems with a memory
filesystem included in the image, in which case the whole (minimal) root
filesys is in there).

  | 12. What is the device node pathname pattern used for referring to each
  |     MBR partition (MS-DOS disklabel slice) on PATA-IDE disk?

There is none, NetBSD doesn't refer to MBR partitions, only GPT or disklabel
partitions - if MBR is in use, any partitions it has need to be added to
the disklabel, and then it has a standard disklabel partition name (see below).

  |     Is it different when the disk was SATA-AHCI?

No.   Those are fundamentally the same thing (logically) just totally
different electronically/physically.

It is different if it is NVMe or SCSI or other technologies, but SATA and PIDE
all share the same namespace.

  |     What happens if it was a logical MBR partition?

Irrelevant, only the disklabel matters.

  |     And what suffix will be used
  |     when referring to a subpartition inside a NetBSD disklabel?

A PIDE or SATA drive will be called wdN for some integer N (/dev/wd0 for
example).   That device (if it is using an MBR) will have a disklabel
(recorded on the drive, or cobbled together from the MBR, though no-one
does that routinely) 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.  In practice it simply isn't
used, as there isn't necessarily a "the NetBSD MBR partition" there
can be several.  I suspect there would be no real problem if 'c' was
just used for some specific partition (but beware, other NetBSD ports,
like sparc and sun3 and vax I think, probably many more, that have
no concept of an MBR at all, use 'c' where the x86 ports use 'd').
in practice, that all means a max of 14 partitions on each drive when
disklabels are used (with GPT you can have thousands if you desire,
the normal default is up to 128).

  |     Would it look like "/dev/wd1da" for the first partition within
  |     a NetBSD disklabel that is the fourth MBR primary partition
  |     located in the second disk in the system?

No.  It would be (perhaps) wd1h or something, though the 'h' can be
any of a, b, d, e, ... p that you desire to assign to that partition,
they don't have to correspond to any particular ordering on the drive.
Which MBR partition they happen to be in is irrelevant.

  |     Also, is NetBSD one of those kinds of Unix system which require
  |     a separate "raw" device node corresponding to each of hard disk
  |     for alternate mode of block-level access?

Yes, /dev/rwd0 /dev/rwd0a etc.

  |     (And is there any kind of "master list" of all major-minor character
  |     and block device number that NetBSD recognize and the device node
  |     name that would usually go with each of them?)

yes, though off hand I don't remember where it is to be found.   But again
beware, because of historical issues, some of the device numbers, etc,
vary from port to port - all the more modern devices have well known major
numbers (driver identifier number effectively) but in the early days, and
for compatibility with the native systems that NetBSD was replacing, some
of the major numbers vary from one port to another (so if an alpha had a
wd0 drive, its major number might be different from that of an x86).
The encodings of the minor numbers (unit number, and partition) can
vary as well - in the ancient past there were just 8 partitions in a
disklabel (a-h), encoded in the bottom 3 bits of the minor device number.
The bits above that were the unit number.   Then dev_t's became wider,
and on those ports, the extra bit needed to make 16 partitions had to
be placed higher than the unit number, whereas 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

  | 13. Does NetBSD's CGD disk encryption driver provide a mode which
  |     is drop-in compatible to metadata-less Loop-AES [4] (especially
  |     a multi-key-v3 [64 keys + 1 init vector] AES-128 variant)
  |     disk encryption scheme, like kernel Linux does?

Sorry, no idea on this one.

  | 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.

kre