My device is a ThinkPad C13 Yoga with the AMD Ryzen™ 5 3500C Processor (Morphius). It has a replaceable NVME drive which is one of the reasons I picked this model. ChromeOS worked without problems.
Flashing the Firmware worked without Problems.
I tried both Fedora and Ultramarine Linux but both ran into the same problem.
The live boot works flawlessly and the installation process also has no Problems.
But upon booting after installing it seems to have problems mounting the boot partition?
cros-ec-uart serial0—0: Timed out waiting for response.
cros-ec-uart serial0—0: missing EC transfer API, cannot send command
cros-ec-uart serial0—0: Canmt identify the EC: error —5
cros-ec-uart: probe of serial0—0 failed with error —5
platform GOOG0014:00: deferred probe pending
failed to mount boot-efi.mount - /boot/efi
I found this thread but even following those instructions it does not work and still is stuck with the same error messages.
It looks like you are having the same issue I am in the thread I posted earlier. Try powering off the laptop for a few hours and the powering it back on, this seems to resolve it for me (maybe this can be expedited by disconnecting the battery, waiting for the caps to drain and reconnecting, I haven’t tested this). The cause for it seems to be rebooting instead of power cycling the machine.
When you need to reboot the machine shutdown and press the power button to start the machine. This seems to resolve issues regarding the NVMe drive.
Blacklisting UART?
Coreboot expects fingerprint scanner to be present, some systems don’t have them. EC UART is used for FPMCU communication on AMD platforms, hence issues.
You also need to iommu=pt because of verstage. We’ve been told updated binaries should be available soon… but we’ve already been waiting for 2 years.
If the live media boots fine the error could probably be bypassed by simply commenting out the entry for /boot/efi in /etc/fstab. Not sure what would cause the error if the kernel can recognize the drive fine. Have you tried the debian netinstaller? I find its more robust and plays nice with weird bioses (as long as you copy /boot/efi/EFI/debian/grubx64.efi to /boot/efi/EFI/BOOT/bootx64.efi).
Kubuntu and EndeavourOS would not launch the installer at all. Opening the installer in the live boot of either did not start it or it opened and crashed immediately
All the other Linux have the mounting boot/efi problem. Or at least I’m very sure it is the same problem because they all have problems booting and refer to mounting problems in some way. Some just word is differently e.g. Pop! OS says something like “partition boot/efi might be corrupted and can’t be mounted”. But most print it out as seen in my post.
I have used a live boot and chroot to get into pop os and run the filesystem check but it reported no error. So I think Pop! OS is covering the real error message in an attempt to make it easier to understand but not every mounting problem is a result of corrupted filesystems.
I can try Debian too.
I just made my post based on Fedora because most seem to recommend it and actually have it running on the platform.
I don’t think the mounting of the boot/efi partition can just be disabled. Like is that not integral to booting the system?
No it is not integral. It is only needed to update grub and the kernel. If disabling in fstab lets you boot you can try to mount it (sudo mount /dev/nvme0n1p1 /boot/efi) and see what happens.
blacklisting cros-ec-uart is the solution but not blacklisting it in cmdline in /etc/default/grub (and then using grub2-mkconfig -o /boot/grub/grub.cfg to apply the changes)
The Blacklisting had to be done in the etc/modprobe.d/ directory. Just create a file in that directory that ends with .conf e.g. no_cros-ec-uart.conf and then put blacklist cros-ec-uart into the file.
then I used sudo dracut -f (or similar tools depending on the OS) to regenerate the initramfs and then reboot.
I don’t understand why but if it tries to load that module and fails it will not be able to mount the drive. So it has to be blacklisted this way.
it actually does not mount any partition. I disabled the boot/efi partition mounting and then the next partition failed to mount. But /boot/efi is usually the first which is where it fails. The Problem was the fingerprint module. When it fails to load that module it results in it not being able to mount any partition.
Got it. Btw, if anyone else has the grub bug it should be able to be bypassed by setting efi shell to be first in boot order and creating a file called startup.nsh on the root of the efi partition with contents like this (assuming FS1 corresponds to boot the root partition and the kernel and initrd are on / (mrchromebox uefi supports ext4 file systems)):
FS1:vmlinuz initrd=\initrd.img root=UUID=<figure out using blkid command> ro loglevel=3 quiet splash
(should work on default debian)
FS1:boot\vmlinuz initrd=\boot\initrd.img root=UUID=<figure out using blkid command> ro loglevel=3 quiet splash
I’m sure this is working for you, and it may be distro specific, but for me I did not have to do this. I have seen two ways of omitting something in grub: module.blacklist=yes and modprobe.blacklist=module, also https://forum.chrultrabook.com/t/lenovo-c13-yoga-nvme-disappears-on-reboot/1196/5?u=brisk.rain this post solves the problem in the same way you did but on pop os, and uses underscores. So I’ve been putting all 4 versions in my grub.conf, and it seems to be working fine on Fedora. So I have:
