|Raspberry PI upgrade to Debian 11 (bullseye)
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.
mbr2gpt.exe to perform an in-place upgrade of
the Windows 10 C: drive.
mbr2gpt also has a stringent
list of pre-requisites:
The validation step:
mbr2gpt /validate /disk:4
failed with the helpful error message
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
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.
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
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
the warning message regarding missing firmware no longer appeared,
the radeon driver was still not being used by X. Also, the log file
glx module could not be loaded, despite the
apparent presence of the required
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
(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.
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 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
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.
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
|Raspberry PI upgrade to Debian 11 (bullseye)