The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] Pre-init initialization
@ 2019-08-06 23:46 Grant Taylor via TUHS
  2019-08-07  1:22 ` Andrew Warkentin
                   ` (2 more replies)
  0 siblings, 3 replies; 17+ messages in thread
From: Grant Taylor via TUHS @ 2019-08-06 23:46 UTC (permalink / raw)
  To: The Unix Heritage Society

[-- Attachment #1: Type: text/plain, Size: 235 bytes --]

Do, or did, anything other than Linux use a concept of an initramfs / 
initrd to create a pre-(main)-init initialization environment to prepare 
the system to execute the (main)-init process?



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4008 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] Pre-init initialization
  2019-08-06 23:46 [TUHS] Pre-init initialization Grant Taylor via TUHS
@ 2019-08-07  1:22 ` Andrew Warkentin
  2019-08-07 13:04 ` Clem Cole
  2019-08-10  1:45 ` Chris Hanson
  2 siblings, 0 replies; 17+ messages in thread
From: Andrew Warkentin @ 2019-08-07  1:22 UTC (permalink / raw)
  To: The Unix Heritage Society

On 8/6/19, Grant Taylor via TUHS <tuhs@minnie.tuhs.org> wrote:
> Do, or did, anything other than Linux use a concept of an initramfs /
> initrd to create a pre-(main)-init initialization environment to prepare
> the system to execute the (main)-init process?
>

Off the top of my head I'm not aware of any other conventional Unix
besides Linux that uses a memory filesystem for early userspace.
Solaris does use a memory filesystem during boot, but it normally
contains only kernel modules and is only read by the kernel module
linker, and IIRC AIX uses a weird vaguely zImage-like format for its
boot image but I can't remember if the image contains just the kernel
and some modules or if there are userspace programs in it.

As far as unconventional Unix-like OSes go, QNX Neutrino (but not QNX
2 and 4) and Plan 9 both use in-memory filesystems during early
userspace boot, although both only load a single image from disk
rather than a separate kernel and ramdisk. In QNX, the image is a
page-oriented XIP filesystem that contains the kernel and early
userspace as regular files, and in Plan 9 the image is the kernel
executable, which contains a minimal embedded filesystem with a few
user-mode programs.

UX/RT, the OS that I'm writing, will also boot from a memory
filesystem containing the kernel and early userspace in a similar
manner to QNX (it's loosely based on QNX and Plan 9 but is not a clone
of either), although currently it isn't running any real userspace
programs.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] Pre-init initialization
  2019-08-06 23:46 [TUHS] Pre-init initialization Grant Taylor via TUHS
  2019-08-07  1:22 ` Andrew Warkentin
@ 2019-08-07 13:04 ` Clem Cole
  2019-08-07 16:40   ` Warner Losh
  2019-08-09  1:46   ` Grant Taylor via TUHS
  2019-08-10  1:45 ` Chris Hanson
  2 siblings, 2 replies; 17+ messages in thread
From: Clem Cole @ 2019-08-07 13:04 UTC (permalink / raw)
  To: Grant Taylor; +Cc: The Unix Heritage Society

[-- Attachment #1: Type: text/plain, Size: 1459 bytes --]

A couple of the commercial systems did this for sure. Linux definitely
picked it up from UNIX practices, although I have no idea/memory of who did
it first.  We used the idea at Stellar (Stellix) and at Masscomp (RTU).
IIRC, a couple of others like Pyramid made have created a RAMFS - but it
was kicking around the UNIX community for a fairly long time - certainly in
the late 1970s - *i.e.* post V7.

FWIW: V7 had /stand which was a funky UNIX-like standalone system that some
applications could be compiled.  The problem was that it was a little
different so you would end up seeing #ifdef STAND in code for things like
fsck, fsdb, even cat.  At Masscomp we ended up with three target
environments for a couple of the system maintenance utilities: the OS,
/stand and the boot ROMS.   This was expensive/a PITA to maintain and keep
straight, and in the case of the boot ROM, space was a huge problem.

The RAMFS idea was created to get rid of at least /stand and IIRC we were
able to drop a number of utilities out of the boot ROM.  I'm not sure how
far they took it.   I left for Stellar and it was always the way Stellix
booted.



On Tue, Aug 6, 2019 at 7:47 PM Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
wrote:

> Do, or did, anything other than Linux use a concept of an initramfs /
> initrd to create a pre-(main)-init initialization environment to prepare
> the system to execute the (main)-init process?
>
>
>
> --
> Grant. . . .
> unix || die
>
>

[-- Attachment #2: Type: text/html, Size: 2401 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] Pre-init initialization
  2019-08-07 13:04 ` Clem Cole
@ 2019-08-07 16:40   ` Warner Losh
  2019-08-08 13:31     ` Theodore Y. Ts'o
  2019-08-08 13:43     ` Clem Cole
  2019-08-09  1:46   ` Grant Taylor via TUHS
  1 sibling, 2 replies; 17+ messages in thread
From: Warner Losh @ 2019-08-07 16:40 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Unix Heritage Society, Grant Taylor

[-- Attachment #1: Type: text/plain, Size: 2916 bytes --]

The move into RAM disks happened as memories grew. This obviated the need
to copy a filesystem to a new disk's swap space and then use that to really
install the system.

Kernels with bundled RAM disks were a thing in BSD for a long time, though
I'm unsure when that functionality entered the code stream. I know the
early versions of FreeBSD's installer ran out of a RAM disk loaded off
floppies, though that's not the same as initrd since there never was a
pivot to something else: just a reboot to boot the real thing.

FreeBSD, at least, has the functionality to also do a RAM disk to get
things configured enough to pivot to the real disk on boot, but that's a
niche operation there: most everybody just boots off / directly without the
initrd-like thing. It's rarely needed, but it's one of those things that
when it is needed, it's really needed, which is why one can do it.

FreeBSD has an interesting 'tertiary loader' that plays a similar role to
initrd. It orchestrates loading of modules, setting tunable parameters and
launching the kernel. It's grown up to be a mini-kernel stand-alone
program, but as the real kernel is now 28MB, the boot loader leverages off
'boot services' or other well-known interfaces to weigh in at only a few
hundred k. This has proven to be both a blessing and a curse at times,
however.

Warner

On Wed, Aug 7, 2019 at 7:05 AM Clem Cole <clemc@ccc.com> wrote:

> A couple of the commercial systems did this for sure. Linux definitely
> picked it up from UNIX practices, although I have no idea/memory of who did
> it first.  We used the idea at Stellar (Stellix) and at Masscomp (RTU).
> IIRC, a couple of others like Pyramid made have created a RAMFS - but it
> was kicking around the UNIX community for a fairly long time - certainly in
> the late 1970s - *i.e.* post V7.
>
> FWIW: V7 had /stand which was a funky UNIX-like standalone system that
> some applications could be compiled.  The problem was that it was a little
> different so you would end up seeing #ifdef STAND in code for things like
> fsck, fsdb, even cat.  At Masscomp we ended up with three target
> environments for a couple of the system maintenance utilities: the OS,
> /stand and the boot ROMS.   This was expensive/a PITA to maintain and keep
> straight, and in the case of the boot ROM, space was a huge problem.
>
> The RAMFS idea was created to get rid of at least /stand and IIRC we were
> able to drop a number of utilities out of the boot ROM.  I'm not sure how
> far they took it.   I left for Stellar and it was always the way Stellix
> booted.
>
>
>
> On Tue, Aug 6, 2019 at 7:47 PM Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
> wrote:
>
>> Do, or did, anything other than Linux use a concept of an initramfs /
>> initrd to create a pre-(main)-init initialization environment to prepare
>> the system to execute the (main)-init process?
>>
>>
>>
>> --
>> Grant. . . .
>> unix || die
>>
>>

[-- Attachment #2: Type: text/html, Size: 4055 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] Pre-init initialization
  2019-08-07 16:40   ` Warner Losh
@ 2019-08-08 13:31     ` Theodore Y. Ts'o
  2019-08-09  1:52       ` Grant Taylor via TUHS
  2019-08-08 13:43     ` Clem Cole
  1 sibling, 1 reply; 17+ messages in thread
From: Theodore Y. Ts'o @ 2019-08-08 13:31 UTC (permalink / raw)
  To: Warner Losh; +Cc: The Unix Heritage Society, Grant Taylor

On Wed, Aug 07, 2019 at 10:40:06AM -0600, Warner Losh wrote:
> The move into RAM disks happened as memories grew. This obviated the need
> to copy a filesystem to a new disk's swap space and then use that to really
> install the system.
> 
> Kernels with bundled RAM disks were a thing in BSD for a long time, though
> I'm unsure when that functionality entered the code stream. I know the
> early versions of FreeBSD's installer ran out of a RAM disk loaded off
> floppies, though that's not the same as initrd since there never was a
> pivot to something else: just a reboot to boot the real thing.

I implemented loading the root file system as a ramdisk from a floppy
in 1991 for Linux.  This predates the publication of 386BSD, and I
wasn't aware of how commercial Unix systems did their initial
installation and setup.  So as far as I know I came up on it on my
own, but none of this was especially earthshaking or subtle.

Linux's ramdisk was implemented because most PC's of the day (I was
using a 40 MHz 386 with only a megabyte of memory) only had a single
floppy drive (and if they had a second it was a 5.25" drive).  So the
very first implementation which I did assumed the kernel would be no
larger than 512k, and looked for Minix file system signature at 512k.
If it existed, it would load it into the ramdisk and use that as the
boot region.

Before that, the kernel was loaded from the first floppy, and then
kernel would prompt the user to eject the boot disk and insert the
root disk, and hit any key to continue, and then it would mount the
root disk.  But then the only floppy drive would be tied up with the
root file system, so that meant there needed to be a second kernel on
the root floppy, and everything else needed to set up the root image
would have to be copied to the hard disk, and then you'd have to
reboot to release the floppy drive so you could install other programs
that couldn't fit on that initial 1.44MB root floppy.

For people who are interested in the history of initrd used as part of
the boot process in Linux, please refer to Werner Almesberger's 2000
paper, "Booting Linux: The History and the Future"[1], presented at the
Ottawa Linux Symposium.

[1] http://www.almesberger.net/cv/papers/ols2k-9.ps.gz

Cheers,

					- Ted

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] Pre-init initialization
  2019-08-07 16:40   ` Warner Losh
  2019-08-08 13:31     ` Theodore Y. Ts'o
@ 2019-08-08 13:43     ` Clem Cole
  2019-08-08 18:59       ` Warner Losh
  1 sibling, 1 reply; 17+ messages in thread
From: Clem Cole @ 2019-08-08 13:43 UTC (permalink / raw)
  To: Warner Losh; +Cc: The Unix Heritage Society, Grant Taylor

[-- Attachment #1: Type: text/plain, Size: 606 bytes --]

On Wed, Aug 7, 2019 at 12:40 PM Warner Losh <imp@bsdimp.com> wrote:

> This obviated the need to copy a filesystem to a new disk's swap space and
> then use that to really install the system.
>

Thanks for the reminder.   I don't remember if V7 on the PDP-11 used the
swap space (but I don't think so). That said, I fairly sure that by BSD 4.1
the boot loader did, which I think is when that trick was first added to
boot phase.

Again, it was all about trying to get rid of the special /stand version of
things.   Funny, history would move on and we come back to that idea with
busybox 🤔

[-- Attachment #2: Type: text/html, Size: 1270 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] Pre-init initialization
  2019-08-08 13:43     ` Clem Cole
@ 2019-08-08 18:59       ` Warner Losh
  0 siblings, 0 replies; 17+ messages in thread
From: Warner Losh @ 2019-08-08 18:59 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Unix Heritage Society, Grant Taylor

[-- Attachment #1: Type: text/plain, Size: 1316 bytes --]

On Thu, Aug 8, 2019 at 7:43 AM Clem Cole <clemc@ccc.com> wrote:

>
>
> On Wed, Aug 7, 2019 at 12:40 PM Warner Losh <imp@bsdimp.com> wrote:
>
>> This obviated the need to copy a filesystem to a new disk's swap space
>> and then use that to really install the system.
>>
>
> Thanks for the reminder.   I don't remember if V7 on the PDP-11 used the
> swap space (but I don't think so). That said, I fairly sure that by BSD 4.1
> the boot loader did, which I think is when that trick was first added to
> boot phase.
>

Just checked the archives. V7 had a stand alone program to restore a
filesystem image form the tape to the disk that you ran after running the
stand alone program to partition and newfs the disk... I think you are
right on your timeline. I installed a dozen Sun3 boxes from tape and hated
mistyping the file number and having to start over...


> Again, it was all about trying to get rid of the special /stand version of
> things.   Funny, history would move on and we come back to that idea with
> busybox 🤔
>

Well, busybox is special in many ways, so there's that in common with
/stand, but it runs under a full otherwise standard kernel, not as some
special mini-exec that provides just enough of the unix APIs to keep the
standalone programs happy.

Warner

[-- Attachment #2: Type: text/html, Size: 2369 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] Pre-init initialization
  2019-08-07 13:04 ` Clem Cole
  2019-08-07 16:40   ` Warner Losh
@ 2019-08-09  1:46   ` Grant Taylor via TUHS
  2019-08-09  2:15     ` Warner Losh
  1 sibling, 1 reply; 17+ messages in thread
From: Grant Taylor via TUHS @ 2019-08-09  1:46 UTC (permalink / raw)
  To: tuhs

[-- Attachment #1: Type: text/plain, Size: 1521 bytes --]

On 8/7/19 7:04 AM, Clem Cole wrote:
> FWIW: V7 had /stand which was a funky UNIX-like standalone system that 
> some applications could be compiled.

I've seen /stand on a few systems (I think SCO OpenServer and / or 
UnixWare) but never really knew what it was for.  I think I had naively 
assumed it was associated with the kernel and / or booting.

Now I'm somewhat more curious what it was.  Was it a simplified version 
of the OS with minimal utilities with fewer dependencies so that the 
system could boot and load more features.

I thought that Linux's initramfs / initrd had the usual suspect files / 
utilities copied from /.  So the idea that a utility in /stand would be 
different from the same utility in / seems strange to me.

> The problem was that it was a little different so you would end up 
> seeing #ifdef STAND in code for things like fsck, fsdb, even cat. 
> At Masscomp we ended up with three target environments for a couple of 
> the system maintenance utilities: the OS, /stand and the boot ROMS. 
> This was expensive/a PITA to maintain and keep straight, and in the 
> case of the boot ROM, space was a huge problem.

Ya.  I can see how that would be a PITA to maintain.

> The RAMFS idea was created to get rid of at least /stand and IIRC we 
> were able to drop a number of utilities out of the boot ROM.  I'm not 
> sure how far they took it.   I left for Stellar and it was always the 
> way Stellix booted.

ACK



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4008 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] Pre-init initialization
  2019-08-08 13:31     ` Theodore Y. Ts'o
@ 2019-08-09  1:52       ` Grant Taylor via TUHS
  2019-08-10  0:23         ` Theodore Y. Ts'o
  0 siblings, 1 reply; 17+ messages in thread
From: Grant Taylor via TUHS @ 2019-08-09  1:52 UTC (permalink / raw)
  To: tuhs

[-- Attachment #1: Type: text/plain, Size: 2515 bytes --]

On 8/8/19 7:31 AM, Theodore Y. Ts'o wrote:
> I implemented loading the root file system as a ramdisk from a 
> floppy in 1991 for Linux.

Impressive.

> This predates the publication of 386BSD, and I wasn't aware of how 
> commercial Unix systems did their initial installation and setup. 
> So as far as I know I came up on it on my own, but none of this was 
> especially earthshaking or subtle.

That logic makes sense to me.

> Linux's ramdisk was implemented because most PC's of the day (I was 
> using a 40 MHz 386 with only a megabyte of memory) only had a single 
> floppy drive (and if they had a second it was a 5.25" drive).  So the 
> very first implementation which I did assumed the kernel would be no 
> larger than 512k, and looked for Minix file system signature at 512k. 
> If it existed, it would load it into the ramdisk and use that as the 
> boot region.

That's before my time.  If I remember correctly, by the time I was 
creating boot+root disks it was the kernel plus something—I don't 
remember if it was an initramfs or an initrd—concatenated together.  I 
also remember having to use a utility to update the kernel to tell it 
where the something started.  Which was really based on how big the 
kernel was as padding before the something started.  That was probably 
2.<something> on Slackware in '99.

> Before that, the kernel was loaded from the first floppy, and then 
> kernel would prompt the user to eject the boot disk and insert the 
> root disk, and hit any key to continue, and then it would mount the 
> root disk.

I remember doing that.  But perhaps it was for a different reason.

> But then the only floppy drive would be tied up with the root file 
> system, so that meant there needed to be a second kernel on the root 
> floppy, and everything else needed to set up the root image would 
> have to be copied to the hard disk, and then you'd have to reboot 
> to release the floppy drive so you could install other programs that 
> couldn't fit on that initial 1.44MB root floppy.
> 
> For people who are interested in the history of initrd used as part 
> of the boot process in Linux, please refer to Werner Almesberger's 
> 2000 paper, "Booting Linux: The History and the Future"[1], presented 
> at the Ottawa Linux Symposium.
> 
> [1] http://www.almesberger.net/cv/papers/ols2k-9.ps.gz

I will definitely check that out.  Thank you for the link.

> Cheers,

:-)



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4008 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] Pre-init initialization
  2019-08-09  1:46   ` Grant Taylor via TUHS
@ 2019-08-09  2:15     ` Warner Losh
  2019-08-09  6:43       ` Kevin Bowling
  0 siblings, 1 reply; 17+ messages in thread
From: Warner Losh @ 2019-08-09  2:15 UTC (permalink / raw)
  To: Grant Taylor; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 2394 bytes --]

On Thu, Aug 8, 2019, 7:47 PM Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
wrote:

> On 8/7/19 7:04 AM, Clem Cole wrote:
> > FWIW: V7 had /stand which was a funky UNIX-like standalone system that
> > some applications could be compiled.
>
> I've seen /stand on a few systems (I think SCO OpenServer and / or
> UnixWare) but never really knew what it was for.  I think I had naively
> assumed it was associated with the kernel and / or booting.
>
> Now I'm somewhat more curious what it was.  Was it a simplified version
> of the OS with minimal utilities with fewer dependencies so that the
> system could boot and load more features.
>

Yes. There was a library that implemented much of the unix API in a
simplified way that ran on bare metal.

I thought that Linux's initramfs / initrd had the usual suspect files /
> utilities copied from /.  So the idea that a utility in /stand would be
> different from the same utility in / seems strange to me.
>

They are because there was no kernel for them to run under. They were
similar, but if you go look at the sources, they are different.

> The problem was that it was a little different so you would end up
> > seeing #ifdef STAND in code for things like fsck, fsdb, even cat.
> > At Masscomp we ended up with three target environments for a couple of
> > the system maintenance utilities: the OS, /stand and the boot ROMS.
> > This was expensive/a PITA to maintain and keep straight, and in the
> > case of the boot ROM, space was a huge problem.
>
> Ya.  I can see how that would be a PITA to maintain.
>

FreeBSD, NetBSD and OpenBSD all implement some version of this. FreeBSD has
it in src/stand in honor of V7 stand. I did that when I integrate / rewrote
the GSoC project to bring Lua scripting to the boot loader. The other BSDs
have it split between sys/boot and lib/libs. FreeBSD uses it to implement
the rich boot loader which knows how to load off a lot of different file
systems and BIOS interfaces. Net/OpenBSD use it more modestly in their boot
loaders, but have a few standalone programs for things like bootstrapping
VAXen.

Warner

> The RAMFS idea was created to get rid of at least /stand and IIRC we
> > were able to drop a number of utilities out of the boot ROM.  I'm not
> > sure how far they took it.   I left for Stellar and it was always the
> > way Stellix booted.
>
> ACK
>
>
>
> --
> Grant. . . .
> unix || die
>
>

[-- Attachment #2: Type: text/html, Size: 3623 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] Pre-init initialization
  2019-08-09  2:15     ` Warner Losh
@ 2019-08-09  6:43       ` Kevin Bowling
  0 siblings, 0 replies; 17+ messages in thread
From: Kevin Bowling @ 2019-08-09  6:43 UTC (permalink / raw)
  To: Warner Losh; +Cc: TUHS main list, Grant Taylor

[-- Attachment #1: Type: text/plain, Size: 2582 bytes --]

On Thu, Aug 8, 2019 at 7:16 PM Warner Losh <imp@bsdimp.com> wrote:

>
>
> On Thu, Aug 8, 2019, 7:47 PM Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
> wrote:
>
>> On 8/7/19 7:04 AM, Clem Cole wrote:
>> > FWIW: V7 had /stand which was a funky UNIX-like standalone system that
>> > some applications could be compiled.
>>
>> I've seen /stand on a few systems (I think SCO OpenServer and / or
>> UnixWare) but never really knew what it was for.  I think I had naively
>> assumed it was associated with the kernel and / or booting.
>>
>> Now I'm somewhat more curious what it was.  Was it a simplified version
>> of the OS with minimal utilities with fewer dependencies so that the
>> system could boot and load more features.
>>
>
> Yes. There was a library that implemented much of the unix API in a
> simplified way that ran on bare metal.
>
> I thought that Linux's initramfs / initrd had the usual suspect files /
>> utilities copied from /.  So the idea that a utility in /stand would be
>> different from the same utility in / seems strange to me.
>>
>
> They are because there was no kernel for them to run under. They were
> similar, but if you go look at the sources, they are different.
>
> > The problem was that it was a little different so you would end up
>> > seeing #ifdef STAND in code for things like fsck, fsdb, even cat.
>> > At Masscomp we ended up with three target environments for a couple of
>> > the system maintenance utilities: the OS, /stand and the boot ROMS.
>> > This was expensive/a PITA to maintain and keep straight, and in the
>> > case of the boot ROM, space was a huge problem.
>>
>> Ya.  I can see how that would be a PITA to maintain.
>>
>
> FreeBSD, NetBSD and OpenBSD all implement some version of this. FreeBSD
> has it in src/stand in honor of V7 stand. I did that when I integrate /
> rewrote the GSoC project to bring Lua scripting to the boot loader. The
> other BSDs have it split between sys/boot and lib/libs. FreeBSD uses it to
> implement the rich boot loader which knows how to load off a lot of
> different file systems and BIOS interfaces. Net/OpenBSD use it more
> modestly in their boot loaders, but have a few standalone programs for
> things like bootstrapping VAXen.
>

Yeah NetBSD has little gadgets in the ports stand directory for booting odd
hardware.  It would be preferable to have something like FreeBSD’s loader
everywhere, but that would be hard to cover to the swath of ports NetBSD
has, and would still require chain loading gadgets for many platforms.

>

[-- Attachment #2: Type: text/html, Size: 3833 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] Pre-init initialization
  2019-08-09  1:52       ` Grant Taylor via TUHS
@ 2019-08-10  0:23         ` Theodore Y. Ts'o
  2019-08-10  2:28           ` Grant Taylor via TUHS
  0 siblings, 1 reply; 17+ messages in thread
From: Theodore Y. Ts'o @ 2019-08-10  0:23 UTC (permalink / raw)
  To: Grant Taylor; +Cc: tuhs

On Thu, Aug 08, 2019 at 07:52:04PM -0600, Grant Taylor via TUHS wrote:
> That's before my time.  If I remember correctly, by the time I was creating
> boot+root disks it was the kernel plus something—I don't remember if it was
> an initramfs or an initrd—concatenated together.  I also remember having to
> use a utility to update the kernel to tell it where the something started.
> Which was really based on how big the kernel was as padding before the
> something started.  That was probably 2.<something> on Slackware in '99.

In 1993 Fred van Kempen (who did the original Linux TCP stack before I
got rewritten by Alan Cox's Net-2 stack) added a patch to the ramdisk
code which so the root file system would be loaded from a second
floppy into the ramdisk.  That was because he wanted to fit more into
stuff into the root file system, and by using a second floppy, the
full 1.44MB could be used for the root file system in the ramdisk.  As
I recall the kernel was also getting bigger than 512k, too.

In '95, Slackware started releasing on CD-ROM's, and while there may
have been boot/root floppies, I suspect more and more they were used
as rescue media, since installing from a CD-ROM was *way* more
convenient.

I'm guesing what you were doing was creating a kernel plus initramfs
which was sufficient to mount a root file system elsewhere as an
emergency "boot this failsafe kernel off the floppy", perhaps?  I
don't think a kernel+initramfs on a single 1.44MB floppy would have
been sufficient for use as an install medium by '99.  Or were you
making an emergency USB thumb-drive as a rescue device, maybe?

Cheers,

				- Ted

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] Pre-init initialization
  2019-08-06 23:46 [TUHS] Pre-init initialization Grant Taylor via TUHS
  2019-08-07  1:22 ` Andrew Warkentin
  2019-08-07 13:04 ` Clem Cole
@ 2019-08-10  1:45 ` Chris Hanson
  2 siblings, 0 replies; 17+ messages in thread
From: Chris Hanson @ 2019-08-10  1:45 UTC (permalink / raw)
  To: Grant Taylor, Grant Taylor via TUHS

On Aug 6, 2019, at 4:46 PM, Grant Taylor via TUHS <tuhs@minnie.tuhs.org> wrote:
> 
> Do, or did, anything other than Linux use a concept of an initramfs / initrd to create a pre-(main)-init initialization environment to prepare the system to execute the (main)-init process?

Mach-based UNIX systems (can) have a Mach init that’s separate from UNIX pid 1 init.

When using a non-colocated UNIX subsystem (like the BSD Single Server) I think I recall that’s how the UNIX subsystem is started, along with other Mach tasks like the port name server.

  -- Chris



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] Pre-init initialization
  2019-08-10  0:23         ` Theodore Y. Ts'o
@ 2019-08-10  2:28           ` Grant Taylor via TUHS
  2019-08-10  4:21             ` Kevin Bowling
  0 siblings, 1 reply; 17+ messages in thread
From: Grant Taylor via TUHS @ 2019-08-10  2:28 UTC (permalink / raw)
  To: tuhs

[-- Attachment #1: Type: text/plain, Size: 1181 bytes --]

On 8/9/19 6:23 PM, Theodore Y. Ts'o wrote:
> In '95, Slackware started releasing on CD-ROM's, and while there may 
> have been boot/root floppies, I suspect more and more they were used as 
> rescue media, since installing from a CD-ROM was *way* more convenient.

The boot & root floppies were how you booted Slackware for a long time. 
The CD-ROM was unbootable for quite a while.  You booted off of floppy 
and the installation scripts would ask you which drive had the CD-ROM in 
it to mount and install from.

> I'm guesing what you were doing was creating a kernel plus initramfs 
> which was sufficient to mount a root file system elsewhere as an 
> emergency "boot this failsafe kernel off the floppy", perhaps? 
> I don't think a kernel+initramfs on a single 1.44MB floppy would 
> have been sufficient for use as an install medium by '99.  Or were 
> you making an emergency USB thumb-drive as a rescue device, maybe?

It was a re-roll of the above boot & root disk set.  It was not rescue 
media per-say.  Though the standard boot & root disk set did get used 
for rescue purposes in addition to installation.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4008 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] Pre-init initialization
  2019-08-10  2:28           ` Grant Taylor via TUHS
@ 2019-08-10  4:21             ` Kevin Bowling
  2019-08-10  4:50               ` Grant Taylor via TUHS
  2019-08-10  4:52               ` Adam Thornton
  0 siblings, 2 replies; 17+ messages in thread
From: Kevin Bowling @ 2019-08-10  4:21 UTC (permalink / raw)
  To: Grant Taylor; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 1384 bytes --]

Yup I remember doing a boot/root floppies with Slackware as late as the
early 2000s on an IBM PS/2 Model 95.

On Fri, Aug 9, 2019 at 7:29 PM Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
wrote:

> On 8/9/19 6:23 PM, Theodore Y. Ts'o wrote:
> > In '95, Slackware started releasing on CD-ROM's, and while there may
> > have been boot/root floppies, I suspect more and more they were used as
> > rescue media, since installing from a CD-ROM was *way* more convenient.
>
> The boot & root floppies were how you booted Slackware for a long time.
> The CD-ROM was unbootable for quite a while.  You booted off of floppy
> and the installation scripts would ask you which drive had the CD-ROM in
> it to mount and install from.
>
> > I'm guesing what you were doing was creating a kernel plus initramfs
> > which was sufficient to mount a root file system elsewhere as an
> > emergency "boot this failsafe kernel off the floppy", perhaps?
> > I don't think a kernel+initramfs on a single 1.44MB floppy would
> > have been sufficient for use as an install medium by '99.  Or were
> > you making an emergency USB thumb-drive as a rescue device, maybe?
>
> It was a re-roll of the above boot & root disk set.  It was not rescue
> media per-say.  Though the standard boot & root disk set did get used
> for rescue purposes in addition to installation.
>
>
>
> --
> Grant. . . .
> unix || die
>
>

[-- Attachment #2: Type: text/html, Size: 1844 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] Pre-init initialization
  2019-08-10  4:21             ` Kevin Bowling
@ 2019-08-10  4:50               ` Grant Taylor via TUHS
  2019-08-10  4:52               ` Adam Thornton
  1 sibling, 0 replies; 17+ messages in thread
From: Grant Taylor via TUHS @ 2019-08-10  4:50 UTC (permalink / raw)
  To: tuhs

[-- Attachment #1: Type: text/plain, Size: 418 bytes --]

On 8/9/19 10:21 PM, Kevin Bowling wrote:
> Yup I remember doing a boot/root floppies with Slackware as late as the 
> early 2000s on an IBM PS/2 Model 95.

That timing seems correct.

I didn't think the IBM PS/2 Model 95, or any PS/2 for that matter, 
supported booting from CD-ROM.  At least stock firmware.  (I have no 
idea if a 3rd party / hacked firmware exists.)



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4008 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [TUHS] Pre-init initialization
  2019-08-10  4:21             ` Kevin Bowling
  2019-08-10  4:50               ` Grant Taylor via TUHS
@ 2019-08-10  4:52               ` Adam Thornton
  1 sibling, 0 replies; 17+ messages in thread
From: Adam Thornton @ 2019-08-10  4:52 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1722 bytes --]

MCA support came pretty late, so that's not terribly surprising.

As did booting-from CD-ROM, for that matter.  I think I remember a fairly
long period where the CD-ROM hung off the SoundBlaster, not the IDE bus.

Adam

On Fri, Aug 9, 2019 at 9:22 PM Kevin Bowling <kevin.bowling@kev009.com>
wrote:

> Yup I remember doing a boot/root floppies with Slackware as late as the
> early 2000s on an IBM PS/2 Model 95.
>
> On Fri, Aug 9, 2019 at 7:29 PM Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
> wrote:
>
>> On 8/9/19 6:23 PM, Theodore Y. Ts'o wrote:
>> > In '95, Slackware started releasing on CD-ROM's, and while there may
>> > have been boot/root floppies, I suspect more and more they were used as
>> > rescue media, since installing from a CD-ROM was *way* more convenient.
>>
>> The boot & root floppies were how you booted Slackware for a long time.
>> The CD-ROM was unbootable for quite a while.  You booted off of floppy
>> and the installation scripts would ask you which drive had the CD-ROM in
>> it to mount and install from.
>>
>> > I'm guesing what you were doing was creating a kernel plus initramfs
>> > which was sufficient to mount a root file system elsewhere as an
>> > emergency "boot this failsafe kernel off the floppy", perhaps?
>> > I don't think a kernel+initramfs on a single 1.44MB floppy would
>> > have been sufficient for use as an install medium by '99.  Or were
>> > you making an emergency USB thumb-drive as a rescue device, maybe?
>>
>> It was a re-roll of the above boot & root disk set.  It was not rescue
>> media per-say.  Though the standard boot & root disk set did get used
>> for rescue purposes in addition to installation.
>>
>>
>>
>> --
>> Grant. . . .
>> unix || die
>>
>>

[-- Attachment #2: Type: text/html, Size: 2531 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2019-08-10  4:53 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-06 23:46 [TUHS] Pre-init initialization Grant Taylor via TUHS
2019-08-07  1:22 ` Andrew Warkentin
2019-08-07 13:04 ` Clem Cole
2019-08-07 16:40   ` Warner Losh
2019-08-08 13:31     ` Theodore Y. Ts'o
2019-08-09  1:52       ` Grant Taylor via TUHS
2019-08-10  0:23         ` Theodore Y. Ts'o
2019-08-10  2:28           ` Grant Taylor via TUHS
2019-08-10  4:21             ` Kevin Bowling
2019-08-10  4:50               ` Grant Taylor via TUHS
2019-08-10  4:52               ` Adam Thornton
2019-08-08 13:43     ` Clem Cole
2019-08-08 18:59       ` Warner Losh
2019-08-09  1:46   ` Grant Taylor via TUHS
2019-08-09  2:15     ` Warner Losh
2019-08-09  6:43       ` Kevin Bowling
2019-08-10  1:45 ` Chris Hanson

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).