[TUHS] Unix install & "standalone" package

Dan Cross crossd at gmail.com
Tue Sep 5 04:21:21 AEST 2023


On Mon, Sep 4, 2023 at 1:08 PM Warner Losh <imp at bsdimp.com> wrote:
> [snip]
> There's a port of /boot/loader to illumos too, but I don't know
> if it is the default, or just available. So I'll not chat about it more.

I can confirm that it is the default on i86pc, though not universally.
At Oxide, for example, we boot directly into a very small loader held
in flash that has a compressed cpio archive containing the kernel and
a few necessary kernel modules compiled into it (as a byte blob); we
uncompress that blob into physical memory, locate and load the kernel
like a normal ELF binary, and jump to the kernel's ELF entry point,
passing a few basic arguments (notably, the location and length of the
cpio archive in physical memory). Entry to the kernel is thus in
64-bit mode with paging enabled.

> So the original 'standalone' environment where you had one program running on a system has evolved
> into either a rich boot loader environment that lets one do a lot to decide what kernel to load, or towards
> having a minimal selection of unix programs faster and using /bin/sh or similar to do scripting. These
> reduced environments are often called standalone, though all they share just the name with the earlier
> 'stand' programs: they are full unix programs, but with reduced feature sets and 'linker magic' to package
> them in a way that's faster, smaller, etc (eg all in one binary). FreeBSD's boot loader is an outgrowth
> of the original standalone env, by way of a port of NetBSD's libsa.
>
> I suspect in the future, we'll see more and more of a trend for low-level init and then handing off to some
> built-in kernel (be it Linux, BSD-based (there's now kexec), or whatever) to reuse more of the vetted code
> rather than re-inventing Unix inside the boot loader (which is a valid criticism of FreeBSD's boot loader,
> though it's rich feature set is what you get for the complexity).
>
> Does that answer the prompt? Should I try to make this into more of a retrospective paper and actually
> do the research on the areas I was hand-wavy about?

That would be interesting.

I can still remember booting IBM 6150 RTs into a miniroot environment
and using that to create and initialize filesystems when installing
AOS (4.3BSD for the RT) back in the day. To my mind, the standalone
programs were always oriented towards solving the related problems of
bootstrap initialization onto a fresh machine, and disaster recovery
when things were really, really messed up.

As I recall, the RT miniroot could either load from tape, or one could
`dd` it into swap and boot from that. In either case, I seem to recall
it was copied into memory and run as a RAM disk. The idea of busy-box
like "a bunch of utilities compiled into the same binary" was to save
space, particularly since this would be copied into RAM; even with
demand paging, redundant copies of bits from `libc` in each binary
were a waste for what was intended to be a minimal environment anyway.

        - Dan C.


More information about the TUHS mailing list