7 Aug
2019
7 Aug
'19
1:46 a.m.
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
7 Aug
7 Aug
3:22 a.m.
On 8/6/19, Grant Taylor via TUHS <tuhs(a)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.
3:04 p.m.
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(a)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
6:40 p.m.
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(a)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(a)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
>
>
8 Aug
8 Aug
3:31 p.m.
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
9 Aug
9 Aug
3:52 a.m.
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
10 Aug
10 Aug
2:23 a.m.
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
4:28 a.m.
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
6:21 a.m.
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(a)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
6:50 a.m.
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
6:52 a.m.
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(a)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(a)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
>
>
8 Aug
8 Aug
3:43 p.m.
On Wed, Aug 7, 2019 at 12:40 PM Warner Losh <imp(a)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 🤔
8:59 p.m.
On Thu, Aug 8, 2019 at 7:43 AM Clem Cole <clemc(a)ccc.com> wrote:
On Wed, Aug 7, 2019 at 12:40 PM Warner Losh <imp(a)bsdimp.com> wrote:
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...
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 🤔
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
9 Aug
9 Aug
3:46 a.m.
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
4:15 a.m.
On Thu, Aug 8, 2019, 7:47 PM Grant Taylor via TUHS <tuhs(a)minnie.tuhs.org>
wrote:
On 8/7/19 7:04 AM, Clem Cole wrote:
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 /
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.
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
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
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
8:43 a.m.
On Thu, Aug 8, 2019 at 7:16 PM Warner Losh <imp(a)bsdimp.com> wrote:
On Thu, Aug 8, 2019, 7:47 PM Grant Taylor via TUHS <tuhs(a)minnie.tuhs.org wrote:
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.
On 8/7/19 7:04 AM, Clem Cole wrote:
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 /
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.
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
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.
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.
10 Aug
10 Aug
3:45 a.m.
On Aug 6, 2019, at 4:46 PM, Grant Taylor via TUHS <tuhs(a)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
1927
days inactive
1931
days old
16 comments
8 participants
participants (8)
-
Adam Thornton -
Andrew Warkentin -
Chris Hanson -
Clem Cole -
Grant Taylor -
Kevin Bowling -
Theodore Y. Ts'o -
Warner Losh