I used to work on that stuff (mostly focused on WIM file format). There's probably a file somewhere called setupact.log that gives you tons of detail on what goes wrong. They don't surface a lot of detailed errors to UI, but the logging is usually precise about what fails and why.
The problem I have with that is that you need to know which log file to look into when an obscure error shows up. If you already know it, you can solve an issue easily, but if you don't, and the error doesn't tell you the details or where to find them, you'll find yourself banging your head against the wall for days.
Instead of the (fairly useless) "Make sure the installation sources are valid and restart the installation", the error could have said "More information can be found in X:\...\setupact.log" which would have been more useful to a person technical enough to read it, and equally useless for the few non-technical users who will ever encounter this error.
This applies to many errors that just tell you what failed with generic steps that might help instead of actual useful information.
Correct, I won't defend all of that, some of these messages were irritatingly vague, and it doesn't tell you how to find the log.
Though in fairness, I believe though the most common cause for an error in that path would be a problem with the installation media, and probably more likely to be checksum errors on an optical drive, or perhaps corruption on the machine capturing the WIM file, or even a bad drive on the target machine -- all of these are much more likely that than someone stuffing a Linux image onto installation media.. So I could see a message geared towards that.
When I was responsible for the WIM code, I got pinged with a lot of noise from people all over Microsoft installing Windows onto bad disks. They usually thought they hit setup bugs.
Yep, the setupact.log is how I eventually figured out that it's looking for the WindowsPE SKU, not Core (despite me picking Core in GImageX when offered). They mention the setupact.log somewhere on one of the dozens of pages of Windows deployment, I pretty much found out about its existence by clicking around randomly and reading articles that looked relevant.
Back in my day we had UMSDOS and loved^Whated it! It let you have Linux file semantics (owners, permissions, etc) on top of the MS-DOS FAT filesystem, and so you could install Linux without its own partition right beside DOS. Then you'd use loadlin which would load the kernel into memory and run it, basically shoving DOS out of memory.
> and so you could install Linux without its own partition right beside DOS. Then you'd use loadlin which would load the kernel into memory and run it, basically shoving DOS out of memory.
It was more than just "install Linux without its own partition". It was "install Linux in a directory like C:\LINUX like a normal DOS application and start it from MS-DOS like a normal DOS application".
It's hard to overstate how important that was at the time. If you had a system running MS-DOS (like most people), with or without Windows 3.x (which also started from MS-DOS like a normal DOS application), you could install Linux without changing anything on your system, and if you didn't like it, you could simply delete the corresponding directory and everything would be gone. That (together with small Linux distributions which ran from a pair of floppies) made it much easier and low-risk to try Linux, and IMHO was one of the things which helped it gain enough marketshare and mindshare to later stand on its own.
(That was my own path with Linux: I started running it as a "normal DOS application" with UMSDOS and LOADLIN, then I moved to a dedicated partition with ext2 and LILO, and finally I discarded MS-DOS completely and gave the whole disk to Linux.)
More importantly, it allowed you to use some hardware that wasn't supported on Linux. I had a sound card that needed a DOS driver to provide Sound Blaster compatibility and this was the only way to use it from Linux.
How does it work? I wasn't using computer at that era but it sounds like start running Linux kernel from MS-DOS. Linux Kernel take the control and overwrite MD-DOS from the memory. So there will be no MS-DOS to operate the sound card.
Probably a "compatible" card that would behave like the standard of the era only after being setup by a DOS driver. Linux, like DOS programs, would find it only after such a setup. Perhaps even the card setup would not survive a reboot.
It wasn't anything like WSL. WSL runs Linux programs under a different kernel by replicating the syscall interface. This was basically a bootloader (loadlin) and a filesystem driver (umsdos). This was a very different world because DOS was hardly an operating system at all, it was just this tiny thing that installed itself into some interrupt handlers right after BIOS. Loadlin could take over and load a full linux kernel, no different from how grub works today (or LILO before that).
Yes, DOS was basically a boot loader and utilities. The EFI shell is modeled the same way, though DOS had fewer address bits available. Netware also used it in this fashion, as a boot loader that may/not initialize hardware.
From memory, the next stage of the OS would simply write itself over DOS in memory, move the instruction pointer and go.
The difference is that WSL either emulates the Linux system call interface (WSL1) or runs Linux on a VM (WSL2); in both cases, the operating system running the machine is still Windows.
With LOADLIN, the Linux kernel completely replaced MS-DOS in memory. To get back to DOS, you had to reboot. Since MS-DOS was a single-task operating system (that is, you weren't normally running anything else at the same time, other than perhaps a few utility TSRs), and it booted quickly (other than the slow memory counting in the BIOS if you had that enabled), that was not a big deal.
Running loadlin from MS-DOS was peak Linux usability, IMHO:
There was a whole entire (simple, limited) operating system to work with (MS-DOS) to use for sorting out any issues with booting the "real" operating system, and that bootloader-OS worked well with the hardware, and was familiar to the people using it -- at that time.
I used it for a long time (longer than most, I'm afraid). The method provided for systems that would [hopefully, and almost-alwaus] successfully boot MS-DOS, whereafter the boot environment was easy to manage and sort out so that a real operating system (Linux) could be loaded and run.
Back then, given any working PC, it was trivial to make an MS-DOS boot floppy, and therefore it was also trivial to make a Linux system boot up with loadlin.
After that, I used LILO for a time: LILO worked great if everything was in order, but it tended to fall down hard if things weren't just-so.
And then: GRUB. I still hate GRUB. (I will probably always hate GRUB: It still has too much interdependence between boot and system environments. It has done an OK job at autocnfiguring itself for a couple of decades, but that interdependence remains, and things can get hairy on reboot when the autoconfig doesn't do the right thing for whatever reason. It all feels like it is too limited, and also too far-reaching -- concurrently.)
tl;dr, I dearly miss the seemingly-simple concept of using a "real," common, minimal-ish operating system as a bootloader. I've been told that UEFI provides something similar to what MS-DOS and loadlin provided, but I haven't found a single utterance as to how that's actually supposed to work. Working within UEFI seems to be mostly a dark black box in common use, and the boot environment should never be a black box.)
Well, if MS-DOS is something you'd be comfortable debugging issues within, then I imagine you'd be even happier using live images to debug issues.
For smaller ISOs, you can even just stuff it on your boot partition and have e.g. the arch install ISO as a permanent boot option should you ever need to debug. I have the Arch ISO there, in the off-chance that I massively screw up and have no spare computer to prepare an image/aid in debugging.
> And then: GRUB. I still hate GRUB.
I'm not a huge systemd fan, but systemd-boot just works. Configuration is trivial and does not require rebuilding, so you can change settings from anything that can mount your EFI system partition.
It does have one annoying quirk, and that is that if your forget to fill in your loader.conf (needs a default entry and timeout which is commented out by default in e.g. Arch), then it silently fails.
> I've been told that UEFI provides something similar to what MS-DOS and loadlin provided,
To some extend - if you drop to the EFI shell (assuming your firmware includes one, otherwise you can bring your own), you can navigate supported filesystems and load ramdisks and kernels and such.
It can host fancier apps too, but I haven't done more than just read files and load OS's. Useful when you effed your system and your bootloader.
I second the "have a recovery distro installed permanently on your computer" thing, it has saved me countless times. My choice is Puppy Linux, since it's impressively tiny and has a good selection of recovery tools preinstalled, but is also totally usable as a desktop OS in case I really need to get some things done before I have time to recover my system.
Since the advent of bootable ISOs on disc and then large USB flash drives, I haven't bothered with any kind of recovery options on my computer, and now actively remove them. See recovery partitions, recovery kernel (on fedora) etc, etc.
Feels redundant, and I enjoy having the disk space back. An external flash boot drive has saved me countless times, and is useful for other stuff.
On it I now use Ventoy, which I heartily recommend. So much better than imaging the whole drive.
Ventoy is great[0], but with laptops easily having 2TB for cheap nowadays, leaving room for a sub-1GB ISO on the boot partition is not really space that would be missed. I also feel that any time one really needed an ISO, no flash drive near me ever had the right one.
[0]: ... when installed, but the installation process is awful. For GPT, it's just a FAT partition with the ESP flag and a few Ventoy files on it, and yet you need to run "installers" as root to "prepare" the drive. It should just have been a tarball and a few trivial commands - not a thousand lines of bash shelling out to a custom C partitioning tool...
I have lot of multi GB movies/series in process at any time so always short on space and don’t want to lock it up in another partition.
You just put several isos on it once a year. It’s usually not installed, just run. Any live distro can download additional tools as needed. And really any from the last five years are fine, partition tools and text editors haven’t innovated recently. Maybe you’d want the latest btrfs tools possibly, if so download.
A cheap 64GB! flash drive dedicated to the purpose and put on a keychain works well. Think I looked for 32GB but needed to go 64 to get usb3.2+ transfer speed, which I also recommended. Still so cheap!
Great for test driving new distros too.
I agree about ventoy, but only had to install it once, and already blocked it out, haha. Hopefully someone strips it down and adds a lite version to debian.
I used MS-DOS as flexible and (at the time) familiar environment from which to run a bootloader, which in turn loaded up a Linux kernel.
Live images aren't the same thing, I don't think: Sure, I can do all kinds of useful stuff with them, and they're vaguely as familiar as any other Linuxey-thing is.
But AFAIK there is no Linux equivalent to loadlin, so I can't use a live image as a flexible environment from which to run a bootloader like I did with MS-DOS over a quarter of a century ago.
> But AFAIK there is no Linux equivalent to loadlin, so I can't use a live image as a flexible environment from which to run a bootloader like I did with MS-DOS over a quarter of a century ago.
> And then: GRUB. I still hate GRUB. (I will probably always hate GRUB: It still has too much interdependence between boot and system environments. It has done an OK job at autocnfiguring itself for a couple of decades, but that interdependence remains, and things can get hairy on reboot when the autoconfig doesn't do the right thing for whatever reason. It all feels like it is too limited, and also too far-reaching -- concurrently.)
GRUB might disappear in the future. You might already switch to systemd-boot (which is basically gummyboot if my understanding is correct?).
But Lennard Poettering & co is working on UKI (unified kernel image) that should make linux bootable from UEFI directly (no grub or other boot loaders needed).
I didn't dive that much into UKIs but if my understanding is correct an UKI should be a bundle comprising a linux kernel, an initramfs and a few more things, packed as an executable that UEFI can launch.
This should simplify a few things (like cryptographic chain of trust) and make some things smoother.
Directly booting Linux kernels on EFI has been possible for quite a while thanks to the EFI stub[0], which is maintained by the kernel developers.
I'm not sure if having yet another implementation of EFI booting Linux kernels, such as UKI, especially if done without support from the kernel developer community, will bring anything but useless competition and strife. The whole kdbus controversy comes to mind.
Vouch, EFISTUB has been by far the fastest method of booting a Linux kernel for me. It's also prettier IMHO, since there already is a framebuffer set up with the correct resolution for my display, provided directly by the UEFI.
Especially if you already compile your own kernels, IMHO, there's almost no excuse not to use EFISTUB other than if your specific firmware isn't compatible with it for whatever reason.
rEFInd has been my goto when using UEFI. Finds most boot partitions without having to configure anything.
Configuration is just a single line:
"Boot with power options" "ro cryptdevice=UUID=XXXXXXXXXXXXX:root root=/dev/mapper/root initrd=amd-ucode.img initrd=initramfs-linux.img quiet amd_pstate=active"
I think for the past three years or so I've exclusively used EFISTUB, extra bootloaders just aren't necessary anymore because UEFI already implies one provided by the motherboard. I just use efibootmgr to set up an entry with the flags I want and boom. You're going to be waiting for the motherboard's bootloader to load anyway, so you may as well have it load the actual kernel rather than another bootloader.
EFISTUB is a Linux config option that has to be specified at compile time, so you do have to compile your own kernel if the distro you're using doesn't already enable it, but I compile my own kernels anyway so this is fine.
It is technically a bootloader. However it looks inside of itself for the kernel, ramdisk, and kernel commandline [0]. This means that you can use objcopy to put an existing kernel and ramdisk into a standalone EFI executable; without needing to recompile anything.
Dracut even has a "--uefi" option that will do all of that automatically.
[0] Although if secureboot is disabled, you can override the cmdline from the EFI if your firmware exposes that functionality.
I stuck with LILO as long as I possibly could too. I was gutted the day I had to switch to GRUB. Like yourself, I don’t think I’ll ever learn to like GRUB.
There was also lubuntu which allowed installing into a file/directory on NTFS --- really wish it was still around (and that there was better driver support for odd hardware such as Wacom's current generation of Wacom EMR).
Zipslack was such a good distribution. In fact there were a number of gnome 1.4 based environments that ran quickly on tailored environments for what you mentioned like early Vector Linux. It was a fun time
Some of us here might remember the joys of using MS-DOS, Windows, Linux, and OS/2 Warp (with extended attributes) all from the same FAT16 filesystem.
(And actually, that usually worked OK. They didn't fight. The filesystem shims, where necessary, weren't always the most reliable, but the operating systems themselves and the applications associated with them were generally pretty chill together.)
There was also Wubi[1], which, while not exactly this (which is more about putting a Linux FS in a WIM) was a windows based installer for Ubuntu which would save your disk contents on the NTFS partition in a single file (much like swapfile.sys).
Some of the earliest versions of Linux would drop a file onto your fat32 partition and boot from that, and replaces the currently running version of Windows. No messing with bootloaders or partitions, as long as you had free space to run the whole thing, it just worked.
Should be pretty easy. Capture a WIM of a Windows EFI partition, then use wimlib-imagex to apply that and also the install.wim.
I'm not sure if the Windows boot process requires the UEFI boot entry to be present or if they drop their efi file in the standard location... but if not, you should just be able to copy it there.
Abusing wimlib's pipable WIM format allowed me to build a Windows PE-based installer that deployed a WIM to a hard drive... from a tape drive attached via USB.
I streamed the entire install from the tape right onto the hard drive and it... worked amusingly well.
So you have a spare Windows installer, but don't have a spare 8GB usb stick? It's a matter of downloading an image writer like Balena Etcher and an ISO and you're done
If you use Ventoy instead of Balena Etcher you can even still use the USB for other files
Except it's not. Today, Windows wants you to use their media creation tool, which is more than just a "download bootable image and flash it to removable media" tool, but also actively slipstreams the latest OS patches to the install media. It ensures you get the latest OS on install with all the needed security patches.
Having a similar tool to automate not only bootable media creation, but also selection of distro and acquisition of install media would indeed make installation more simple. Unetbootin used to do that (still might? Haven't used it in ages), but IIRC, keeping the list of distros up to date was a challenge.
I think this may fall under the commenter's definition of "too complex." This kind of thing is normal for old heads, but I installed Linux on dozens of machines before I ever had to do manual anything. Just slap the iso onto a flash drive or DVD, and go.
Nix broke the streak, and even that was just a matter of following instructions in their wiki.
I have done my share setting up systems, I just don't have the patience I had when I was younger, put 2 hours into it. Gave up. There are new thing that I don't understand, need to learn that to understand. To much work. Just need to buy that usb stick
It won't be a problem getting a usb stick, but I disagree that it´s not a hurdle
Why hasn't any distro create a Windows installer? I think it would increase the usage. Today you need to download an .iso file, you need to know how to set it up on USB, then restart.
Circa ~2013-2014 i don't remember ubuntu had a windows installer you'd downloand then reboot after installation, no usb drive needed. It's how my gf at the time, no wife, got her torrenting partition on her pc. Idk what happened but that's not a thing anymore :'(
I wanna say it was a little different? Super idiot-proofed for a windows user. Download a .exe from the ubuntu website, might've downloaded something after installation I don't remember, then click a few buttons and wait.
What would be more interesting is installing Windows from a Linux live boot environment. It could actually be very useful to have a custom open-source Windows installer like that, with customization options and repositories with community-made mods.
This is actually possible. There's Linux tools to extract the WIM files from a Windows installation iso. You have to create the appropriate partition setup (EFI partition with bootloader, NTFS partition with the extracted files), and for configuration of the bootloader I created https://github.com/U1F984/create_bcd/
Very nice implementation of a BCD creator. And in a language I can read, heh.
The only thing that's missing would be driver reflection. I always wanted to have a magic command to just reflect a driver from WinPE into an already-installed Windows, but that seemed to be handled directly by Windows Setup back when I looked at it.
I think you can do it with DISM nowadays though. So just make a trip through a WinPE on the way to starting for the first time and everything would probably work fine.
I would bet that FOG[1] probably handles all of this reliably already. Anyone wishing for a real devops-style workflow for Windows installation could also look at Glazier[2].
The windows install process is actually pretty hackable despite not being open source. It largely boils down to extracting an OS image archive into a partition and installing the boot loader in another, all of which can be directed manually via CLI from the install media (shift+F10 if you want to do it manually). So the modifications are more or less: Do you want to customize the partitions? Do you want to tweak/replace the bootloader? Do you want to extract a custom image? Do you want to modify the image after to customize the install?
I did consider it, but you'd also have to modify the copy of the fstab in the initramfs in addition to the one in the root. Admittedly I didn't try very hard to make that happen, I just wanted something working for the bit. :P
Make a partition, copy the kernel and base system of your choice there, copy GRUB to EFI partition, configure it to load that kernel, reboot. Because of lemmas [1] and [2], the problem is solved.
[1]: Any Linux system can be turned into Arch/Gentoo.
[2]: Arch/Gentoo can be turned into any Linux system.
If you are not limited by RAM size and metered traffic, enabling or installing tiny PXE boot agent is even faster. Then you can load everything netboot.xyz offers, including regular installers.
Now that Linux has a rather good NTFS support, it should be possible to just have a folder in C:\Linux with the plain rootfs in there without any kind of virtual disk.
I know OSX has a tool to automatically fix permissions, is there anything in Linux?
If this installed + used a driver for btrfs or ext3 on the Windows side, I wonder it might be 99% of the way there (combined with however the permissions fix would work).
> This is formatted as NTFS, mounted at / using the ntfs3 partition type
IIRC, the Paragon ntfs3 in-kernel driver is extremely fragile and hasn't been maintained properly since its merge. It's a mildly amusing novelty to see /usr, /bin, Program Files and Windows all in one root, but the novelty wears off real quick as the filesystem is just so brittle.
The author discusses this as a caveat at the end of the post—glad it was at least mentioned.
[1] which has since been improved by Endless, so linking to their repo