On Mon 14 Feb 2022 at 12:13:20 (-0500), Chuck Zmudzinski wrote: > On 2/14/2022 10:19 AM, Bijan Soleymani wrote: > > On 2022-02-14 10:02, rhkra...@gmail.com wrote: > > > I think I did mis-remember this, and the behavior I described > > > is more like the > > > behavior of the Debian installer (i.e., it boots an image (with a Linux > > > kernel) into RAM to use temporarily for the installation.
What actually boots up in a typical Debian installer (that's netinst in my case) is, from what I can understand from observations, quite varied. Looking at the ISO, there's isolinux and an El Torito section for booting as a DVD, some EFI stuff that heads into Grub, autorun/setup exe files that look like Windows software, and even loadlin for good old DOS to run. And, of course, you can point your extant installation's Grub at the ISO's kernel and initrd in order to boot it where you have no slot/socket/CD/DVD/floppy or connector of any sort to push something into. But the end result is the same: decompressing and loading the vmlinuz kernel together with one of the initrd instances. And that kernel remains in operation until you reboot into your new system. > AFAIK a ramdisk image is not only loaded when using the Debian > installer, it is also loaded when booting a full installation on a > disk. For example, the initrd.img-5.10.0-11-amd64 file that is created > when installing a kernel and installed under /boot on bullseye systems > contains the compressed contents of a filesystem that is loaded into > RAM upon initial boot, and AFAIK that filesystem does not contain a > kernel but it does contain kernel modules that are binary-compatible > with the running kernel to support the proper initialization of > various hardware. The main job of that initrd environment is to find > and mount the installed root filesystem that is usually on an SSD > these days. I wish! :) But yes, the initrd for an installed system does just that. OTOH the initrd for the debian-installer becomes the OS used for building the new system onto the device mounted on its /target directory. When you reboot, it's thrown away. > > > I just wanted to try to correct this for posterity. > > > > > > If anyone can confirm this (both my mistake about grub and my (new) > > > recollection about the Debian installer, those would be good things.:-) > > > > Not sure about the Debian installer (except that it does boot and > > run Linux, but not sure it ever switches to another kernel > > midway), but the Grub bootloader is kind of a mini-OS, in that it > > can read files from filesystems (rather than some other > > bootloaders that read from specific sectors/blocks of a disk). I think that confuses the issue. Grub is just a program, not an OS. It can run commands from a shell, and it can load lots of drivers, but that doesn't even qualify it as a single-user OS. It's technically correct to say that Grub is designed with a "kernel" and modules, but that's mainly a way of saving space in the final product, by having as little excess code included as possible. There's no concept of kernel- and user-space. They could have as easily named the kernel.img "trunk.img", and core.img "body.img", to illustrate how Grub is agglomerated. > > Which is to say if you boot to grub and you are in the grub menu > > and see there is no entry for the particular kernel (or OS) you > > want, you can edit the boot parameters for any menu entry you see > > and boot the missing kernel (or OS) from then and there. (with > > other bootloaders you'd have to boot to the OS or boot from a live > > CD to modify the boot loader parameters). > > Also, grub has its own shell, and sometimes if something is not > configured right, grub may drop into its shell where a knowledgeable > user can type in commands such as the ls command to list files on the > disks attached to the system and the configfile command which can be > used to load the grub configuration if for some reason grub was unable > to find the grub.cfg file that tells grub how to boot the system. This > is a useful feature for those who know how to use it, and it has saved > me from having to reinstall on more that one occasion. Effectively, Grub has two shells, Grub> and Grub rescue>, depending on whether the "normal" module has been loaded, and about the only thing you can sensibly do without normal is to find it and insmod it. But most people will never see rescue, and with patience it's usually fairly straightforward to stumble your way round the system with ls, and find something to boot or chainload. BTW a very useful command to kick off with in Grub is: Grub> set pager=1 without which it can be hard to use: Grub> help Cheers, David.
