Moving from MBR to GPT and UEFI

My Windows 10 installation on amber was not eligible to upgrade to Windows 11 for many reasons. The first, and most basic, was that Windows 10 was on an MBR partitioned disk, using legacy MBR boot. See below for the other reasons Windows 11 cannot be installed.

I used mbr2gpt.exe to perform an in-place upgrade of the Windows 10 C: drive. mbr2gpt also has a stringent list of pre-requisites:

• The disk is currently using MBR
• There is enough space not occupied by partitions to store the primary and secondary GPTs:
• 16KB + 2 sectors at the front of the disk
• 16KB + 1 sector at the end of the disk
• There are at most 3 primary partitions in the MBR partition table
• One of the partitions is set as active and is the system partition
• The disk does not have any extended/logical partition
• The BCD store on the system partition contains a default OS entry pointing to an OS partition
• The volume IDs can be retrieved for each volume which has a drive letter assigned
• All partitions on the disk are of MBR types recognized by Windows or has a mapping specified using the /map command-line option

The validation step:

  mbr2gpt /validate /disk:4

failed with the helpful error message "Validation failed". In my case the reason for failure was the lack of space at the end of the disk. I used gparted in Debian to shrink the last partition (a no-longer functioning recovery partition) to free up enough space.

Once validation passed, the conversion was performed by:

  mbr2gpt /convert /disk:4

which only took a couple of minutes. After that, I could boot into a UEFI version of Windows 10.

Converting Debian to UEFI

However, since Debian was still MBR-based, GRUB could not boot into Windows. Not supported, apparently. To regain the ability to boot Windows 10 via GRUB, I needed to also convert Debian to GPT and UEFI.

The only way I could see to do this was a fresh install of UEFI Debian bullseye. Oh well, maybe a good opportunity to remove some cruft after years of upgrading Debian in-place.

I decided to simplify the disk paritions to root, /tmp, /var and /home during this process but keep XFCE as the desktop. The install appeared to go well; at least, until I rebooted. The graphical login screen was only 1024x768. It remained the same after I had logged in. Investigation of /var/log/Xorg.0.log showed that the fbdev was being used, not the radeon driver (graphics card is an old ATI RV730XT [Radeon HD 4670]). The boot log contained a warning message about missing radeon firmware. Ah, that'll be it.

However, after installing firmware-amd-graphics, while the warning message regarding missing firmware no longer appeared, the radeon driver was still not being used by X. Also, the log file showed the glx module could not be loaded, despite the apparent presence of the required libGL.so.1 files.

I tested the system using a buster-based USB drive and found that X started the radeon driver perfectly well, giving full 1920x1080 resolution on both monitors. I also noticed, and I had forgotten this effect of loading the radeon firmware, the console resolution changed once it was loaded. That didn't occur with the failing bullseye instance.

To fix this, I installed buster on the target hard drive, with the intent to upgrade to bullseye. Of course yet more problems. The grub (dummy) would not install at the end of the buster setup. Hmm, well grub was probably still there from the original bullseye install. I used GRUB on the buster USB drive to boot into the newly installed buster and, well bugger, no login screen. However, I could ssh in, so ran update-grub that way. I also set the default systemd target so that a console login was required via:

  sudo systemctl set-default multi-user.target

Once I could boot the new buster instance and login, I installed the radeon firmware after updating /etc/apt/sources.list to add the non-free repositories. The X radeon driver worked. I upgraded to bullseye and still radeon worked.

That was a lot of effort to end up having everything the same.

Things I had forgot

Enabling Wake-On-Lan

Systemd method of making network adapter support WOL

  [mark@amber:~]$ cat /etc/systemd/network/10-ethernet.link
  [Match]
  OriginalName=*

  [Link]
  NamePolicy=kernel database onboard slot path
  MACAddressPolicy=persistent
  WakeOnLan=magic

NFS mount settings

  # nfs mounts
  opal:/home/mark       /share/mark     nfs retrans=1,retry=0,timeo=60
  opal:/rep/public      /share/public   nfs retrans=1,retry=0,timeo=60
  opal:/rep/music       /share/music    nfs retrans=1,retry=0,timeo=60

You can't have Windows 11 because...

• Your system is MBR-partioned..
• Your system does not boot with UEFI.
• Your system is not subject to Secure Boot using TPM 2.0
• The AMD Ryzen 7 1700 CPU is not supported.

So, I have jumped the first two hurdles. The third hurdle is more difficult. I have installed a TPM chip, which appears to be OK, When I attemped to switch the BIOS option for [Advanced -> Windows OS Configuration -> BIOS UEFI/CSM Mode] from CSM (Compatability Support Module) to UEFI, the BIOS tells me I need to enroll keys in user mode. The BIOS also tells me that the Graphics Output Protocol (which, I assume, means the graphics card), does not allow the switch to Secure Boot and the BIOS rolls back to CSM.

I guess I need to buy a more modern graphics card, but finding something at a reasonable price is rather tricky at present.

Prehaps I will need to resort to the registry hack to cause Windows 11 to skip the CPU and TPM/Secure Boot checks. Another day, maybe.

Addendum - MSI BIOS Settings for UEFI/Secure Boot

Menu: Boot -> Boot Mode Select [Legacy+UEFI|UEFI] Menu: Security -> Trusted Computing (everything enabled that can be)

  TPM2.0 Device Found
  Firmware Version: 3.6
  Vendor: AMD

Menu: Advanced -> Windows OS Configuration -> BIOS UEFI/CSM Mode [CSM|UEFI]

Changing this option to UEFI displays two more menu items:

  GOP Information (Unknown Driver)
  Secure Boot