With the release of Nitrux 1.1.0, we’ve got new questions about our Linux distribution. Still, the most common issue has been the support for Legacy BIOS or CSM-enabled motherboards; if you’re wondering why we do not recommend other tools like Rufus to write our ISO to a USB, this the reason (see screenshot below).
Our ISO does not use the Master Boot Record partition table or MBR. Neither do we use SYSLINUX. In turn, we do not use ISOLINUX, so our ISO is not a “hybrid-ISO,” for example, check this screenshot of Konsole, comparing the Deepin 15.7 hybrid-ISO to the Nitrux 1.1.0 pure UEFI bootable ISO shows this difference.
Our ISO is a standard ISO-9660 bootable image. However, our ISO image uses the GUID partition table or GPT and directly uses GRUB2 to boot from the ESP or EFI System Partition. As we said in our release announcement, we only support booting from EFI and UEFI motherboards and not from the CSM or Compatibility Support Module or Legacy BIOS motherboards because of this, meaning that if you have enabled CSM in your UEFI to boot other systems, it must be disabled to boot Nitrux.
It is theoretically possible to use the ESP on an MBR device. This method, however, is untested, and it seems to produce more problems related to bootloader naming and NVRAM entries managed by efibootmgr. Furthermore, Intel plans to phase out support for the CSM by 2020. As such, we do not have any intention to spend resources on pursuing this method.
Also, EFI and subsequently UEFI motherboards have been available ca. 2010–2011, when Intel introduced its Nehalem architecture in 2008 and then when AMD launched its 800 chipset series in 2009 and later released it in 2010. These motherboards have been commonplace ever since, and this means that the kind of hardware that we are targeting is at least ten years old.
While rare, there were EFI compatible motherboards for older platforms such as Socket 775 Intel processors.
We understand many users may feel left out by our lack of support for Legacy BIOS motherboards or booting using the CSM or even 32-bit processors, but we cannot bear with the weight to support hardware that is over ten years old.
We are building a distribution for the present and the future and not for the past.
We believe that there are Linux distributions or BSD distributions that are better suited for this kind of hardware support in the same way that we believe that there other distributions whose goal is to provide vanilla or default Plasma and Ubuntu experience while ours is to provide an experience of our own.
From the GUI software to the method of acquiring desktop software to the way our distribution works. And that means narrowing down the hardware that we are targeting.