* [TUHS] Unix install & "standalone" package @ 2023-09-04 9:57 Paul Ruizendaal via TUHS 2023-09-04 14:53 ` [TUHS] " emanuel stiebler 2023-09-04 17:07 ` Warner Losh 0 siblings, 2 replies; 8+ messages in thread From: Paul Ruizendaal via TUHS @ 2023-09-04 9:57 UTC (permalink / raw) To: tuhs Recently, I was looking into the “Das U-Boot” boot loader package. Summarised with great simplification, u-boot bundles device drivers, file systems, commands and a Bourne-like shell into a standalone package. Normally it auto-runs a script that brings up a system, but when used in interactive mode it allows a great deal of poking around. It made me think of the “standalone” set of programs for installing early Unix. On 16-bit understandably each basic command has to be a separate standalone program, but after the shift to 32-bit bundling more functionality in a single binary would have become possible. How did the Unix “standalone” package evolve in the 80’s, both in the research and BSD lineages? Is there any retrospective paper about that? Or is it a case of “Use the source, Luke”? ^ permalink raw reply [flat|nested] 8+ messages in thread
* [TUHS] Re: Unix install & "standalone" package 2023-09-04 9:57 [TUHS] Unix install & "standalone" package Paul Ruizendaal via TUHS @ 2023-09-04 14:53 ` emanuel stiebler 2023-09-04 17:07 ` Warner Losh 1 sibling, 0 replies; 8+ messages in thread From: emanuel stiebler @ 2023-09-04 14:53 UTC (permalink / raw) To: Paul Ruizendaal, tuhs On 2023-09-04 05:57, Paul Ruizendaal via TUHS wrote: > > Recently, I was looking into the “Das U-Boot” boot loader package. Summarised with great simplification, u-boot bundles device drivers, file systems, commands and a Bourne-like shell into a standalone package. Normally it auto-runs a script that brings up a system, but when used in interactive mode it allows a great deal of poking around. U-Boot has his roots in embedded systems, where you have a nice environment to debug your system. You have already everything there to download files with s-record from serial, boot from tftp, etc. Actually also setting up the memory controllers, timing, setting environment variables ... This became so comfortable, that sometimes the U-Boot code is larger than the target system. So, after development is done, the system jumps into the real application or code ... ^ permalink raw reply [flat|nested] 8+ messages in thread
* [TUHS] Re: Unix install & "standalone" package 2023-09-04 9:57 [TUHS] Unix install & "standalone" package Paul Ruizendaal via TUHS 2023-09-04 14:53 ` [TUHS] " emanuel stiebler @ 2023-09-04 17:07 ` Warner Losh 2023-09-04 18:21 ` Dan Cross 2023-09-05 11:15 ` Paul Ruizendaal via TUHS 1 sibling, 2 replies; 8+ messages in thread From: Warner Losh @ 2023-09-04 17:07 UTC (permalink / raw) To: Paul Ruizendaal; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 7235 bytes --] On Mon, Sep 4, 2023 at 3:58 AM Paul Ruizendaal via TUHS <tuhs@tuhs.org> wrote: > > Recently, I was looking into the “Das U-Boot” boot loader package. > Summarised with great simplification, u-boot bundles device drivers, file > systems, commands and a Bourne-like shell into a standalone package. > Normally it auto-runs a script that brings up a system, but when used in > interactive mode it allows a great deal of poking around. > > It made me think of the “standalone” set of programs for installing early > Unix. On 16-bit understandably each basic command has to be a separate > standalone program, but after the shift to 32-bit bundling more > functionality in a single binary would have become possible. > > How did the Unix “standalone” package evolve in the 80’s, both in the > research and BSD lineages? Is there any retrospective paper about that? Or > is it a case of “Use the source, Luke”? > The stand package continued in research and BSD to be those programs needed to install and/or recover badly damaged systems. You could create a new file system, copy a file from the tape to a partition, etc. You couldn't do general scripting with this, by and large. Originally, they were tape programs. This made sense because of its original focus. In time, some systems could load the stand alone programs instead of the kernel, but they continued the original focus. This is, imho, due in large part due to the miniroot. The miniroot evolved into both a full-enough system to do the installation scripts in shell instead of C (Venix, at least, had their install program written in C). You'd copy the minroot to swap and then install the system. But a number of additional programs were placed into the miniroot so you could do some limited filesystem repair, file editing, etc. In addition, many vendor's ROMs grew in complexity. Solbourne's ROMs, for example, could do basic repair of UFS (clri level, not fsck level), and copy files from one place to another. I often recovered a Solbourne system I screwed up by attaching an external SCSI drive that had a known good kernel, init, etc. The 'stand' environment was a whole set of tools that could be used to build stand-alone programs that shared much code of their full unix brethren, despite not having a full kernel under them. Kernel services were provided by different libraries that did filesystem things, block driver things, network things, etc in a similar way to Unix, but with a much reduced footprint. initramfs, as has been mentioned elsewhere, is pretty much a Linux invention. It was designed to 'punt' on the choose where to load things from and have a very minimal interface between the boot loader and the system. In time, it grew to support more interfaces, more ways of loading, and better ways to mount something that you could then 'pivot' onto. Few other unix systems went this route, though many adopted some variation on the pivot_root functionality. Linux has moved beyond the pivot root after having booted the correct kernel into being able to take over the machine early in, say, UEFI startup with a minimal kernel and initramfs that just knows how to load the next kernel. They skipped the complex boot loader stage, and went straight to the 'run linux earlier' stage which is how things like LinuxBoot, coreboot and others have put the boot logic into bash scripts. The ability to 'kexec' a kernel and replace the current running kernel originated in the 'non-stop' world that wanted to reduce downtime. Now, it's used to reduce firmware complexity by eliminating large swaths of UEFI from the boot process, but also generalizes in the embedded space. FreeBSD, from around FreeBSD 2 (1995 or so), had /rescue which largely took over form the stand alone environment for the repair duties of things. FreeBSD also adopted a more complex boot loader that would load the kernel, modules, set tunables, etc prior to kicking off the kernel. Between /rescue having all the tools needed to repair bad updates, repair failing disks, get that one last backup before the drive is dead while you wait for the new drive to be delivered, etc, and /boot/loader being able to script loading the kernel while the BIOS was still around so the need for drivers in the loader was lessened. However, as the BIOS evolved into UEFI and FreeBSD pushed into the embedded space whose firmware provided a less rich environment to the boot loader, so it was able to load things off fewer and fewer devices, it became clear that it would need a pivot root feature to allow it to boot all the way into FreeBSD, load some drivers from an included ram disk, and then use that mount a new root and then 'reroot' to that by killing everything and running init from that new root. FreeBSD also moved from Forth to Lua in its scripting language for the boot loader, giving 'pre boot' environment support better features. I also added the ability to use FreeBSD boot loader as a Linux binary to load FreeBSD and its metadata from a LinuxBoot environment. Finally, FreeBSD has 'spun out' and generalized the /rescue feature to allow creation of any 'BeastyBox' environment, similar to what you get in a busy box, or clone, environment. This environment, though, is meant in large part on both Linux and FreeBSD to be in constrained environments where a full install is prohibitive (even those that never pivot to something more, like ap, routers and nas boxes). NetBSD retains many of the old BSD stand-alone programs that started on the vax. I've not studied things beyond noticing this. OpenBSD is similar. Their boot chain is a bit simpler than FreeBSD's, though there's noises about porting FreeBSD's boot there. 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. 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? Warner [-- Attachment #2: Type: text/html, Size: 8399 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* [TUHS] Re: Unix install & "standalone" package 2023-09-04 17:07 ` Warner Losh @ 2023-09-04 18:21 ` Dan Cross 2023-09-05 11:15 ` Paul Ruizendaal via TUHS 1 sibling, 0 replies; 8+ messages in thread From: Dan Cross @ 2023-09-04 18:21 UTC (permalink / raw) To: Warner Losh; +Cc: Paul Ruizendaal, tuhs On Mon, Sep 4, 2023 at 1:08 PM Warner Losh <imp@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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [TUHS] Re: Unix install & "standalone" package 2023-09-04 17:07 ` Warner Losh 2023-09-04 18:21 ` Dan Cross @ 2023-09-05 11:15 ` Paul Ruizendaal via TUHS 2023-09-05 14:15 ` Clem Cole 2023-09-05 17:03 ` Warner Losh 1 sibling, 2 replies; 8+ messages in thread From: Paul Ruizendaal via TUHS @ 2023-09-05 11:15 UTC (permalink / raw) To: Warner Losh; +Cc: tuhs > 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 certainly answered the prompt, much appreciated the walkthrough. Currently just trying to get a view of the field and to collect recollections on how it was done back in the day. Part of it is finding a conceptual framework that can make sense of it all. One pitfall I would like to avoid in my own thinking is conflating “installing” and “booting”, even though the two seem related (one loads bits into permanent storage, the other into volatile storage; both are built around incrementally adding capability). When variable hardware comes into play, the two mix even more. Also related is the topic of recovery. The starting point seems to be a setup where a small set of standalone programs is used to load or repair the bits, as was done for 16-bit unix. A next conceptual step seems to be where first a very basic system is installed that is then used for further installation or for repair. This step seems to have come early, if this 32V install page is reflective of how it was done back in 1980: https://gunkies.org/wiki/Installing_32V_on_SIMH The idea to use disk swap space for this also seems to have come early (and I suppose the concept lives on in “rescue partitions”). Another conceptual step might be where early installer phases run a different, smaller kernel (or even OS) than the one being installed. There seems to be much potential for a “wheel of reincarnation” here where as an installer grows large, a pre-installer is created to load the installer and then the pre-installer grows large, etc. For booting, this wheel seems to have turned about 5 times in current Linux. Installing that from scratch on a fully blank SBC (without prepping a removable disk on another computer) also appears to have 4 or 5 revolutions. That is one revolution every 5 years for the 25 years from the late seventies to the early 2000’s. Then there is the question of where in the "installer stack" to stop. My current interest excludes (precursors to) package managers, containers, etc. In short: much to ponder, thanks to all for sharing recollections. > On 4 Sep 2023, at 19:07, Warner Losh <imp@bsdimp.com> wrote: > > > > On Mon, Sep 4, 2023 at 3:58 AM Paul Ruizendaal via TUHS <tuhs@tuhs.org> wrote: > > Recently, I was looking into the “Das U-Boot” boot loader package. Summarised with great simplification, u-boot bundles device drivers, file systems, commands and a Bourne-like shell into a standalone package. Normally it auto-runs a script that brings up a system, but when used in interactive mode it allows a great deal of poking around. > > It made me think of the “standalone” set of programs for installing early Unix. On 16-bit understandably each basic command has to be a separate standalone program, but after the shift to 32-bit bundling more functionality in a single binary would have become possible. > > How did the Unix “standalone” package evolve in the 80’s, both in the research and BSD lineages? Is there any retrospective paper about that? Or is it a case of “Use the source, Luke”? > > The stand package continued in research and BSD to be those programs needed to install and/or recover > badly damaged systems. You could create a new file system, copy a file from the tape to a partition, etc. > You couldn't do general scripting with this, by and large. > > Originally, they were tape programs. This made sense because of its original focus. In time, some systems > could load the stand alone programs instead of the kernel, but they continued the original focus. > > This is, imho, due in large part due to the miniroot. The miniroot evolved into both a full-enough system > to do the installation scripts in shell instead of C (Venix, at least, had their install program written in C). > You'd copy the minroot to swap and then install the system. But a number of additional programs were > placed into the miniroot so you could do some limited filesystem repair, file editing, etc. > > In addition, many vendor's ROMs grew in complexity. Solbourne's ROMs, for example, could do basic > repair of UFS (clri level, not fsck level), and copy files from one place to another. I often recovered a > Solbourne system I screwed up by attaching an external SCSI drive that had a known good kernel, > init, etc. > > The 'stand' environment was a whole set of tools that could be used to build stand-alone programs that > shared much code of their full unix brethren, despite not having a full kernel under them. Kernel services > were provided by different libraries that did filesystem things, block driver things, network things, etc > in a similar way to Unix, but with a much reduced footprint. > > initramfs, as has been mentioned elsewhere, is pretty much a Linux invention. It was designed to > 'punt' on the choose where to load things from and have a very minimal interface between the boot > loader and the system. In time, it grew to support more interfaces, more ways of loading, and better > ways to mount something that you could then 'pivot' onto. Few other unix systems went this route, though > many adopted some variation on the pivot_root functionality. Linux has moved beyond the pivot root after > having booted the correct kernel into being able to take over the machine early in, say, UEFI startup with > a minimal kernel and initramfs that just knows how to load the next kernel. They skipped the complex boot > loader stage, and went straight to the 'run linux earlier' stage which is how things like LinuxBoot, coreboot > and others have put the boot logic into bash scripts. The ability to 'kexec' a kernel and replace the current > running kernel originated in the 'non-stop' world that wanted to reduce downtime. Now, it's used to reduce > firmware complexity by eliminating large swaths of UEFI from the boot process, but also generalizes in > the embedded space. > > FreeBSD, from around FreeBSD 2 (1995 or so), had /rescue which largely took over form the stand alone environment > for the repair duties of things. FreeBSD also adopted a more complex boot loader that would load the > kernel, modules, set tunables, etc prior to kicking off the kernel. Between /rescue having all the tools needed > to repair bad updates, repair failing disks, get that one last backup before the drive is dead while you wait > for the new drive to be delivered, etc, and /boot/loader being able to script loading the kernel while the BIOS > was still around so the need for drivers in the loader was lessened. However, as the BIOS evolved into UEFI > and FreeBSD pushed into the embedded space whose firmware provided a less rich environment to the boot > loader, so it was able to load things off fewer and fewer devices, it became clear that it would need a pivot > root feature to allow it to boot all the way into FreeBSD, load some drivers from an included ram disk, and then > use that mount a new root and then 'reroot' to that by killing everything and running init from that new root. > FreeBSD also moved from Forth to Lua in its scripting language for the boot loader, giving 'pre boot' > environment support better features. I also added the ability to use FreeBSD boot loader as a Linux binary > to load FreeBSD and its metadata from a LinuxBoot environment. Finally, FreeBSD has 'spun out' and > generalized the /rescue feature to allow creation of any 'BeastyBox' environment, similar to what you get > in a busy box, or clone, environment. This environment, though, is meant in large part on both Linux and > FreeBSD to be in constrained environments where a full install is prohibitive (even those that never pivot > to something more, like ap, routers and nas boxes). > > NetBSD retains many of the old BSD stand-alone programs that started on the vax. I've not studied things > beyond noticing this. OpenBSD is similar. Their boot chain is a bit simpler than FreeBSD's, though there's > noises about porting FreeBSD's boot there. 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. > > 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? > > Warner ^ permalink raw reply [flat|nested] 8+ messages in thread
* [TUHS] Re: Unix install & "standalone" package 2023-09-05 11:15 ` Paul Ruizendaal via TUHS @ 2023-09-05 14:15 ` Clem Cole 2023-09-05 17:03 ` Warner Losh 1 sibling, 0 replies; 8+ messages in thread From: Clem Cole @ 2023-09-05 14:15 UTC (permalink / raw) To: Paul Ruizendaal; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 4922 bytes --] below.. On Tue, Sep 5, 2023 at 7:16 AM Paul Ruizendaal via TUHS <tuhs@tuhs.org> wrote: > One pitfall I would like to avoid in my own thinking is conflating > “installing” and “booting”, > That is an excellent point. I think that the real question comes back to how 'cold' the 'system' is. Booting is the process of making the processor 'live' including the loading of the 'initial memory contents' (IBM used to call it IPL for Initial Program Load), while 'installation' is setting up a 'system' which 'lives' in the peripherals as long-term storage. When you 'Power-On' a CPU, you often need to IPL a system even if the peripherals have been set up [back in the day of core memory, you might not even have that as the OS was not lost when power was removed]. > The starting point seems to be a setup where a small set of standalone > programs is used to load or repair the bits, as was done for 16-bit unix. > You are solving the 'chicken and egg' issue. Truth is Ken's famous "Reflections on Trusting Trust" comes to bear here. The fact is you are 'setting up' (or restoring) a system for bits that were generated on another. The critical point is that you are setting the initial 'systems' bits into the peripherals for that specific system. You are relying on making copies of those bits from another system. The question is how to get them into the new media. All the standalone system is doing is offering you a minimum way of making a copy of that other system without having access to its hardware directly. > A next conceptual step seems to be where first a very basic system is > installed that is then used for further installation or for repair. This > step seems to have come early, if this 32V install page is reflective of > how it was done back in 1980: > https://gunkies.org/wiki/Installing_32V_on_SIMH The idea to use disk > swap space for this also seems to have come early (and I suppose the > concept lives on in “rescue partitions”). > Newer versions of the system setup scheme offer more and more features, as the options of how you set up might be different from the origin system become greater and greater. Modern OS implementations of the Unix technologies now run on a much more comprehensive range of devices, and frankly, 'IPL' much less might be set up from so many different types of sources, it's not surprising that the IPL schemes and the system setup scheme are a lot more sophisticated. But remember, when you examine the past scheme, you must also consider the constraints of the timeframe (particularly the economics of certain choices). It's not that you could not have built something like some of today's schemes — it was expensive with respect to what was available and, frankly, not wholly necessary. > > Another conceptual step might be where early installer phases run a > different, smaller kernel (or even OS) than the one being installed. There > seems to be much potential for a “wheel of reincarnation” here where as an > installer grows large, a pre-installer is created to load the installer and > then the pre-installer grows large, etc. For booting, this wheel seems to > have turned about 5 times in current Linux. Installing that from scratch on > a fully blank SBC (without prepping a removable disk on another computer) > also appears to have 4 or 5 revolutions. That is one revolution every 5 > years for the 25 years from the late seventies to the early 2000’s. > The circle started long before that. For instance, the boot/IPL got more flexible (like Sam's autoconfiguration work developed for VAX). Why? Because the HW configurations had begun to branch and get bushy. Even with the PDP-11's peripheral set in V7, it was getting more complex. But those kernel configurations were statically linked. Sun added dynamic linking, making both IPL, much less setup/installation more complex. But frankly, to do that on an earlier machine took a lot of work. BSD2.9 did backport much of the VAX work but not all of it. It was often too difficult, and the 'gain' for the effort was low. So my modern UNIX implementations, be it macOS, *BSD, or the Linux family, the schemes have matured and been recreated over and over. For instance, you can look at what Apple's done with its system install scheme. It hides the setup/tear down as of the root and then makes a read-only root system under the covers. This is both a blessing and a curse. Sure, it helps make things a lot more secure for them and basic users, but that choice breaks traditional admin scripts [which drives me nuts think - /etc/periodic] because the new Apple system implementors don't understand why the core system works the way it does and thus those of us that have scripts have worked since V7 in the late 1970s, now don't. Clem ᐧ [-- Attachment #2: Type: text/html, Size: 9204 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* [TUHS] Re: Unix install & "standalone" package 2023-09-05 11:15 ` Paul Ruizendaal via TUHS 2023-09-05 14:15 ` Clem Cole @ 2023-09-05 17:03 ` Warner Losh 1 sibling, 0 replies; 8+ messages in thread From: Warner Losh @ 2023-09-05 17:03 UTC (permalink / raw) To: Paul Ruizendaal; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 13663 bytes --] On Tue, Sep 5, 2023 at 5:15 AM Paul Ruizendaal <pnr@planet.nl> wrote: > > 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 certainly answered the prompt, much appreciated the walkthrough. > Currently just trying to get a view of the field and to collect > recollections on how it was done back in the day. > > Part of it is finding a conceptual framework that can make sense of it all. > Yes. V7 and other early unix had a 'stand alone' framework. So that's one piece of the puzzle. It could be used for anything (I've seen private diagnostic stand alone programs at Solbourne that would do more extensive tests than the boot roms did for RMA and manufacturing line acceptance). But as they come down to us from AT&T, they are just the bits needed to install a system from scratch (or in some cases fix a system by booting the distribution tapes). > One pitfall I would like to avoid in my own thinking is conflating > “installing” and “booting”, even though the two seem related (one loads > bits into permanent storage, the other into volatile storage; both are > built around incrementally adding capability). When variable hardware comes > into play, the two mix even more. Also related is the topic of recovery. > There's "booting" and then there's "bootstrapping". booting happens all the time, but installation happens rarely. The problem is that the install process for V7 and earlier systems was to load a series of programs into memory from tape that did each step of the process to stay within the 64k limits imposed by the platform. That process was done by a series of standalone programs that could, in some cases, act as system repair for certain cases of 'afu' system. > The starting point seems to be a setup where a small set of standalone > programs is used to load or repair the bits, as was done for 16-bit unix. > Yea, that's where stand came from originally: An environment that could run a limited program w/o booting the kernel... > A next conceptual step seems to be where first a very basic system is > installed that is then used for further installation or for repair. This > step seems to have come early, if this 32V install page is reflective of > how it was done back in 1980: > https://gunkies.org/wiki/Installing_32V_on_SIMH The idea to use disk > swap space for this also seems to have come early (and I suppose the > concept lives on in “rescue partitions”). > Yes. It was quite common for the next step to be when demand paging became a thing. Once demand paging became a thing and you didn't need a dedicated swap partition, you could 'borrow' the installed system's swap partition (or what would become the installed system's swap partition) to have a richer set of tools. This would use otherwise wasted space for the install, then you'd overwrite it with whatever workload you put on your system. > Another conceptual step might be where early installer phases run a > different, smaller kernel (or even OS) than the one being installed. There > seems to be much potential for a “wheel of reincarnation” here where as an > installer grows large, a pre-installer is created to load the installer and > then the pre-installer grows large, etc. For booting, this wheel seems to > have turned about 5 times in current Linux. Installing that from scratch on > a fully blank SBC (without prepping a removable disk on another computer) > also appears to have 4 or 5 revolutions. That is one revolution every 5 > years for the 25 years from the late seventies to the early 2000’s. > Indeed, the whole linuxboot saga where you boot a minimal linux kernel that has a shell script (or similar) that decides where to load the complete kernel from is also interesting (doubly so to me because it means I can sneak in at that point and load FreeBSD onto the system). > Then there is the question of where in the "installer stack" to stop. My > current interest excludes (precursors to) package managers, containers, etc. > Yes. For me, the 'preboot environment' is a better mental framework to look at it with. Or 'pre-kernel' or 'non-kernel' environments. Though that paradigm runs out of steam in the 90s when people started booting kernels with bundled ram disks (in various flavors) to do the installation to allow boot medium to be used to load additional data (eg the system). The read/write nature of RAM made this vector useful, even when CDROMs appeared on the scene. It was easier to run off a ram disk than off the CDROM because you don't have to have symlinks to a (small) RAM disks for the bits of the system that needed to be read/write during the install process... The 'standalone' stuff, as typified by the src/stand directory, was all pre-kernel or non-kernel use-cases. Sometimes it was used to build a bit of code that had to be small, but was also used to build code to load the kernel (even dating back to the original boot loader for V7, though I'm relying on my memory which may be confusing that with the 2BSD bootstrap)... The stuff that was 'standalone-but-on-a-unix-kernel' came later. It might also be amusing to note: I once contemplated porting V7 unix to replace FreeBSD's stand environment to replace the various ad-hock hacks that had grown up. But I found that those hacks were smaller in the end, and needed less code space to support more things (excluding crypto and compression) than the V7 did once you started looking at modifying it to support multiple filesystem types, adding a network stack etc. While V7 is nice and clean, it's also immature in terms of features needed for a modern loader... Warner > In short: much to ponder, thanks to all for sharing recollections. > > > > On 4 Sep 2023, at 19:07, Warner Losh <imp@bsdimp.com> wrote: > > > > > > > > On Mon, Sep 4, 2023 at 3:58 AM Paul Ruizendaal via TUHS <tuhs@tuhs.org> > wrote: > > > > Recently, I was looking into the “Das U-Boot” boot loader package. > Summarised with great simplification, u-boot bundles device drivers, file > systems, commands and a Bourne-like shell into a standalone package. > Normally it auto-runs a script that brings up a system, but when used in > interactive mode it allows a great deal of poking around. > > > > It made me think of the “standalone” set of programs for installing > early Unix. On 16-bit understandably each basic command has to be a > separate standalone program, but after the shift to 32-bit bundling more > functionality in a single binary would have become possible. > > > > How did the Unix “standalone” package evolve in the 80’s, both in the > research and BSD lineages? Is there any retrospective paper about that? Or > is it a case of “Use the source, Luke”? > > > > The stand package continued in research and BSD to be those programs > needed to install and/or recover > > badly damaged systems. You could create a new file system, copy a file > from the tape to a partition, etc. > > You couldn't do general scripting with this, by and large. > > > > Originally, they were tape programs. This made sense because of its > original focus. In time, some systems > > could load the stand alone programs instead of the kernel, but they > continued the original focus. > > > > This is, imho, due in large part due to the miniroot. The miniroot > evolved into both a full-enough system > > to do the installation scripts in shell instead of C (Venix, at least, > had their install program written in C). > > You'd copy the minroot to swap and then install the system. But a number > of additional programs were > > placed into the miniroot so you could do some limited filesystem repair, > file editing, etc. > > > > In addition, many vendor's ROMs grew in complexity. Solbourne's ROMs, > for example, could do basic > > repair of UFS (clri level, not fsck level), and copy files from one > place to another. I often recovered a > > Solbourne system I screwed up by attaching an external SCSI drive that > had a known good kernel, > > init, etc. > > > > The 'stand' environment was a whole set of tools that could be used to > build stand-alone programs that > > shared much code of their full unix brethren, despite not having a full > kernel under them. Kernel services > > were provided by different libraries that did filesystem things, block > driver things, network things, etc > > in a similar way to Unix, but with a much reduced footprint. > > > > initramfs, as has been mentioned elsewhere, is pretty much a Linux > invention. It was designed to > > 'punt' on the choose where to load things from and have a very minimal > interface between the boot > > loader and the system. In time, it grew to support more interfaces, more > ways of loading, and better > > ways to mount something that you could then 'pivot' onto. Few other unix > systems went this route, though > > many adopted some variation on the pivot_root functionality. Linux has > moved beyond the pivot root after > > having booted the correct kernel into being able to take over the > machine early in, say, UEFI startup with > > a minimal kernel and initramfs that just knows how to load the next > kernel. They skipped the complex boot > > loader stage, and went straight to the 'run linux earlier' stage which > is how things like LinuxBoot, coreboot > > and others have put the boot logic into bash scripts. The ability to > 'kexec' a kernel and replace the current > > running kernel originated in the 'non-stop' world that wanted to reduce > downtime. Now, it's used to reduce > > firmware complexity by eliminating large swaths of UEFI from the boot > process, but also generalizes in > > the embedded space. > > > > FreeBSD, from around FreeBSD 2 (1995 or so), had /rescue which largely > took over form the stand alone environment > > for the repair duties of things. FreeBSD also adopted a more complex > boot loader that would load the > > kernel, modules, set tunables, etc prior to kicking off the kernel. > Between /rescue having all the tools needed > > to repair bad updates, repair failing disks, get that one last backup > before the drive is dead while you wait > > for the new drive to be delivered, etc, and /boot/loader being able to > script loading the kernel while the BIOS > > was still around so the need for drivers in the loader was lessened. > However, as the BIOS evolved into UEFI > > and FreeBSD pushed into the embedded space whose firmware provided a > less rich environment to the boot > > loader, so it was able to load things off fewer and fewer devices, it > became clear that it would need a pivot > > root feature to allow it to boot all the way into FreeBSD, load some > drivers from an included ram disk, and then > > use that mount a new root and then 'reroot' to that by killing > everything and running init from that new root. > > FreeBSD also moved from Forth to Lua in its scripting language for the > boot loader, giving 'pre boot' > > environment support better features. I also added the ability to use > FreeBSD boot loader as a Linux binary > > to load FreeBSD and its metadata from a LinuxBoot environment. Finally, > FreeBSD has 'spun out' and > > generalized the /rescue feature to allow creation of any 'BeastyBox' > environment, similar to what you get > > in a busy box, or clone, environment. This environment, though, is meant > in large part on both Linux and > > FreeBSD to be in constrained environments where a full install is > prohibitive (even those that never pivot > > to something more, like ap, routers and nas boxes). > > > > NetBSD retains many of the old BSD stand-alone programs that started on > the vax. I've not studied things > > beyond noticing this. OpenBSD is similar. Their boot chain is a bit > simpler than FreeBSD's, though there's > > noises about porting FreeBSD's boot there. 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. > > > > 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? > > > > Warner > > [-- Attachment #2: Type: text/html, Size: 15791 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* [TUHS] Unix install & "standalone" package @ 2023-09-04 14:44 Norman Wilson 0 siblings, 0 replies; 8+ messages in thread From: Norman Wilson @ 2023-09-04 14:44 UTC (permalink / raw) To: tuhs I don't remember any special many-programs-in-one binary like busybox in any Unix from the days when Unix was simple enough for me to understand. That covers the entire lifetime of the Research systems, but also System V and the BSDs and their sundry offspring up into at least the 1990s. I'm pretty sure OpenBSD at least still has nothing like busybox. The nearest thing was to make sure certain programs were linked statically (or existed in alternate statically- linked versions) so they would work before shared libraries were available. (It seems to be common wisdom that `sbin' means `system bin' these days, but I remember once, long ago, being told it stood for `static bin'.) Perhaps the question to ask is why such a magic program is needed at all. Is it just because programs like the shell have become so large and unwieldy that they won't fit in a small environment suitable for loading into an initramfs? Older UNIXes, even on the VAX, didn't use an initramfs. the boot code had just enough understanding of devices and file systems to load the kernel and to point it at the real root file system. The VAX hardware designers had a clever scheme on many (but, strangely, not all) VAX variants by which the hardware had several little boot ROMs, each containing a bare-bones read-only device driver for a particular device along with a few instructions to read the first sector into memory and start it, with pointers to the boot-rom driver and device ID in specified registers. That was enough to support a device-independent Unix boot block that could read unix (or another file name typed on the console) from the root of the file system at the start of the disk. I know it was because I wrote such a boot block, though I don't know whether anyone else did. (Other systems, I think, just used it to load /boot, a larger and more-capable program.) Maybe it was just that the boot environment was simpler in older systems, without the need to load kernel modules or support multiple locations and means of access for the root? Norman Wilson Toronto ON ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2023-09-05 17:04 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-09-04 9:57 [TUHS] Unix install & "standalone" package Paul Ruizendaal via TUHS 2023-09-04 14:53 ` [TUHS] " emanuel stiebler 2023-09-04 17:07 ` Warner Losh 2023-09-04 18:21 ` Dan Cross 2023-09-05 11:15 ` Paul Ruizendaal via TUHS 2023-09-05 14:15 ` Clem Cole 2023-09-05 17:03 ` Warner Losh 2023-09-04 14:44 [TUHS] " Norman Wilson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).