My monkey-testing results: amdgpu is not ready, blackscreen (I think MUX, not backlight), some propositions for Troubleshooting section

Hello, all!

I used the Resolute Daily ISO from 03/12/2026 on my laptop.
It was interesting to try to enable TPM-FDE “out of the box”, right at the installation stage.
I used the UEFI (BIOS) options to hide the primary NVMe drive from the system, gave the Live Installer the entire second additional NVMe drive, and tried various ways (monkey-testing until you succeed) to get the installer to accept my system as “available for installation using TPM-FDE”.
I also tested my laptop in quite detail for compatibility with 26.04 in general.
I was pleased that the keyboard backlight worked like in Windows, set to turn off after 30 seconds, and the backlight does turn back on when you press a key. It didn’t turned on after turning off on 24.04.
My attempts to use TPM-FDE ended with an error about “you have very new hardware, we haven’t seen anything like this before”. That is:
“PCR_UNUSABLE
error with secure boot policy (PCR7) measurements: generating secure boot profiles for systems with timestamp revocation (dbt) support is currently not supported”
If I understood GhatGPT correctly, he advised me to appear in two places: WithSecureBootPolicyProfile should accommodate systems that support timestamp revocation · Issue #306 · canonical/secboot · GitHub and TPM-backed FDE: Take 2 minutes to help widen Ubuntu compatibility with your TPM configuration! - #29 by dnxb42 , there were no additional questions here, I offered help on the first link, and on the second I sent 2 answers to the form, as requested.

But my testing of the Ukrainian translation was super successful, there is nothing to complain about here. There is a place for a few corrections, thought.
In addition, I saw some screens with translations for the first time after conducting initial testing in Hyper-V for quite a long time.

Regarding installation issues: they were minimal.
First, I’ll add a suggestion to include in the Troubleshooting section of the Release Notes:
If you have a laptop, and when booting from an ISO in Live mode, after the initial screen with the laptop manufacturer’s logo (for example, Acer Nitro) and the “round boot indicator” the image disappears, then perhaps it is because the Radeon video adapter does not behave very well at startup. If the system has two video adapters and Optimus/Advanced Optimus, then it may happen that the system needs to be rebooted into UEFI, and there enable the Nvidia GPU Only mode in the Display mode switch. (see pictures)

In general, on Windows I already had a problem installing reference Radeon drivers, and I already know that AMD themselves recommend installing the OEM version of the Adrenaline driver, and with AI we once figured out why this is so and how to deal with it, here, (for additional reading, you can skip it, because for this post it can be considered a bit offtopic): https://www.reddit.com/r/AMDHelp/comments/1op3i71/amd_reccommends_to_stick_with_vendor_laptop/ - my personal experience and conclusions on Radeon graphics in the laptop mentioned in this post, applies to Windows.

Let’s go back to Resolute.
I think that the problem with MUX (Optimus) is a problem in this case too.
There is no OEM Acer driver for Linux.
And the driver that “comes with the installer” has the same symptom as when installing the reference driver on Windows, that is, a black screen at some stage of system boot.
It is worth noting that when I booted in Live mode, the external display connected to the HDMI output worked without additional options.
Therefore, another recommendation for the Troubleshooting section - advise connecting an external display that is switched to the Nvidia video adapter.
If the display receives an image, and the mascot - Raccoon - appears there, then all that remains is to press the Win+P+P key combination (hold down Win, press P twice, release Win), this key combination will switch the graphics output to the “External display only” mode, and you will see the desktop that was displayed on the black screen, including the installer window.
After the installation is complete, after rebooting, when you see a gray background on the secondary display, this is a sign that the login screen has loaded on the main display, and since the system uses the secondary display in extended mode, you need to perform the following sequence of actions: after the gray background appears on the secondary display, count to 10, press Enter (confirm that we want to log in to our first account), count to 5, enter the account password, press Enter (login attempt). If you see Raccoon, then all that remains is to press the aforementioned Win+P+P to switch the main screen to the secondary display.

It is also worth noting that the current version of amdgpu refused to install for me.
In fact, my graphics on the primary display work fine just in Nvidia GPU Only mode - for my current experiments with Cursor, AI Agents, and Figma, this is enough for me right now.

I think it should be noted that I saw the PCR_UNUSABLE error after wiping the TPM module and even resetting the Secure Boot settings (including the “factory reset” option).
I think it would be more appropriate to immediately inform the owner that he will have a PCR_UNUSABLE error and the owner will not be able to do anything about it.

There won’t be screenshots, there will be screen shots, but I edited them a bit so they wouldn’t be too big.

Acer Latop used in testing: https://www.acer.com/ua-uk/support/product-support/AN17-41/NH.QL1EU.003/

Just a big FYI:

There was a bug in mksquashfs that was causing .iso images to be corrupted.

I don’t read Ukranian, but this does appear to be a similar issue to the issue described in that bug report (unable to extract file due to I/O error?). So, you might consider testing the next daily and see if that fixes it.

1 Like

Thanks for the warning. I used the ISO from 2026-03-12, I think it was good. But I may re-attempt later with another daily build just to be sure.

It was not a problem to install the system, but to enable TPM-FDE.

I took pictures of the installer (1, 2, 3, 5) to show the progress, and to show that there is “final error” :slight_smile: PCR_UNUSABLE which stopped my attempts to enable TPM-FDE, I used Passphrase-FDE instead, and it succeeded.

4th picture is a workaround to have builtin display working without blackscreen issue.

The 6th picture is one of my attempts to try to install amdgpu driver using an AMD manual after the system was installed successfully. It is failing to build. Bad thing that I didn’t save make.log from one of the attempts.

The reason I’m saying you should try a later daily build (there is one every single day at https://cdimage.ubuntu.com/daily-live/current/) is because none of these should be considered representative of the final product. There are known bugs that are constantly getting fixed, and simply testing one and determining something isn’t ready is completely expected.

For what it’s worth, Canonical has a whole test lab of computers in Taipei where they test just about everything on various pieces of hardware. I’m fairly certain what you’re seeing, as it was due to known bugs, is far from an edge case.

That said, continuing to test what is now an old daily .iso image is not going to do you (or us) any favors since it’s not representative of the latest bug fixes. I’d download the next one. It’s very easy from the command line if you install zsync:

cd ~/Downloads # or wherever you placed the .iso you initially downloaded
zsync -i resolute-desktop-amd64.iso https://cdimage.ubuntu.com/daily-live/current/resolute-desktop-amd64.iso.zsync

That will keep you from downloading the next .iso image entirely, recycling information from the old one into the new one. This saves bandwidth and, in many cases, time.

1 Like

Don’t worry, this wasn’t scepticism, that was a set of notes from yesterday’s attempt.

I will definitely try the fresh iso on the weekend.

As for the TPM-FDE - I know this is still an experimental feature.

I had run test-ubuntu-tpmfde-compat and put the outputs to form for Didier to look.

No blame for the Canonical team, just notes about my experiment with the alpha on my hardware.

I didn’t expect it to be stable in either way.

1 Like

Thanks for a hint about zsync.

dnxb4@denixxcomp-3 /cygdrive/c/OurData/dnxb4/Downloads/ubuntu_26.04_alpha_20_03-13_1
$ zsync -i resolute-desktop-amd64.iso https://cdimage.ubuntu.com/ubuntu/daily-live/current/resolute-desktop-amd64.iso.zsync
failed on url https://cdimage.ubuntu.com/ubuntu/daily-live/current/resolute-desktop-amd64.iso.zsync
could not read control file from URL https://cdimage.ubuntu.com/ubuntu/daily-live/current/resolute-desktop-amd64.iso.zsync

===

===

dnxb4@denixxcomp-3 /cygdrive/c/OurData/dnxb4/Downloads/ubuntu_26.04_alpha_20_03-13_1
$ zsync -i resolute-desktop-amd64.iso http://cdimage.ubuntu.com/ubuntu/daily-live/current/resolute-desktop-amd64.iso.zsync
#################### 100.0% 3094.5 kBps DONE

reading seed file resolute-desktop-amd64.iso: ***… … a lot of stars … …
Read resolute-desktop-amd64.iso. Target 94.5% complete. … stars …
downloading from http://cdimage.ubuntu.com/ubuntu/daily-live/current/resolute-desktop-amd64.iso:
##################-- 94.5% 7.4 kBps
#################### 100.0% 22932.1 kBps DONE

verifying download…checksum matches OK
used 6540750848 local, fetched 381144918

===

Cool, new experience. Thank you!

Erich, if you’re in a good mood, can I also draw your attention to the fact that the new Daily Live builds don’t work every day?
Maybe you know someone to show this to.

You say “there is one every single day” - that’s not 100% true.
Pay attention to what the size of the daily-live-nnnnnnnn.log files looks like here (this year): Index of /cd-build-logs/ubuntu/resolute
Some of the builds sometimes crash, and as a result the log file is literally less than 1 KB of text.
It happens that some builds crash for several days in a row.
I think this is the reason why, according to the link Ubuntu 26.04 LTS (Resolute Raccoon) Daily Build
, we have the amd64 build from yesterday, not today’s,
and the arm build is from the 8th.

I believe there is a field for someone’s review and improvement.

That’s 100% expected. They’re just for testing, they’re not guaranteed to ever work.

Yes, that’s because, just like anything that isn’t meant for production, builds will fail. That tells us there’s other problems to look for. It’s 100% expected and never guaranteed.

That’s happening every single minute for anyone who is constantly learning.

1 Like

Okay, I had a “retrospective“ session with ChatGPT, and it says I overengineered it a bit… :slight_smile:

Says he wouldn’t recommend installing amdgpu-dkms and recommends left the default inbox amdgpu driver.
And the problem for amdgpu-install -y --usecase=graphics is, as usual, it is not ready for the newer system.

As it was testing and I was trying to fix the black screen on my laptop, it was worth trying to. The failure is not critical, but in the case of success, it might repair the black screen for my system.

I see that I should not try it; maybe I just need to disable the Radeon iGPU each time I boot into this test system.

I think I’ve done what needed to be done.

A full set of tests in search of the place where it goes wrong.

@eeickmeyer Erich, please, take a look.
It could be interesting for the test lab crew to reproduce.

- AMD Rembrandt / Radeon 680M iGPU (1002:1681)
- NVIDIA GeForce RTX 4050 Mobile / Max-Q dGPU (10de:28e1)

Am I right in seeing that your laptop has an integrated AMD iGPU and a discrete Nvidia 4050? If that’s the case, your system most certainly won’t be using the amdgpu driver since that’s for discrete GPUs. What you need is the Nvidia driver.

You’re really overthinking it. If you simply use ubuntu-drivers install from the command line, your system will be set-up for everything it needs.

As for the testing lab, they only have “Ubuntu Certified” hardware, and your system probably doesn’t qualify for their tests.

Oh, the “Ubuntu Certified”, thank you.

Nope, it never had such a label on it or a note in its specs.

I should dig a little deeper into this topic. Thank you!

Yes, it is based on AMD Ryzen 7 7735HS with AMD Radeon 680M iGPU plus dGPU Nvidia GeForce RTX 4050 Laptop.

It’s a rare piece of hardware from 2023.
Bought it to have such an experience of having a laptop with Ryzen.
I think it never get Ubuntu Certified because of an unpopular combination of hardware.

How do you think, maybe it’s worth to “Won’t fix” the bug report?
It was useful to collect - to be documented (I hope it will help someone who is curious enough), but it might never be fixed, as the system has never been Ubuntu Certified. I don’t think ever would be.

No, go ahead and keep it open. The kernel team will decide what to do with it.

1 Like

Looks like older amdgpu/yellow_carp_dmcub.bin fixed my issues with Radeon.
Thanks to Mario Limonciello (superm1) instructions (comments 50 and 54).

https://gitlab.freedesktop.org/drm/amd/-/work_items/5143