Transfer a Debian installation from a larger UEFI drive to a smaller one while keeping the host system on BIOS boot by cloning partitions, adjusting UUIDs in /etc/fstab, and reinstalling GRUB with the correct target architecture. This approach avoids boot conflicts and ensures the new drive boots independently.
Understanding the Boot Environment Conflict
The core challenge here is managing two distinct firmware interfaces simultaneously. The primary computer uses Legacy BIOS (or CSM) to boot its large internal drive, which typically relies on an MBR partition table and a standard/boot or /boot/grub structure. The source Debian installation resides on a UEFI-capable drive, likely formatted with GPT and containing an EFI System Partition (ESP). When moving this OS to a smaller physical disk, you are not migrating the firmware mode of the *host* machine; rather, you are creating a portable or secondary boot environment that may need to function on different hardware or simply coexist without interfering with the existing BIOS boot chain.
It is critical to understand that UEFI and BIOS boot methods use different mechanisms to locate the bootloader. UEFI reads files directly from the FAT32-formatted ESP using GUID Partition Table entries. BIOS loads the Master Boot Record (MBR) and looks for a specific boot signature in the first sector, then chains to GRUB configuration files located in the standard Linux partition. Because these mechanisms are separate, you can safely have both systems on the same machine provided their identifiers do not collide.
Why UUID Conflicts Matter
A common misconception is that UUIDs (Universally Unique Identifiers) assigned to partitions will never clash. This is technically false. If you clone a drive without regenerating UUIDs, the new drive will have identical UUIDs for its root filesystem, swap, and potentially the ESP as the original. While some modern kernels handle this gracefully by preferring the first detected device, it can lead to race conditions during boot, incorrect mounting of swap, or GRUB failing to find the right kernel image if multiple drives with the same UUID are present. Therefore, changing UUIDs is a mandatory step in this migration process.Preparation and Cloning Strategy
Before touching any partitions, ensure the target smaller drive is connected and recognized by the system. You must calculate the space requirements carefully. A UEFI setup requires at least two partitions: a small EFI System Partition (typically 512MB to 1GB) and the main Linux partition. The total size of the target drive must be greater than the sum of the used sectors on the source drive plus the overhead for the new partition table. Use a tool likedd or rsync for data transfer, but note that simple bit-for-bit cloning will fail if the destination is physically smaller. Instead, you should create the partition layout on the new drive first, then copy the data. This gives you control over where the EFI partition sits and ensures the partition table fits within the smaller capacity.
Creating the New Partition Layout
Identify the target drive usinglsblk. Use gdisk or parted to create a GPT partition table on the new drive. Create the first partition as type EF00 (EFI System) and format it with FAT32 using mkfs.vfat -F 32 /dev/sdX1. Create the second partition for the root filesystem, using ext4 or btrfs depending on your source setup. Mount both partitions to temporary directories, such as /mnt/target_boot and /mnt/target_root.
Copy the contents of the old root partition to the new root partition. Preserve permissions and attributes using cp -a. Do not copy the entire old ESP into the new one yet; we will generate a fresh one to avoid identifier collisions.
Fixing Identifiers and Filesystem References
Once the data is copied, you must update the internal references to point to the new partitions. First, generate new UUIDs for the root partition usingtune2fs -l /dev/sdX2 | grep UUID to see the old one, then apply a new one with tune2fs -U random /dev/sdX2. For the EFI partition, since it is FAT32, you can reformat it with mkfs.vfat, which automatically assigns a new UUID.
Next, edit /mnt/target_root/etc/fstab. Replace the old UUIDs for the root and swap partitions with the new ones. If your system uses labels instead of UUIDs, update those as well. Failure to do this will result in a kernel panic or a dropped shell during boot because the initramfs cannot mount the root filesystem.
Reinstalling the Bootloader
This is the most complex part. Since the original system was booted via UEFI, GRUB was installed in the ESP. However, if you intend for this new drive to be bootable on a BIOS-only machine (as suggested by the title's context of "BIOS booting the computer's drive"), you might actually need to install GRUB in BIOS mode onto the MBR of the new drive, not in UEFI mode. If the goal is to keep the Debian instance UEFI-bootable but move it to a smaller drive, you must reinstall GRUB for UEFI. Chroot into the new system:mount --bind /dev /mnt/target_root/dev
mount --bind /proc /mnt/target_root/proc
mount --bind /sys /mnt/target_root/sys
chroot /mnt/target_root
apt install grub-efi-amd64-bin
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=debian
update-grub
exitgrub-install --target=i386-pc /dev/sdX. Ensure you specify the correct disk device, not a partition number. After installation, verify that /boot/efi/EFI/debian/grubx64.efi exists if using UEFI, or that the MBR contains the boot code if using BIOS.
Verification and Troubleshooting
Disconnect the old large drive to prevent any accidental interference or dual-boot menu confusion. Boot the system with only the new smaller drive attached. If using UEFI, enter the firmware settings and ensure the new drive’s ESP is selected as the boot option. If using BIOS, ensure the drive is set as the primary boot device in the BIOS order. Check the boot logs for any errors related to missing UUIDs or failed mounts. If the system hangs, it is almost certainly due to an incorrect entry in/etc/fstab or a mismatched GRUB configuration.
Frequently Asked Questions
Can I clone a UEFI drive to a smaller BIOS-only drive?
Yes, but you cannot perform a direct bit-for-bit clone. You must recreate the partition table on the smaller drive, copy the file data, and then reinstall the bootloader specifically for BIOS mode (GRUB PC target) rather than UEFI mode.What happens if I don't change the UUIDs?
If the new drive retains the same UUIDs as the old one, the operating system may mount the wrong partitions, especially if both drives are connected simultaneously. This can lead to data corruption, failed swaps, or boot failures where the kernel cannot identify the root device.Do I need to resize the EFI partition?
No, you do not need to resize the EFI partition unless the original was unusually large. A standard 512MB or 1GB EFI partition is sufficient for storing GRUB binaries and kernel images. Keep it small to save space on the smaller drive.How do I fix a black screen after installing GRUB?
A black screen often indicates that GRUB was installed for the wrong architecture (e.g., EFI instead of BIOS or vice versa). Verify your installation command matched the desired boot method. You can also try addingnomodeset to the kernel parameters in the GRUB menu to rule out graphics driver issues.