From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 11024 invoked from network); 4 Sep 2023 23:51:57 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 4 Sep 2023 23:51:57 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 764CF4101C; Tue, 5 Sep 2023 09:51:52 +1000 (AEST) Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) by minnie.tuhs.org (Postfix) with ESMTPS id B20B341019 for ; Tue, 5 Sep 2023 09:51:46 +1000 (AEST) Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-99bcc0adab4so281767066b.2 for ; Mon, 04 Sep 2023 16:51:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1693871505; x=1694476305; darn=tuhs.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=oeF9cNWUr7S3ID2TcvUp1jApGW8j+IG4kL5k2za1ZE4=; b=hqK1+7J3VY3YoRpuFbd916LIJq8tvi2qUYcBLsf2U94cCnNfbwlO393aPEUtEaV8bD nsZ4tEFTaFVTg1PqMe1Ws8kd08TTRHweDQmDDT0rfr5Jj3csgourR6yLVCNrayOE5o3g uF0hisUq/fMgeBFfhkhgELv+vrXToMFDSDAdo7GreMvEnTTG0TMTe4xSXYXQNflRauvn desDBHYuYcWXlThmzUFc/QHm9WbS6VNW9EMzGCnK/m3iES+nmD9HlmF/cTYoxfjsnylD kL0brdxpVkNKiBEtmWr6i5xKvmcedPQdJUzfyStdk5tbexhonXf96Ws80diRv0frbdNV 69/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693871505; x=1694476305; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=oeF9cNWUr7S3ID2TcvUp1jApGW8j+IG4kL5k2za1ZE4=; b=Xvn6VrFO2t/tB6eYopyqMieWQKY3GkZBAgUoH4IzPbYva8GhsEMrRj39drVcLAi6SX obDKpU7nGJndfv8eCpG+pyyWAgaoOjV/MQZVTnnABiFMYcwKGvm+kLJNLgqrHloXVvZ4 fkC63ijvEvB4sdfFsFrQ0OgtAK/9FhFl5b9Sps5GxqaEPTNMGOaQpaYPtNzygDwvrtOi KJNdzkV+wNYoIrlTJNAnKWdPljXKbcTi3E7vGLspTDDCikgdl3qn/asJX1032uFnk9Wo /Icbhw6Ere6iSrETqwTIRBLStaIOdvg1pTMzhYtenkCLaRV33YAVQ58hREp8Mkkkh5cy jCMg== X-Gm-Message-State: AOJu0YxVYgirFvXQFdAWNfTYmEcxJN1EK5Q7B8TbUBj6fAb/BzHPsMiP QLRQLxj16EpY0u9edzRnuPDj0v4GYaO5ozcvu6f5Spip6SAjntEU X-Google-Smtp-Source: AGHT+IHQdV/ZyDCccqvwWJGLsjfg8rv4QM6Pt15LD05cL7pg4scIGcePzH0m/1PlYRE8E+92KmzZqTiXfZamB6TpMEA= X-Received: by 2002:a17:906:8b:b0:9a5:852f:10ae with SMTP id 11-20020a170906008b00b009a5852f10aemr9010673ejc.60.1693871504537; Mon, 04 Sep 2023 16:51:44 -0700 (PDT) MIME-Version: 1.0 References: <9A989054DE79CE5059CBA74797391E39.for-standards-violators@oclsc.org> <20230904195918.GC701295@mit.edu> In-Reply-To: <20230904195918.GC701295@mit.edu> From: Warner Losh Date: Mon, 4 Sep 2023 17:51:33 -0600 Message-ID: To: "Theodore Ts'o" Content-Type: multipart/alternative; boundary="00000000000052cc910604913181" Message-ID-Hash: XBGDMDHNC2AFBJZEJPWHLSIFFMZVK4X4 X-Message-ID-Hash: XBGDMDHNC2AFBJZEJPWHLSIFFMZVK4X4 X-MailFrom: wlosh@bsdimp.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: tuhs@tuhs.org X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Unix install & "standalone" package List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000052cc910604913181 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Sep 4, 2023 at 1:59=E2=80=AFPM Theodore Ts'o wrote: > On Mon, Sep 04, 2023 at 11:20:31AM -0600, Warner Losh wrote: > > > > Yea, it was an effort to move mounting of root out of the > > kernel. The earliest scripts just mounted the right disk and moved > > on, and didn't load any new drivers: they just had the logic to pick > > the desired root. But at the same time, there were a lot of people > > that were running on 4MB and 8MB systems that noticed they could put > > all the router software in the initramfs and never pivot to > > something else and they could have quite the product with that. And > > those were the first few bricks that paved the road to hell :) > > The other reason why you might need something like an initial ramdisk > is if you don't yet *have* a root file system on the hardware, and you > are trying to install a system using TFTP boot. At that point, you > have three choices: > > (a) Use a NFS root > > (b) Use a read-only network block device (for example, MIT Project > Athena had a read-only Remote Virtual Disk which was a network block > device that was used to provide a read-only system image used for > installation and update, as well as a read-only /usr image). > > (c) Use a built-in ramdisk. (And here's not just Linus which has > adopted this strategy; OpenBSD's installer does this as well.) > Yes. FreeBSD did this originally, and some installers still do that. > The other dynamic at play was that ramdisks were needed when you were > installing on a 386 PC with, say, 16 megs of memory, a 320 megabyte > hard disk, and a *single* 1.44MB floppy --- and no ethernet, because > this was for the home PC user, so the best that you had might be a > 38kbps dialup link with PPP --- if you were lucky. > > So putting the kernel on the first floppy disk, and putting a ramdisk > image on the second floppy disk, so you could then eject the floppy > disk and insert subsequent floppy disks so you could install rest of > the installation binaries (including the shell utilities, the C > compiler, X windows systems, etc.) and then reboot onto the HDD with a > fully set up system, was a pretty natural evolution. > Yes. FreeBSD 2.0 definitely did that, and I think FreeBSD 1.0 as well. > And since we had the ramdisk infrastructure, and most users didn't > want to configure their own kernel as part of the installation > process, that begat kernel modules and the initial ramdisk being used > to store the kernel modules. In the very early days, this made Linux > *far* more user friendly for non-system programmers to install, > compared to say, FreeBSD during that era, which was still stuck in the > BSD 4.x days of a generic kernel, followed by a kernel configuration > step, etc. > GENERIC worked fine in the early days: it was small enough that the savings from removing all the extra devices was small... but that's because the number of devices supported was also relatively small. By the time it became an issue FreeBSD did have dynamic loading of drivers, but retained the GENERIC kernel for install (it should have gone to a minimal kernel, but hasn't yet completed the migration: the savings wasn't big enough due to Moore's Law growing machine memories faster than the kernel grew: FreeBSD's kernel only doubled every 2 years...). But yea, it was a bit of a kludge. And FreeBSD grew the ability to configur= e the morass of ISA devices in the boot loader early on so you could at least boot the generic kernel, and have the loader remember your choices. > These days, given that some enterprise setups what their servers to be > installed from a Fibre Channel Storage Area Network, or iSCSI, perhaps > using Kerberos to authenticate to the iSCSI target, it makes > absolutely a huge amount of sense to have an initial ramdisk as an > option. That being said, for a long time, the initial ramdisk was an > *option*. You didn't have to use it, if you were willing to have a > custom kernel and you are using a device which has a fixed and stable > boot-time enumeration. > Yea. FreeBSD can use it to this day (and many interesting use cases use it), but generally the loader tells the kernel what root filesystem to use. These smarts in the boot loader have also kept the pressure of the vast majority of cases where initramfs makes sense in Linux land. > This tended to only be used by people who knew what they were doing, > but for example, my file system test appliance VM system doesn't use > an initial ramdisk at all. It uses qemu, and has a built-in kernel > configuration and build system, and this works perfectly fine booting > into the latest Debian stable distribution, with no initial ramdisk > used at all: > > > https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-quick= start.md > Ah, cool. Every single distro I've run in the past has had an initramfs. I thought it had become no longer an option... I do similar things for my VM setup with FreeBSD :) Warner --00000000000052cc910604913181 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Sep 4, 2023 at 1:59=E2=80=AFP= M Theodore Ts'o <tytso@mit.edu&= gt; wrote:
On Mo= n, Sep 04, 2023 at 11:20:31AM -0600, Warner Losh wrote:
>
> Yea, it was an effort to move mounting of root out of the
> kernel. The earliest scripts just mounted the right disk and moved
> on, and didn't load any new drivers: they just had the logic to pi= ck
> the desired root. But at the same time, there were a lot of people
> that were running on 4MB and 8MB systems that noticed they could put > all the router software in the initramfs and never pivot to
> something else and they could have quite the product with that. And > those were the first few bricks that paved the road to hell :)

The other reason why you might need something like an initial ramdisk
is if you don't yet *have* a root file system on the hardware, and you<= br> are trying to install a system using TFTP boot.=C2=A0 At that point, you have three choices:

(a) Use a NFS root

(b) Use a read-only network block device (for example, MIT Project
Athena had a read-only Remote Virtual Disk which was a network block
device that was used to provide a read-only system image used for
installation and update, as well as a read-only /usr image).

(c) Use a built-in ramdisk.=C2=A0 (And here's not just Linus which has<= br> adopted this strategy; OpenBSD's installer does this as well.)

Yes. FreeBSD did this originally, and some inst= allers still do that.
=C2=A0
The other dynamic at play was that ramdisks were needed when you were
installing on a 386 PC with, say, 16 megs of memory, a 320 megabyte
hard disk, and a *single* 1.44MB floppy --- and no ethernet, because
this was for the home PC user, so the best that you had might be a
38kbps dialup link with PPP --- if you were lucky.

So putting the kernel on the first floppy disk, and putting a ramdisk
image on the second floppy disk, so you could then eject the floppy
disk and insert subsequent floppy disks so you could install rest of
the installation binaries (including the shell utilities, the C
compiler, X windows systems, etc.) and then reboot onto the HDD with a
fully set up system, was a pretty natural evolution.
<= br>
Yes. FreeBSD 2.0 definitely did that, and I think FreeBSD 1.0= as well.
=C2=A0
And since we had the ramdisk infrastructure, and most users didn't
want to configure their own kernel as part of the installation
process, that begat kernel modules and the initial ramdisk being used
to store the kernel modules.=C2=A0 In the very early days, this made Linux<= br> *far* more user friendly for non-system programmers to install,
compared to say, FreeBSD during that era, which was still stuck in the
BSD 4.x days of a generic kernel, followed by a kernel configuration
step, etc.

GENERIC worked fine in the e= arly days: it was small enough that the savings
from removing all= the extra devices was small... but that's because the number
of devices supported was also relatively small. By the time it became an i= ssue
FreeBSD did have dynamic loading of drivers, but retained th= e GENERIC
kernel for install (it should have gone to a minimal ke= rnel, but hasn't yet
completed the migration: the savings was= n't big enough due to Moore's
Law growing machine memorie= s faster than the kernel grew: FreeBSD's kernel
only doubled = every 2 years...).

But yea, it was a bit of a klud= ge. And FreeBSD grew the ability to configure
the morass of ISA d= evices in the boot loader early on so you could at least
boot the= generic kernel, and have the loader remember your choices.
= =C2=A0
These days, given that some enterprise setups what their servers to be
installed from a Fibre Channel Storage Area Network, or iSCSI, perhaps
using Kerberos to authenticate to the iSCSI target, it makes
absolutely a huge amount of sense to have an initial ramdisk as an
option.=C2=A0 That being said, for a long time, the initial ramdisk was an<= br> *option*.=C2=A0 You didn't have to use it, if you were willing to have = a
custom kernel and you are using a device which has a fixed and stable
boot-time enumeration.

Yea. FreeBSD can= use it to this day (and many interesting use cases
use it), but = generally the loader tells the kernel what root filesystem to
use= . These smarts in the boot loader have also kept the pressure of the
<= div>vast majority of cases where initramfs makes sense in Linux land.
=C2=A0
This tended to only be used by people who knew what they were doing,
but for example, my file system test appliance VM system doesn't use an initial ramdisk at all.=C2=A0 It uses qemu, and has a built-in kernel configuration and build system, and this works perfectly fine booting
into the latest Debian stable distribution, with no initial ramdisk
used at all:

https://github.com/= tytso/xfstests-bld/blob/master/Documentation/kvm-quickstart.md

Ah, cool. Every single distro I've run in the past has had an initra= mfs. I thought
it had become no longer an o= ption...

I do similar things for my VM setup with FreeBSD :)

Warner
--00000000000052cc910604913181--