Hi.
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):
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.
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).
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
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.
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.
