I installed Fedora Kinoite on an ASUS P8‑Z77V Premium (circa 2012) and wanted to share a few observations that may be relevant to the Atomic Desktop roadmap.
Attempting to install a second Fedora Atomic/Kinoite system on the same disk consistently fails. Anaconda detects the existing OSTree deployment and incorrectly enters the GRUB2 multi‑boot path. It then attempts to run:
Code
grub2-mkconfig
against OSTree layouts, which is unsupported. This results in a fatal crash during the bootloader write stage. Partitioning itself is valid — the failure is purely in the bootloader path selection.
2. Installer UX note
The “custom” option that allows fixing the size of the root filesystem is extremely useful for reserving space for other OSes. It’s a bit hidden, but works well.
3. UKI concerns on older UEFI firmware
I initially explored whether I could manually enable UKI boot. After further reading, I now understand that Kinoite does not yet ship UKI‑first boot.
My long‑term concern is about hardware viability when Fedora transitions Atomic desktops to UKI‑only boot. Older Aptio UEFI implementations (like the P8‑Z77V) sometimes have limited or fragmented pre‑boot heap space. GRUB today loads a ~90 MB initramfs without issue, but that uses GRUB’s disk I/O, not the firmware’s LoadImage() path.
My question is whether the UKI rollout accounts for older firmware that may struggle to allocate a contiguous 60–90 MB PE image. I’m trying to understand whether boards of this era are expected to remain compatible.
4. Edge Flatpak performance
Microsoft Edge Flatpak on Kinoite shows noticeably slower start up compared to native Chromium or the RPM version.
Thanks for the heads on Bug #2263643. This centers on the hardware compatibility of older UEFI motherboards during the transition to Unified Kernel Images (UKIs). I may need to reconsider Fedora and make use of another distro so I am not distracted by a future regression in the making.
Currently, my hardware successfully processes the small EFI shim/GRUB footprint. However, the progression of this bug indicates a shift toward monolithic PE binaries that bundle the kernel and initrd. For older firmware with strict limits on PE binary sizes or limited memory allocation during the LoadImage() phase, a 100MB+ UKI represents a significant ‘blob size’ risk.
If Fedora moves to UKIs as the primary or sole boot method, there is a high probability that legacy UEFI hardware will become ‘bricked’ from a software perspective—not because the OS is incompatible, but because the firmware cannot physically execute a binary of that magnitude. I urge the team to maintain a ‘Small-Stub’ boot path to ensure Fedora remains the leading distribution for hardware longevity.
