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, MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 1638 invoked from network); 4 Sep 2023 19:59:38 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 4 Sep 2023 19:59:38 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 7D13640FE3; Tue, 5 Sep 2023 05:59:32 +1000 (AEST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by minnie.tuhs.org (Postfix) with ESMTPS id 59E4240FDC for ; Tue, 5 Sep 2023 05:59:26 +1000 (AEST) Received: from cwcc.thunk.org (pool-173-48-119-169.bstnma.fios.verizon.net [173.48.119.169]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 384JxIuh028995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 4 Sep 2023 15:59:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1693857561; bh=h2cyXGX8WEBy9eCu49F8RWrhMCse4Mi0pZGmy0Xblzo=; h=Date:From:Subject:Message-ID:MIME-Version:Content-Type; b=PsorC9MSi8Q84ec2LSK68uwON1Zm8jzhm7SMam0B1w74O8TMggoQo8KbA6PIXc3Lf 2YegibYL0FQLGx5gVB5aUoknkMLaR4RRJwhYJ5wvEg7TBafnS2UaodVotPqkqsffgJ GTRScagnYA5Y9bszSzhVb0yrRjl4HegDVtIHdx6slYbfzEH2MM6bipzn6p0GfzS5V0 s0Sk6yyQ+yh2wcOA2FhXE5z5J74Fzoux2s0Ve0Wtb3wq17EjRg5ZPEc+ztgzSSgDm6 aGQDP1E5K3t+1LOyh6N7iyJl+WFuB6euTWGuBnvA9Frw0N2FgAzjObP/0/0tVTWcNy H+hQpPh6TL/1g== Received: by cwcc.thunk.org (Postfix, from userid 15806) id 323E215C023F; Mon, 4 Sep 2023 15:59:18 -0400 (EDT) Date: Mon, 4 Sep 2023 15:59:18 -0400 From: "Theodore Ts'o" To: Warner Losh Message-ID: <20230904195918.GC701295@mit.edu> References: <9A989054DE79CE5059CBA74797391E39.for-standards-violators@oclsc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Message-ID-Hash: BSR5NRHRFPZWNRZTPLVIUEMHY24RA2BL X-Message-ID-Hash: BSR5NRHRFPZWNRZTPLVIUEMHY24RA2BL X-MailFrom: tytso@mit.edu 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: 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.) 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. 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. 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. 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-quickstart.md - Ted the root filesystem on the second floppy disk (the first floppy disk contained the kernel), which was then copied into a ramdisk, so you could Trying to fit the kernel and the root file system on a single 1.44MB floppy, was (barely) doable, but you certainly wouldn't have space for a C compiler so you build or link your own custom kernel. So one of the first things that we did was to put the kernel on a single floppy disk, and then but the root on a single floppy disk, and then copy the root to the HDD, and then reboot onto the HDD, and then take the installation procedure from there. But that was awkward and