Nutchanon Wetchasit <[email protected]> writes: > 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.
I am not sure it is possible and it is definitely not a good idea. If you use GPT, you can avoid all this. The VM guest doesn't need to see the host partitioning; it can just have space from your host LVM, and do GPT in that. My advice is don't fight nested labels within a block that's hosted. It won't help you to win that at all. > 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] Yes that's fine. I think you can do it with the installer. Not even odd. > 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. Maybe, but NetBSD's ext2fs code is not 100% ok and it is missing features so you have to create any shared ext2fs from NetBSD. > 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? No, unless you have to use userconfig at boot time. The kernel has drivers, and things are probed at boot. > 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] Yes, if an install would have succeeded on the new one. [more later unless somebody else answers]
