Hi everyone. I just installed the UEFI firmware for OMNIGUL thanks to Mr Chromebox who added support for it in less than 24h from the moment I’ve spoken to him about it (here and here), besides solving a mount issue that this particular board happened to be affected by.
I was able to live boot Manjaro KDE 23.1.3 and proceed with the installation to completion, yet when the system was rebooted, the bootloader failed to recognize the EFI partition: Booting from 'Manjaro' failed: verify it contains a 64-bit UEFI OS
The ISO was run twice: through Ventoy and flashed using dd, and the default partitions were removed.
Do you think that the OS is to blame (maybe bad mount flags when doing the partitioning), or is there something else that can be addressed from the advanced boot options?
Update: Removed reference to error message since it was actually related to the unmounting of the Manjaro Live USB session.
Have you tried Arch using the archinstall script built in to the ISO? Or EndeavourOS? In my experience, Manjaro has been less stable than straight Arch.
Went with EndeavourOS and got the same outcome. It’s clear that this isn’t OS-specific since the bootloader is failing to recognize any boot partition.
Tried, but there wasn’t any option to choose from in Boot Manager → Boot From File. The bootloader is seeing the EFI partition of Manjaro but it’s seemingly unable to properly read it. From the boot menu, its path reads: \EFI\Manjaro\grubx64.efi.
You can use the same workaround as for eMMC not working on EDKII on Picasso/Dali - put the partitions /boot and /boot/efi on a separate drive, like a USB or SD card.
Thanks, but having to reserve 1 of 3 USB ports just for booting purposes (no SD card slots on this device) isn’t a workable solution for me.
Hopefully, the serial log from the SuzyQ cable can help resolve the issue, though I have to wait 3-4 more weeks to know that, which is the time it will take for the SuzyQ to arrive.
Could you please tell me why booting from a USB won’t serve you as a temporary (until edk2 hopefully supports UFS media, if I understood correctly the GitHub conversation) solution?
My line of reasoning is the following:
if your use case is a static one that involves having the USB ports plugged constantly (say charger, external storage, display via USB-C DisplayPort) then adding a USB hub / docking station should not be of much inconvenience
on the other hand, if you travel with the Chromebook, then I assume that the USB ports are “normally” free and used only when you need them. In this case, why wouldn’t keeping a low profile USB drive plugged in constantly for booting and unplugging it (the system is up, so EFI is no longer needed, right?) only when the port is sometimes needed and putting back in after finishing work, be a viable solution?
I’m waiting on CB515-2H to arrive. I could still cancel the order though, so I will highly appreciate your insights to what I might be missing about the USB drive boot workaround.
I wrote that comment partly out of frustration at being unable to make the machine fully functional after two days of debugging. Alas, I think it’s a great machine that’s worth buying, even with the current lack of support for booting from internal storage.
The original suggestion was to boot from a USB flash drive (or SD card, which is technically possible but you’d need a USB card reader for that). I disagreed because of two reasons: performance and portability.
Internally, this chromebook comes with a UFS 3.1 flash drive (SDINFDO4-128G) having a maximum reported sequential write speed of 1550MB/s, far higher than the theoretical limit of the USB 3.2 Gen 1 Type-A port (625Mb/s) but comparable to that of the two USB-C ports (1250MB/s). Thus, the most sensible option would be to use an NVMe over USB-C (by purchasing a good-quality USB-C to M.2 NVMe enclosure) for decent W/R performance.
For a static setup, you’re right; having external storage set up as just described, plugged in at all times, won’t be an issue. However, as someone who travels a lot with his laptop, it’s impractical to have a dongle attached to a peripheral at all times. I’m not sure whether it’s possible in UEFI to boot Linux from a USB then unplug it after it switches to the root partition on UFS, but I stand to be corrected. If that were the case, then I’d surely reconsider.
I know I’m a bit off topic, but I’ll take advantage of already responding (to thank) to just hint you that “the Internet” seems to agree that /boot is not necessary after already having booted to the OS (except of course for updating anything on /boot like kernel or GRUB) here and also here (though the question was phrased differently). I’m no expert, but it is also consistent with my understanding of how the start up process goes. Unfortunately, I can’t test / take the risk of having to rescue-live boot my main workstation at the moment.
As for the drive speed — do you think this would be noticeable? Kernel, initramfs and other /boot / /boot/efi stuff does not seem to exceed 100M on my workstation (I’ve excluded backup / rescue files). It will get loaded “x times” faster but that would only be a couple of milliseconds, wouldn’t it? I think my reflexes are not swift enough to notice.
Nonetheless, I’m keeping my fingers crossed and hopeful for native support.
Thank you for the included references. I was hesitant to confirm whether the unmounting of /boot would also work for UEFI systems but, evidently, it’s possible. With this kind of setup, you shouldn’t worry about performance since what’s ultimately important is where / is, which would be on the internal storage.
I think the only risk with this kind of setup are kernel updates, which as a Manjaro user myself, are quite frequent – you just have to remember to mount the USB back in.