I just purchased a Thinkpad C13 after watching your talk and have spent the last 24 hours trying to get a working Linux install, without any success.
Right after installing, the system boots just fine but on most subsequent boots I get this error:
Console: switching to colour frame buffer device 240x67
I say most subsequent boots because sometimes the system manages to boot with no issues, after several attempts.
If I ignore the error and press Enter (I have to do this twice, as it goes into emergency mode again), the system boots but networking no longer works (no WiFi, no Bluetooth, no Ethernet).
Here’s a picture (couldn’t take a screenshot, sorry):
I first had this problem with Fedora 39.
Since I’ve tried:
- Fedora 38
- OpenSUSE Tumbleweed (latest version)
- Fedora 39 but with an older kernel
- installing Fedora 39 without encrypting my data (I usually have the installer set up LUKS)
Inexplicably, the rescue option on Fedora 39 worked well for a couple of boots. It stopped working after I did updates, which is just strange. What is breaking my boot?
On OpenSUSE, the error is slightly different. I will post a picture in the replies as I am limited to one image as a new user.
I’m honestly at a loss. I feel like I must be missing something very basic. Am I missing an EFI payload? Is there something that I need to add right after installing to avoid breakage? I did add “iommu=pt” to the cmdline but the boot stays the same.
Any help would be greatly appreciated.
Here is the image for OpenSUSE. This was after pressing Enter twice.
A couple details that I forgot in the main post:
- this is the 128GB NVMe model
- I am running the latest full UEFI firmware (TP enabled)
Hey, do a
dmesg once you start the maintenance mode. We need to see the kernel logs. Also, I’d suggest trying PopOS, as the kernel was a bit older and I got no issues in booting (I also had boot problems on my C13).
I can’t use maintenance mode without giving root a password but here is the
dmesg output after the boot (with broken WiFi and Bluetooth).
Dropbox link as I’m over the character limit
As for the PopOS suggestion, I will try installing, thank you. However I am miffed since Fedora should work. I see that @s31bz has been using Fedora 39 Cinnamon. Maybe there is some difference between the GNOME and Cinnamon editions driving this bug?
Update: PopOS just boots to a grey screen after install (and displays upside down on Live CD). Can’t access a TTY either but I assume this is due to keybinds
Here’s the current status of what I’m running on my Morphius.
Thank you. The only difference on my system seems to be that the Multimedia controller has Handle 0x0012.
I’ve now tried “updating” (reinstalling) firmware. No difference in behaviour as far as I can tell. I still haven’t figured out a pattern for when booting is successful and when it isn’t. All I can really say for sure is that I haven’t had a successful reboot, all of my successful boots have been from a powered off system.
Here is a
dmesg output from a successful boot, hopefully this can be helpful:
Maybe I haven’t looked incredibly close here, but I’m not seeing any reports of hardware failure, and the only real errors I’ve seen come up are these guys:
[ 18.293349] cros-ec-uart serial0-0: Timed out waiting for response.
[ 18.797940] cros-ec-uart serial0-0: Timed out waiting for response.
[ 18.797985] cros-ec-uart serial0-0: missing EC transfer API, cannot send command
[ 18.798003] cros-ec-uart serial0-0: Cannot identify the EC: error -5
[ 18.798211] cros-ec-uart: probe of serial0-0 failed with error -5
So I’ll just ask to be sure; after installing Fedora 39 with the desktop of your choice, have you run through the keyboard script and audio script from WeirdTreeThing’s github?
I hadn’t run the scripts yet when I made that
dmesg output but I have since: here is another output :
As you can see it’s quite similar.
dmesg does highlight the
kernel NULL pointer dereference in bright red and it isn’t there on the successful boot. This is probably worth further investigation.
I’ve also found some other limitations on this failed boot state: the touchpad does not work (trackpoint does) and USB drives aren’t detected (I haven’t tested any other USB devices).
Is the machine still in warranty? These sound like too many things failing at the same time to be a coincidence. I have a few friends with the
MORPHIUS board and when one started experiencing failures with his board, it was only a few months shy of the warranty ending.
I bought it used. Looking on the website, it seems like it still has 11 months warranty.
Just to be clear, everything that doesn’t work on these failed boots works fine on the Live CD, every time. I don’t think it’s a hardware issue.
Before installing the custom firmware, I did all of the diagnostics tests on ChromeOS and they all passed smoothly. The laptop only had 15 discharge cycles so I don’t think it was used much.
Please try booting with
iommu=pt, picasso is known to have issues with MMU due to PSP
I have been since the beginning, but maybe I didn’t set it up correctly? I added
iommu=pt to the end of the linux line in
/etc/default/grub and then ran
grub2-mkconfig -o /boot/grub2/grub.cfg.
Here is what it looks like if I press e before booting.
Okay, it looks like either:
a) Firmware bug (unlikely)
b) Kernel bug, related to UART
This shouldn’t be a problem, as UART is only needed for FPMCU in case of AMD platforms (at least AFAIK), which we don’t have a userspace driver for.
Can you try blacklisting
That fixed it, thank you! Strange that that was the issue, my laptop doesn’t even have a fingerprint reader.
For anyone else reading this I created a text file named
/etc/modprobe.d/nofpmcu.conf (any file name works) with the line
Interesting, I thought all MORPHIUSes came with fingerprint reader.
That would explain UART errors, haha
I did too, I was surprised when the seller handed it to me lol
Maybe coreboot should disable the device if there isn’t any fingerprint reader present in the device then.