Have you searched the community for related issues?
[ x] No similar issues found.
Please describe the problem you’ve encountered in detail:
I created an install USB which successfully worked on an old system76 laptop. Brilliant. Using the same device on a newish Asus S13, I get a blank screen for a few seconds and then the boot process restarts (from the beginning).
I have installed on that machine currently PopOS and it runs like a champ. Secure boot is turned off. I tried with a second USB, same thing. (Note that the first one was a USB-C fairly large USB. The second one was an old USB-A that comes in at 7.8 G.).
I tried hacking this by creating a bootable USB and copying the bin directly, then trying to mount it and boot into it. Unfortunately the kernel for FydeOS doesn’t seem to have EFI stubs and it didn’t work. So that was probably a dead-end.
Any ideas?
System & Device Information
ASUS Zenbook UX305CA
Hardware & System Configuration:
Processor: Intel Core m3-6Y30
Graphics Card(Please specify if there’s a discrete graphics card):
I misquoted the processor. The original S13 came out with the one originally mentioned. This is a quite new machine. My bad for trusting a google search and not verifying. Using lscpu it’s actually an Intel Core Ultra 7 155U.
The machine meets the boot requirements as documented. The Ultra processor line is specifically called out as being supported in the documentation for choosing the right variant. Notice that it has Meteor Lake which is the 155H processor as being supported by the Modern variant. The 155U is not called out explicitly (which I believe is Arrow Lake) but it is extremely close to the 155H. It’s hard to imagine that that minuscule difference in the number of cores and frequencies would cause the machine not to boot.
When you say “Ultra is not supported” what specifically do you mean and what about it is not supported?
Ok, thanks for the tip. They are officially supported it looks like, but there seems to be some bugginess in that support. Seems like the Meteor Lake processors (and therefore Arrow Lake as well) all have the same issues.
I might have a shot at trying to build the kernel and replacing it in the image with one that has EFI handover enabled. I suspect if I can get past the initial boot process I might be able to get it to work. I’ll post back if I am able to make some progress.
I hacked my way through this over the course of a few days and I know what is happening. Following is a description intended to make it easier for the Fyde OS developers to create a fix if they decide to do so.
Bug report ==>
FydeOS installer fails to boot on ASUS UEFI (black screen → immediate reboot)
Hardware: ASUS laptop (UEFI mode).
Comparison: Same installer USB boots fine on an older System76 laptop.
What happens
Selecting the FydeOS USB on the ASUS shows a black screen for ~1–2 seconds, then the firmware restarts the boot process (loop).
No splash, no GRUB menu, no errors on screen.
What works (control experiment)
If I replace the installer’s \EFI\BOOT\BOOTX64.EFI with systemd-boot and put a minimal loader entry that boots the kernel directly (EFI-stub) from ROOT-A, the same ASUS boots the installer successfully.
So the kernel, partitions, and filesystem are fine ; the failure is strictly in the EFI bootloader stage .
Likely root cause (GRUB ↔ ASUS GOP init)
The installer’s BOOTX64.EFI appears to be a GRUB-based EFI shim that initializes gfxterm via efi_gop/efi_uga.
On this ASUS firmware, that GRUB image fails during graphics/console init (no usable GOP mode or mode-switch issue), resulting in a blank screen and firmware watchdog reboot before any menu is rendered.
Because swapping to systemd-boot (which uses simple UEFI LoadImage/StartImage with a text console) fixes it, the problem is very likely GRUB’s video path on this firmware, not media layout or the kernel.
Note: ESP size/layout does not cause this black-screen-reset. (I also tested with a larger ESP; behavior unchanged until GRUB was replaced.)
Repro steps (what you can try to validate)
Use the standard FydeOS installer USB on an ASUS UEFI laptop with Secure Boot off.
Observe: black screen → reboot loop.
Replace \EFI\BOOT\BOOTX64.EFI on the USB with systemd-bootx64.efi, and copy the installer kernel to \vmlinuz (and \initramfs.img if available) add:
\loader\loader.conf -> default fydeos
\loader\entries\fydeos.conf:
title FydeOS (installer)
linux \vmlinuz
initrd \initramfs.img (if present)
options root=<UUID|PARTUUID of ROOT-A> rw rootwait cros_debug loglevel=7
Observe: ASUS now boots the installer → confirms the GRUB image is the incompatibility.
What would fix this in the official installer
Any one of these would make ASUS-class firmware happy:
Ship a “text-only” GRUB EFI as the default BOOTX64.EFI
Build GRUB without gfxterm (or set GRUB_TERMINAL_OUTPUT=console), avoid forcing GOP mode switches.
Include only the minimal modules needed (part_gpt, fat, ext2, normal, configfile, search*, linux, test, echo).
Ensure fallback to plain console if GOP init fails.
Ship a systemd-boot (or direct EFI-stub kernel) path as default/fallback
For the installer USB, place a kernel + (optional) initramfs on the ESP and a loader/entries/*.conf.
This bypasses GRUB entirely on firmware that’s sensitive to gfxterm/GOP.
Offer a boot-option switch (“Text mode bootloader”)
Let users toggle between the current GRUB build and a text-only/systemd-boot path if GOP init fails.
Why this matters
Some OEM UEFI implementations (ASUS being common) are picky with GRUB’s graphics initialization.
A plain UEFI text path (systemd-boot or text-mode GRUB) dramatically improves compatibility without touching the ChromeOS-style A/B layout or kernel.
Additional notes
If a person wants to make this work in the meantime, see this script which can modify a FydeOS install so that it will boot with systemd-boot. Note that this is for testing purposes only. Not responsible for any unexpected outcomes or undesirable consequences. Always review a script before running it.
To use the script:
Create an install USB
Also create a Linux distro that can be booted from a separate USB. Copy the fix script to it.
Run the fix script against the Fyde OS installer USB.
Boot from the USB and install FydeOS
Reboot after installation into the bootable Linux distro.
Run the fix script against the installed Fyde OS drive.
Note that major updates to Fyde OS (anything that would cause a switch between A / B partitions) would require re-running the fix script.
This is for testing purposes only!
Having said that, I am quite happy to say my Asus now runs FydeOS, with caveats.
So, definitely some instability here. Activating Android borks the system, and it won’t wake up from sleep correctly. I’m continuing my hacking journey. I’ll post back with updates and progress (including scripts) will be here
If any of the developers wants to chat or wants me to test a build, happy to do so.
This worked for me on FydeoS 20 on my usb, but then trying to do it from my Linux Distro to the Fydeos install on my internall NVME, it cays it cannot find the efi partition, not matter if I select the EFI or FydeOS Partition, or the NVME drive itself. Is there something I’m missing?
I also still tried booting the install and it says the kernel is missing, this would be related correct?
Yep, it’s set to UEFI and Secure Boot is off. But since it can’t find the systemd EFI partition from my bootable USB Linux distro, it won’t boot correct?
You basically have to do the same trick after booting. I have a script that will hack the installed boot to use systemd-boot. But in my case anyway, there was a lot of instability. It seems that the kernel was not new enough in FydeOS for my hardware.
But basically there were two steps:
Run fix-fyde-os-install.sh on the usb installer in order to get it to install.
After installation, boot from a bootable Linux USB and run fix-fyde-os-install.sh again on the installed OS.
In my case, I had it booting fine, but
Battery life was reaaaaally bad… clearly power optimization was not there.
I had to hand hack things to make OS partition writable in order to install Android support
After installing Android support, the system would crash a few seconds after logging, presumably because the Android subsystem was starting and it bork.
I tried building the Chrome OS kernel latest and using it in the Fyde OS installed os, but I could not get a build that would actually boot. I tried every whicih way but no dice. I think if we had an updated kernel the systemd-boot method might work.
A shame, because I really wanted to run it directly on this machine.
Hey @toochevere Thank you again for your efforts. I can run FydeOS as on my Huawei Matebook with Ultra 155h processor. Regarding the problem of not waking up from sleep, the hwtuner trick mentioned in this post helped me solving it: https://fydeos.io/help/knowledge-base/developer-options/hardware-configuration/power-management-settings/ I also made a clean install of FydeOS v21.0 and confirm that your systemd-boot fix still works fine. I didn’t test activating the Android yet.
Question Description
System & Device Information