How to Package an Installed Linux system into a UEFI-bootable ISO

In a previous tutorial, we discussed the Systemback application that allows us to create a bootable live system from an installed Linux system. However, Systemback was no longer maintained. Luckily, we can do the same with standard ISO packaging tools in Linux.

The key is to create a hybrid ISO that contains both legacy BIOS and UEFI boot records. Two approaches are available :

• Method 1 (GRUB 2) is modern and recommended.
• Method 2 (SYSLINUX) is a viable alternative.

For simplicity, I will only show you how to do it with Grub. It’s easier and straightforward.

🚀 Using GRUB 2 (Recommended)

This is the method used by mainstream Linux distributions. GRUB 2 handles both legacy BIOS and UEFI boot.

Install grub2-common and xorriso.

sudo apt install grub2-common xorriso

Create working directories

mkdir ~/{source_fs,iso_content}

• ~/source_fs : You will copy the root file system to this directory. 
• iso_content: This will be the root directory for the ISO

Copy your running system into source_fs. Exclude virtual & temporary directories (/proc, /sys, /dev, /run, /tmp) and also exclude ~/source_fs and ~/iso_content to avoid recursion. Example:

sudo rsync -avx --exclude={"/proc/*","/sys/*","/dev/*","/run/*","/tmp/*","/home/your_username/source_fs/*","home/your_username/iso_content/*"} / ~/source_fs/

Edit the fstab file.

sudo vi source_fs/etc/fstab

Comment out every line in this file. Save and close the file. Then make sure the /media/your_username/ directory is owned by you.

sudo chown your_username:your_username source_fs/media/your_username/ -R

Create the SquashFS Image: Compress a complete Linux root filesystem (with directories like /bin, /etc, /usr) into a SquashFS file, usually named filesystem.squashfs

mkdir iso_content/live

sudo mksquashfs source_fs/ iso_content/live/filesystem.squashfs -comp zstd

Copy the necessary Linux kernel (vmlinuz) and initramfs (initrd.img)

cp source_fs/vmlinuz iso_content/live/
cp source_fs/initrd.img iso_content/live/

Create the grub.cfg file.

mkdir -p iso_content/boot/grub/
nano iso_content/boot/grub/grub.cfg

Add the following content.

set default="0"
set timeout=10
menuentry "My Live Linux System" {
  linux /live/vmlinuz boot=live live-config live-media-path=/live findiso=${iso_path}
  initrd /live/initrd.img
}

If your computer has plenty of RAM, you can add the toram parameter at the end of the second line, so the entire live system will be copied into RAM.

linux /live/vmlinuz boot=live live-config live-media-path=/live findiso=${iso_path} toram

Save and close the file. Finally, run grub-mkrescue to create the final ISO file

sudo grub-mkrescue -o my_live_system.iso iso_content -iso-level 3

Now you can test your ISO file in VirtualBox, or use dd to write the ISO file to USB flash drive. Note: You can use dd to clone the ISO image to a partition (/dev/sdb1) instead of a disk drive (/dev/sdb), like the command below. This is useful when you have a large disk, but don’t want dd to format the entire drive.

sudo dd if=my_live_system.iso of=/dev/sdb1 status=progress

You can also use Grub to boot the ISO file without creating a bootable USB drive.

The GRUB UEFI Boot Process for a USB drive

The process begins when you turn on the computer.

1. The UEFI firmware checks if the USB drive is bootable. For a UEFI system, a bootable USB drive must contain a GPT partition table with an EFI System Partition (ESP). This ESP must be formatted with the FAT32 filesystem. It’s usually hidden from file manager. You can run sudo parted -l command to check the partition info on the USB drive.
2. You choose to boot the computer from the USB drive.
3. UEFI firmware looks for a specific, standardized path on the EFI System Partition. For removable media like a USB drive, the mandatory fallback path is: \EFI\BOOT\BOOTX64.EFI. This is the standard 64‑bit UEFI boot filename. In our case, this is the Grub UEFI boot loader. 
4. UEFI boot loader searches for its configuration directory (/boot/grub/). This directory contains the main configuration file (grub.cfg), modules, and other files.

5. The BOOTX64.EFI binary is relatively small. It loads additional modules from /boot/grub/x86_64-efi/ to gain more functionality, such as support for specific filesystems (part_gpt, fat, ext2), video modes (gfxterm), and boot commands (linux, normal).

6. GRUB processes the grub.cfg file. This text file defines boot menu entries, default boot options, timeouts, and various other settings. Based on the configuration, GRUB displays a graphical or text-based boot menu that lists available operating systems.

The Shift to UEFI-Only is Accelerating

The transition away from BIOS is not just underway; for most modern use cases, it is already a reality. Providing a UEFI-only bootloader is not only sufficient but is rapidly becoming the expected standard. Several converging trends are making it possible and advantageous to drop BIOS support:

• Mandated by Major OSes: Windows 11 has officially required UEFI and Secure Boot since its launch, and its market dominance effectively sets a global hardware standard. In the Linux world, major distributions like openSUSE are actively planning to drop Legacy boot support in releases like Leap 16, and Fedora is considering similar deprecation measures.

• The End of BIOS on New Hardware: The industry has already decisively moved on. Intel began phasing out CSM support in 2020, and from its 12th generation CPUs onwards, many motherboards have removed the option entirely. AMD has followed suit with its AM5 platform, meaning that brand new computers often have no BIOS compatibility mode to enable, forcing a UEFI-only configuration.

• Technological Benefits: UEFI isn’t just “new”; it is demonstrably better. It offers faster boot times through concurrent hardware initialization, supports booting from drives larger than 2TB via GPT, and includes critical security features like Secure Boot. Running a modern NVMe SSD in Legacy/CSM mode can severely limit its performance, reducing data throughput by over 30% in some cases.

The New Hardware Reality: UEFI Class 3

The UEFI specification classifies firmware into different types, and “Class 3” is the key term for the future we are entering.

• Class 1 vs. Class 2 vs. Class 3: Class 1 systems are pure BIOS. Class 2 (the vast majority of computers today) are UEFI firmware with a Compatibility Support Module (CSM) that acts as a BIOS emulation layer for legacy OSes.

• Class 3 is the Future: Class 3 firmware has the CSM physically removed from the hardware, leaving no legacy boot capability whatsoever.

• It’s Already Here: Many new laptops (e.g., from HP, Dell, Lenovo) and pre-built desktops from major manufacturers are now shipping with UEFI Class 3 firmware. On these systems, a UEFI-only bootloader is not a choice—it’s the only option.

BIOS Support’s Long Tail and Graceful Phase-Out

Despite this clear trend, there are still older, BIOS-only machines in use, particularly in enterprise, industrial, or embedded environments. This creates a classic support dilemma for OS maintainers. The emerging strategy is not to “turn off” BIOS support overnight, but to signal a definitive end-of-life for it. Fedora’s proposal, for example, would move BIOS to a “deprecated, community-maintained SIG” status, with plans for eventual removal from the main product. For your own work, if you are targeting modern hardware or creating a custom ISO for your own new computers, you can confidently go UEFI-only today. For maximum compatibility with older hardware, you may still need to support BIOS for a while longer.