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

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

Hello,

I'm new to NetBSD, and I plan to experiment with NetBSD i386 in a
(VirtualBox) VM when I clear out enough of my disk space to download
the installer CD.

I had a passing experience under FreeBSD 6.0 as a user nearly 2 decades ago,
but most of my Unix-like experience in the last 20 years has been GNU/Linux;
so in the meantime, I have started skimming and skipping through NetBSD
user guide and various related documents to see what's actually like
to install and configure NetBSD. The documentation answered some questions
I originally meant to ask, but it brought several more questions.

So please excuse me being here asking about these weird kinds of
unusually-specific niche things that might be otherwise considered an "expert"
questions of system installation/operation; as a complete beginner.

I have done/been-doing much of the stuffs I'm going to about,
but on GNU/Linux; so I would like to understand more about if/how things
I understood would translate to NetBSD world, and what are additional caveats
I have to be aware of; considering assumptions I might have,
coming from that side.

(Note: I haven't actually got a chance read the manual back-to-back yet,
so if any of these questions deserved "RTFM" as an answer, it probably is;
but please, please actually link to the thing I could actually go
read it too)

 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?

    ^ The installer itself apparently said that the nested disklabel
      was required [1]; but I would like to ask for sure whether
      it was an absolute requirement, especially _if_ NetBSD
      was installed manually without using the installer.

      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), kernel-level (i.e. the kernel won't find its root
      without BSD disklabel), or bootloader-level limitation (i.e. the stock
      bootloader won't read the file system without BSD diskabel)?

    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.

 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?

    Note that the single-root scheme is actually my preferred filesystem
    scheme all of my past and current GNU/Linux systems in the last
    20 years, for simplicity in block-level arrangement
    and for any block-level intervention/tinkering I need or want to do. [2]

 3. Is it possible to use Linux ext2fs filesystem type as a NetBSD
    *root* partition? If it was, could it be partitioned/formatted/chosen
    directly from TUI installer; or such partition had to be manually created
    and formatted on command line (or from GNU/Linux system) beforehand,
    then chosen as a root in the installer afterward?

    If not, would it be okay to use Linux ext2fs as NetBSD home, usr, tmp,
    and var? And would it okay for the `/home`, `/usr`, `/tmp`, and `/var`
    on NetBSD root filesystem to be symlinks to other mounted filesystems?
    (I understand that the installer itself likely won't allow doing this,
    but I'll do so manually when needed)

    ^ Note that I wanted to do this because I would like as much as possible
      of my NetBSD install to be readable/writable from GNU/Linux
      for diagnostics and data exchange reasons.

 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?

    I.e. if I installed NetBSD on one (NetBSD-compatible) computer
    in a usual way, then unplug its hard disk and move it
    to another (NetBSD-compatible) computer of the same CPU architecture
    but different brand of mainboards and peripheral cards;
    would the moved NetBSD instance still boot and use the new hardware
    automatically? [3]

 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?

    ^ 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
      as the MBR-level boot manager. Which if the answer was not,
      I would then workaround by having GRUB chain-load to a detached
      NetBSD bootloader/bootblock file instead.

 6. If #5 was true, is it possible to make BSD disklabel (or root filesystem)
    a MBR-level logical partition; while retaining non-MBR bootloader's
    bootability described in #5?

 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*?

 8. Is NetBSD kernel bootable from GNU GRUB 0.9x (GRUB1) in any method
    other than primitive boot sector chain-loading at MS-DOS disklabel level?
    (A la `makeactive` and `chainloader +1` under GRUB shell)

    ^ If no, what about GNU GRUB (GRUB2) 1.x?

 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.

    Does this mean that under NetBSD, it was the bootloader's actual duty
    to handle console I/O? (Or, it was rather just the console type selection
    was being a parameter baked into the bootloader to be given to the kernel,
    and it was actually the kernel that handled console I/O?)

10. Is NetBSD console I/O (especially serial console) 8-bit clean
    and binary-safe? 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
    sitting in a server room somewhere far; so I would like to know
    if I'd have to apply any workaround for that use in case of NetBSD.

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?

    (On all systems based on kernel Linux, the answer would be yes;
    with the file path being "/vmlinux", "/vmlinuz", "/zImage",
    or "/bzImage" depending on the whim of distribution in question)

12. What is the device node pathname pattern used for referring to each
    MBR partition (MS-DOS disklabel slice) on PATA-IDE disk?
    Is it different when the disk was SATA-AHCI? What happens if it was
    a logical MBR partition? And what suffix will be used
    when referring to a subpartition inside a NetBSD disklabel?

    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?

    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?

    (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?)

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?

    I don't see any mention of loop-AES anywhere in CGD manual page [5],
    so the answer was probably NO for multi-key-v3 mode;
    but there are mentions of AES-128/AES-256 CBC-- are those compatible
    with Loop-AES v1 [single-key] mode?

    (There are userspace tools for encrypting/decrypting such volumes,
    but the lack of random access would mean no practical access
    on filesystems inside them as such tools could only do wholesale
    decryption/re-encryption)

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?

    (Kernel Linux provides this in its Network Block Device [NBD] facility.
    What is NetBSD's offline/online analog of it, if any?)

Please advice,
Nutchanon Wetchasit

-----

[1] https://www.netbsd.org/docs/guide/en/netbsd.html#exinst-disklabel
    https://www.netbsd.org/docs/guide/en/netbsd.html#chap-inst-install-partition

[2] Also, on the hard disk of multi-booting machine I'm typing this on:
    there are 3 bootable GNU/Linux installations, 2 bootable FreeDOS
    installations, 1 bootable live GNU/Linux not-quite-installation,
    1 bootable GNU/Linux installer (don't ask why); all bare-metal,
    and several more if I count VMs.

    So, I'd need all partitioning simplicity I could get, if/when
    I actually transfer (by the means of `dd`) my VM-based NetBSD install
    into a bootable bare-metal partition without re-installing it.

[3] If I asked the same question, but with GNU/Linux as an OS,
    the answer would be yes (I tested firsthand); but for Microsoft Windows,
    the answer has been no.

    I don't consider the lack of this ability to be a show-stopper;
    but it is something I have to keep in mind, because what I wrote
    at the end of footnote [2] is what I intend to eventually try.

[4] https://loop-aes.sourceforge.net/

[5] https://man.netbsd.org/NetBSD-11.0/cgd.4