The evolution of OS installs
... no big insights, just a few fun observations.
Once upon a time, installing an operating system on a computer (... who am I kidding, it was the computer, for most people who weren't doing this as part of their actual jobs) started with booting from a floppy. You could get a reasonable fraction of DOS 6.22 running from a floppy; it technically had an installer, too, but apart from copying a bunch of files, it didn't really do magic things.
Then Windows 95 became a thing. You already had DOS (of course you did), so "booting" the installer consisted of just launching an EXE file from DOS itself. Then, various magic things happened, Windows got installed, and then you could run it after booting DOS, essentially, by launching win.com. (All this resulted in a major confusion for many people whether Win95 was in fact a DOS program or not.)
This is the point where I started looking into Linux... initially booted using Loadlin, a DOS program which loaded a Linux kernel into memory and launched it from there. Imagine a DOS boot menu with Linux in it! (Linux installs using LILO were only for advanced Linux users.)
Eventually though... we came to a point where the main way of launching OS installers was booting from a CD (well, if your machine was cool enough for this). No more looking for boot floppies; just pop in the latest Windows 2000 / Debian Woody / SuSE 6.3 CD and off we go. No more weird "going though DOS first" maneuvers. Apart from "CDs" eventually becoming DVDs and then USB drives, this did not change a lot. Want an install an OS? Grab its image, write it out to something, boot from it, next next finish (possibly including partitioning), install bootloader, that's it.
Totally not worth writing an article about, even if you're only aiming for just more article for the 100 for the year.
Well, the above method works well for... most people, but it's kinda inconvenient. You need to boot from something. That something needs to be written separately. If it's an optical disk, there is a good chance this is the last time you're using it. If it's a USB drive... do you actually have one at hand?
On the plus side though: you can boot from a network! Just look up TFTP and iPXE is real neat and you'd want to hack your DHCP server into allowing this, but when it works, it's great. Of course, once you boot, you do need an actual file system to mount... enter iSCSI and friends; it's... somewhat nontrivial.
Linux by hand
A great alternative, if you're a fairly experienced Linux user already, is to just grab your hard drive, mount it on another Linux machine, partition it using (c)fdisk, then use some distro-specific tools (like debootstrap to generate a minimal system image onto it. Then, you put the disk back, somehow boot into it (modern EFI bootloaders like rEFInd can boot Linux kernels without GRUB involvement, even; this is a lot easier than it sounds if you're installing a distro this way from another distro on the same machine), there we go, you're done. Without ever clicking through an installer.
(This is, by the way, the actual, official way of installing Gentoo. Definitely scary first; a lot easier after.)
However... the actual reason why I wrote this post was somewhat different though. Namely... there might be an even easier way!
The VM swap trick
Most OS installs proceed in several steps. Namely:
- boot something super basic. Load enough drivers to see the installation media. Partition, copy a bunch of files, install bootloader, reboot...
- ... to the actual OS you're installing; since now you're running the right kernel and from the actual file system, you can now do some more hardware detection, initial configuration, convincing the user that they have the best OS ever, etc.
- after another reboot, we have the system up and running.
Note that the first stage really doesn't care a lot about your hardware. It might take a quick look at how many CPU cores you have (one or many), but... that's it. It'll just copy files.
Now, what we do is... we grab the hard drive from the target machine, plug it into ours (cheap SATA-USB adapters start at $10-ish now). Once it shows up in /dev/ (... say, as /dev/sdb), we launch qemu on it!
WARNING: do not mix it up with your actual hard drive; you're really not going to have a good day. Also, everything is your responsibility, this is not financial advice, etc. Just a description of what I did. It's not that dangerous though, as long as you do have an idea of what you're doing.
chown youruser:youruser /dev/sdb # so that you have all the permissions qemu-system-i386 \ # for 64-bit, it's qemu-x86_64 -enable-kvm \ # makes it a lot faster but might or might not work -m 256M \ # ... or whatever amount you think is reasonable -drive media=cdrom,file=ReactOS-0.4.13-release-14.iso \ # ... or your ISO file here -vga cirrus \ # just play around with different options if things don't work right away -drive file=/dev/sdb,format=raw # this is the important part! -boot d # to boot from the iso, not the disk.
(This, by the way, one of the possible conclusions from today's post: invoking qemu from the command line is a lot simpler and quicker than messing around with VirtualBox GUIs.)
If everything goes well, the installer launches. (Linux, Windows, ReactOS... well, technically, I only tried it with ReactOS, but I'd expect this to work for many other things.)
You partition, install the bootloader, etc., just as if you were a normal person, running this on the actual machine you'd like to install things on. And when it wants to reboot... you just kill qemu, then, for good measure,
sync # flush caches hdparm -y /dev/sdb # power down the drive so that you can remove it more nicely
... disconnect from USB, and, with any luck, it will boot nicely in your target machine. Worked for ReactOS!
This is post no. 5 for Kev Quirk's #100DaysToOffload challenge.
... comments welcome, either in email or on the (eventual) Mastodon post on Fosstodon.