Why ISO was retired (2021)

In a traditional "full" installation, the filesystem occupies an entire partition, with the usual /etc, /bin, /usr, /proc, /sys, /tmp, etc. Easy does not install like this. Easy installs to hard drive in what we call frugal mode, which occupies just one folder in a partition, allowing to co-exist with whatever else the partition is used for. Installation is so simple: Just copy three files 'vmlinuz', 'initrd' and 'easy.sfs' into a folder in any ext4 partition, and that's it, Easy is installed. All that remains is to create an entry in the boot manager. [1]

Generally seems to be a highly stripped down, security focused Linux distro. No systemd, polkit, or even PAM. Heavily container oriented. Feels a bit like a lighter alternative to Qubes OS.

[1]: https://easyos.org/about/how-and-why-easyos-is-different.htm...

Our tooling evolves in some strange ways. The only reason you want an ISO is because some software insists that it can't use a simpler FS the same way. It's like the software that insisted on saving things into floppy drivers even after no computer had them anymore.

Of course, that software existing may be a good reason for the author to keep the ISO packaging. Or maybe not, I have no idea what is his context. But what you describe is a deficiency on your software, and not any intrinsic benefit from ISOs.

A good final half of the article is spent on blaming Ventoy's developers and users for holding it "wrong". And here I am left still wondering what is so bad about ISOs.

I just tried under libvirt. It doesn't work as a virtual CD, so just add a virtio disk and point it at the image.

The author was saying that these tools already do support booting image files, not that they could be modified by the tool authors to add support.

If the governance of this tiny distro is bad, don't worry, there are a million other tiny distros to choose from.

Things like Etcher or dd are nonideal when the "drive geometry" of the master that was imaged is not fully compatible with the target USB device and/or its bootability. The master image is simply written bitwise to the target regardless of differences in the "heads & sectors" that might be native to the target USB device, which can be a show-stopper when it comes to bootability, or it can compromise erase-block alignment which can dramatically slow the performance of an otherwise good master file set.

Bootable ISO's are made to boot using the Isolinux proper approach, one part of the overall Syslinux Project. Which means the ISO when burned to an optical disk or mounted will have an ISOLINUX folder in the root of its filesystem, and within that folder will be the boot files which allow it to boot as an optical disk.

The other parts of the Syslinux Project are Extlinux for network booting, and of course Syslinux proper for booting from FAT partitions.

The intention was to get a Linux ISO to boot from a HDD, you copy all files and folders from the optical disk (or mounted ISO) to the FAT volume of the HDD, rename its ISOLINUX folder to SYSLINUX, rename the contained isolinux.cfg file to syslinux.cfg, then "syslinux" the FAT volume and it will write a Syslinux boot sector to the volume which will then load and run the live fileset from FAT not much differently than if it was on an optical disk.

Traditionally a target USB device would be zeroed before inserting into the socket of a DOS/Windows/Linux PC. The USB device can then be partitioned MBR-style based on what the BIOS/OS detects regarding the native geometry of the device, without having a potentially nonideal sector 0 or other misleading data previously on the USB remain existent, which the partitioning and/or formatting process would prefer to replicate. The partition must also be "marked active" before it will be a bootable one, which is an important option to select when partitioning.

Once partitioned in response to low-level detected geometry, the USB device would then be formatted as FAT32 in DOS/Win9x, once again allowing the traditional OS to detect its preferred geometric layout, this time within the provided partition. This can make all the difference when it comes to bootability. Lots of people have never done this since DOS is so out-of-date, plus DOS did not support USB anyway so you had to plug in the USB device before you boot the PC so the BIOS can recognize the USB as a drive to begin with before DOS can then format it. Once formatted the volume would then physically start with a DOS Bootsector in place at its detected location, often sector 63 but also sector 16, 32, 64, 1024, or other choices can also be where the "native" volume might start instead. For booting you would still further need an actual Master Boot Record to be written to sector zero (to accompany the partition table already there) which would require careful use of the undocumented DOS FDISK switch /MBR. FDISK /MBR is best run when booted to DOS from a floppy (or some optical media), while the USB device is already plugged into the PC and there are no other drives connected to the motherboard, because FDISK /MBR will silently write the standard DOS MBR to sector 0 of the C: drive. Also before the USB would boot you would need an OS or at least some boot files to be present on the FAT32 volume, which was accomplished when booted to DOS by running SYS.COM on the target device which would write the 3 DOS OS files to the FAT USB.

Then ejecting the floppy and rebooting to the USB instead, the motherboard would then detect the USB as a regular drive with its recognizable geometry, read the Master Boot Record at sector 0 then jump to the Volume Boot Sector of the (primary) partition marked as active at the time. A DOS boot sector would then seek DOS bootfiles on that FAT volume and if present you get a DOS command prompt.

The modern alternative in Windows10/11/Linux would be to partition the zeroed USB, and set it active, followed by formatting it FAT32 using Windows. This would give you a Windows NT6 boot sector at the beginning of your FAT32 volume which will not boot to DOS but will instead seek a BOOTMGR file and an accompanying BOOT folder containing some NT6 bcd-style boot files. But for booting Linux you won't need BOOTMGR or a BOOT folder when using Syslinux. But you will need a Master Boot Record so use the Windows command bootsect /nt6 x: /force /mbr and it will overwrite the NT6 bootsector with a duplicate while also adding the optional MBR which is essential for booting, where x: is the actual volume of your USB device as seen by Windows.

Now for BIOS the Syslinux Project has been mature since 2014 at version 6.03, but most Linux distributions are using one of the poorly documented version 6.04's to achieve variable degrees of UEFI/GPT performance. The ISOLINUX/SYSLINUX folder will usually contain various of the helper files known as .C32's which need to be from the same exact version of Syslinux that the ISO was prepared from. If you can not run the Syslinux app to prepare the FAT volume from a distribution which has the same Syslinux version as the ISO, then I use version 6.03 from Windows while also replacing any of the .C32 files which may be present, with ones having the same filename from version 6.03 instead of the supplied files in my renamed SYSLINUX folder.

To recap,

Zero the USB device.

Partition and set it active.

Format it FAT32 in Windows, ideally label the USB volume with a descriptive moniker in 11 characters or less. Then run bootsect /nt6 x: /force /mbr.

Copy all the files and folders from the mounted ISO to the FAT volume. This works for Windows setup ISO's too (older ones with filesizes less than 3.2GB which can be handled by FAT32) which are then ready to boot at this point. For Windows setup ISO's where the install.wim file is too big for FAT32 you would have to format as NTFS instead of FAT, however some of the early large setup ISO's had the install file split into smaller install.swm's for use from FAT32.

Run SYSLINUX from Linux or Windows on the target USB volume, to prepare the FAT volume to boot Linux. This will write the ldlinux.sys and ldlinux.c32 files to the root of the FAT volume while also overwriting the NT6 bootsector with a syslinux bootsector as a replacement.

Change the name of the ISOLINUX folder to SYSLINUX, rename the contained isolinux.cfg file to syslinux.cfg. This is supposed to be how easy it was intended to be to change a proper distribution from optical to FAT. However as this knowledge has faded over the decades there are some distributions which may need further effort within the Syslinux folder (occasional editing of cfg files and kernel switches) in addition to making sure any .C32 files are from the correct matching Syslinux version.

P.S. there's no reason to use dd(1) for this; cp(1) works just as well and is usually faster, since it can autoconfigure the block size.

(Live images like this typically do have different bootloaders than your regular/dev/sda).

I think it's sort of the opposite. Read-only/write-once file systems can be simpler because they don't have to be structured in a way that allows things to change. For instance, full file systems generally need to deal with files that are laid out in a non-contiguous manner on the disk since files may change in size after creation.

I think the other aspect is that in the early days of CD-ROM a lot of folks envisioned there would be a lot of use cases that transcended a single operating system so having a universal file system for them was useful. And while some of the grander visions may not have won out, distributing plain data (photos, clip-art, etc.) on CD-ROM was a common use case and benefited from a cross-platform filesystem.

I suspect the ISO standard was more of a product of the traditional electronics industry than the computer industry.

At one time I was tempted into putting a UFS(the dvd filesystem) format on a flash drive, the theory was it would be a better filesystem than FAT and be readable in any OS. The problem was nobody ever implamented write routines for their UFS implementation, they were all read only. Sort of understandable as the key driver of UFS was a read only medium(the dvd). but it dashed my dreams of using it as a cross platform filesystem.