Fedora fails to start. Failed to mount boot-efi. Morphius


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.

This is how my modified grub looks:

I opened the ThinkPad to look inside and the NVME drive looks normal. I reseated it too.

Before flashing the firmware and installing Fedora the device had no problems with the drive.

I even tried partitioning a major section of the drive and only using the leftover space to install Fedora.

Is the cros-ec-uart problem related to the mounting problem?

Any ideas on what might fix this?

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.

I never use reboot, hell I was not even in the OS yet after installing it.

I have to kill it by holding the power button until it shuts down because it is stuck in the boot process.

It was off now for over an hour and does not boot

I have removed the battery and discharged everythingby holding the power button for 30 seconds.

After reinstalling still the same problem on boot

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

I already put them into grub as you can see in my last photo. If I didn’t write something wrongly

I tried

  • Pop! OS
  • openSUSE
  • Fedora
  • Ultramarin Linux
  • Manjaro
  • EndeavourOS
  • Ubuntu
  • Kubuntu

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?

lol debian install does not work

same issues as described here: https://youtu.be/z6oyqrrXTLM?si=3qlNpyRUc_8udj1N&t=942

any option in the grub install menu results in a reboot.

apparently a grub error. The newer grub 2.12 of the testing branch works.

So not going to bother with that.

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.

I found the solution.

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.

See my comment above for the solution.

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

(if rootfs and kernel are in /boot)

FS1:@rootfs\vmlinuz initrd=\@rootfs\initrd.img root=UUID=<my uuid> rootflags=subvol=@rootfs ro loglevel=3 quiet splash

(works on my system with a btrfs root)

or something along those lines

then type startup and press enter in the efi shell prompt

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:

cros-ec-uart.blacklist=yes modprobe.blacklist=cros-ec-uart cros_ec_uart.blacklist=yes modprobe.blacklist=cros_ec_uart iommu=pt

3 of those may well be unnecessary, but I’m not going to figure out which until it stops working.