I recently installed Kinoite and I am trying to add my Windows install into Grub. What’s the proper way to edit Grub for an atomic distro?
Looking at my system it seems to misalign with the standard Fedora docs, for instance I don’t seem to have an /etc/default/grub.
Fedora Kinoite has limitations regarding dual booting. See Installing Fedora Kinoite :: Fedora Docs.
interesting, wish I read that before I installed 
I had dual boot working on this setup at one point with Silverblue 39. So it may have been the installer messing something up, or it may be something else. How can I confirm that I am using EFI boot?
Edit: From the docs, [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS confirms I am using UEFI.
Added atomic-desktops, silverblue
I spent an hour or so trying to fix this today. It’s difficult because different docs offer different course of actions and some don’t match the setup the atomic spins have. It’s frustrating and this may be the deal break for me and immutable desktops.
My understanding is that you can fix this manually but beyond that a lot of the suggestions I’ve found haven’t worked for me. os-prober returns no output so it’s not as simple as running that and regenerating the grub config.
Need a grub guru 
Added grub
Is there a reason you can’t use the UEFI boot menu to select the other OS?
I’ve been looking into what happened and my understanding is that Anaconda doesn’t play nice with the existing Windows EFI boot (or other OSes) and blows it away and makes it own.
Is there a reason you can’t use the UEFI boot menu to select the other OS?
No because I was partitioning one drive and now the only UEFI boot on it is the Bazzite (Kinoite) one.
This is known issue with Anaconda and it sounds like the reason things like os-prober and grub2-mkconfig weren’t adding Windows is because the Windows boot got wiped.
To answer my original question, the Atomic distros use the same process as standard Fedora to configure Grub. I was just thinking I was doing something wrong because of the aft-for mentioned issue.
Kindly know that Atomic spins F41 onwards use a pre-supplied static GRUB config, and use the UAPI Boot Loader Spec (BLS) for defining entries.
The static grub config sources the adjacent user.cfg file though, for things like timeouts etc…
Although /etc/default/grub and grub2-mkconfig (/etc/grub.d) are still supported, they overwrite the static config. This will not be supported.
I have tried grub2-mkconfig -o $(bootctl -x)/grub2/user.cfg, but this severely breaks the GRUB menu to a much worse condition, for some reason.
You need to handpick what you want, into user.cfg.
It is a lot of trial and error… sometimes unexpectedly you might need to insmod some module into GRUB (This is differnt from the insmod to load kernel modules; This is a GRUB built-in)
The UAPI Boot Loader Spec (BLS) specifies a simple declarative format for boot entries, to be same across bootloaders, therefore the entries created for GRUB will work out of the box with systemd-boot too…
systemd-boot has a cleaner and more basic theme on boot, (anyhow GRUB doesn’t support theming now), has a easier-to-edit configuration file for things like timeouts and all…
And it is better documented than GRUB… everything is detailed in the manpages… and I’m always here to help.
As for the dualboot thing, systemd-boot auto-detects windows without any complex os-prober configuration.
So, systemd-boot is the right bootloader for Atomic desktops…
If you don’t want to deviate from GRUB for whatever reason, DON’T USE os-prober.
DON’T USE grub2-mkconfig
DON’T USE /etc/default/grub or /etc/grub.d.\
Use the BLS config files, to chainload the windows bootmanager EFI executable.
Under $(bootctl -x)/loader/entries the BLS files exist. systemd-boot has it well documented, and you might like to ask here if you have doubts.
Personally I recommend to use systemd-boot (most probably included in the systemd package)
NOTE: $(bootctl -x) is mostly /boot, but don’t assume that if you have done an advanced install with different paths…
Only of the /boot partition is marked as XBOOTLDR. Otherwise it will refer to the ESP partition.
But it is marked as XBOOTLDR already…
The UAPI Boot Loader Spec requires that, and F41 onwards that is being followed (That’s how the static config works).
Only in recent new installs. Systems originally installed about five or more years ago that was not the case. And system upgrades don’t change that.
I don’t think a significant no. of systems are too old…
Huh! Then how do newer systems work with the “static” config? I think they just regenerate the GRUB config like before.
Upgrading the system doesn’t change the XBOOTLDR flag, and whatever it was set at when the system was originally installed is only changed if the user explicetely does that. Neither grub2 nor rpm-ostree cares about the XBOOTLDR flag.
The grub configuration for the ostree based system is done inside the ostree and/or rpm-ostree
Thanks for pointing out.
Users who are using a sufficiently old system that this can happen, kindly follow the steps (if you want) to follow new behaviour:
/boot partition./dev/sda and /dev/sda2 OR /dev/nvme0n1 and /dev/nvme0n1p2 (Note the final no. usually 2; It is the partition number)DEVICENAM=/dev/sdX PARTNUM=2sudo or run0 run parted ${DEVICENAM} printparted ${DEVICENAM} set ${PARTNUM} bls_boot on to set the flag.