Re: i386-Misc questions: [non-]disklabel'd wd1X, initrd-floppy, PUFFS-vnconfig

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

    Date:        Tue, 10 Nov 2026 18:55:49 -0500
    From:        Greg Troxel <gdt%lexort.com@localhost>
    Message-ID:  <rmio6bwkzqy.fsf%s1.lexort.com@localhost>

  | > Labels written to the drive were a BSD invention (still earlier than
  | > MBR's I think - DOS (no windows at the time) was still generally just
  | > using floppies, if it existed at all).
  |
  | I guess I blurred 1976 and the early 80s!

I have been doing a little digging - it turns out that disklabels
appeared much later than I had thought (remembered) - the first code
for them was early 1987, that is after 4.3BSD, but before 4.3 Tahoe
(the next "release").   (The massbus hp.c driver vers 7.2).

Before then, the drivers mostly all had a big "This should be read
from the pack" comment just before the long list of partition tables
for every supported drive type (and even after on-pack labels were
supported, the code retained the in-driver partition labels, so it
could deal with packs that had been previously used, and had no
label written to them.)

Further, it appears as if none of the unibus drivers were ever really
updated to support on-pack labels, though there is an unchecked in
version of up.c (up.c.disklabel) from 1988 which has the label support.

  | I'm remembering an 11/40 reading from an RK05.  Perhaps incorrectly :-)

I don't think I ever booted a pdp-11 so I'm not sure - but a lot of the
time booting would have been from disk.   Recall these were back in the
days of genuine core memory, which didn't forget its contents due to
trivial little things like rebooting, or power off - at least in systems
I was familiar with, a normal boot would be from disk, using bootstrap
code left in core (the source of that word in its current usage) from
the previous boot, and just the same as the one before it, ...

When there was reason to suspect that piece of core was invalid,
(eg: it failed to work when attempted) then the console needed to be
used to enter the boot sequence (console as in buttons/switches, not
some keyboard like device), and then set the PC, and cause the processor
to jump to that location and start executing.

Generally it is much easier to read from a tape (from its current position)
- it just needs to be told "read" and then the data collected.  A disk
(of the time) needed to do a seek to the desired cylinder (the heads might
be anywhere) then have which track set (which head to use), and finally a
sector number to find, and then be told to read - lots more operations
required before data could start arriving (in even more primitive interfaces,
the code would need to watch the sector headers go past, and turn on data
reading at the correct place, but I doubt devices like that were ever
connected to a unix system).   Hence, true absolutely cold boots would
(in my experience) use tapes - far fewer words of code to need to enter
manually, than to read from a disk.  Once that had worked, the code to read
from the disk would be available, and boots after that would usually be done
that way.   Of course, if there was no reason to believe that the in-core
kernel had been corrupted, there was no need to load it at all, just
(effectively) jump to "main" and go (after which it would reinit all its
data structs, including clearing its BSS segment, just the same as it
would if just loaded into core with unknown contents).

kre