I’m planning to dual-boot two Fedora editions (the official workstation version and the KDE version), I know that they are the same but I just want two partitions, one for work and one for leisure, but my SSD has a limit on how many partitions can it have, so I have to share both /boot and /boot/efi. However, I’m concerned about potential kernel overwriting when updating it in either installation.
Both Fedora installs use DNF for package management, which is going to update the kernel and other system files in place. This makes me worry that updates from one installation might overwrite the kernel files of the other, causing boot problems.
My questions are: Is it safe to share /boot and /boot/efi partitions between two “identical” Fedora’s? Will kernel updates from either will cause any overwriting issue?
There’s any risk at all or I’m just overthinking? If there’s a big chance of something breaking what should I do to prevent it? Are there any recommended practices?
First, I do not understand how your ssd is limited in partitions. GPT allows 256 partitions per device.
Even the older msdos partition table limited the primary partitions but allowed a lot of logical partitions in the extended partition area.
I think the issue you will run into is that both versions will use /boot/efi/EFI/fedora as the main efi partition and thus will overwrite each other on the initial install.
Then the /boot partition will be competing for space, and the initramfs files and /boot/loader entries will also compete. Kernel updates will overwrite /boot/grub2/grub.cfg .
This may or may not be an issue if both versions keep their own kernel files, but I would expect conflicts.
Personally, I think it would be much easier to use a separate /boot/efi and especially /boot partition for each fedora spin you install.
On second thought, the way grub works would require that either both /boot & /boot/efi be shared, or that neither be shared.
That’s weird then, because I tried using the Arch ISO to partition my SSD and check what was going on, but even when using cfdisk, I couldn’t create more than five partitions.
Just to be clear, my SSD already has five partitions, from /dev/sdx1 to /dev/sdx5, with two for /boot and /boot/efi, another two for my current Fedora installation (I’m not sure why it uses two, but it always shows sdx5 as a branch of sdx4) and one with the borked install. I’m able to create a new partition (sdx1 in this case), but I can’t create any more than that; it simply gives me an error message."
The SSD is a external one, I don’t know if that has any effect.
About half a year ago there was one very unhappy Fedora user who tried to do that and found that he could only boot the last installed Fedora and the first installed became unavailable. In this particular case the /boot was not shared; but when booting, grub would only select to use one of the /boot file systems and there was no option to select the other.
If you really want to dual boot two Fedora systems, it is safest to do that using two disk units, and keep each Fedora system strictly to one disk unit, including separate /boot and /boot/efi file systems. You should then be able to select the version at the Firmware level – same way as when you select to boot the live system.
It seems that’s the way. It also seems that if I don’t find a solution for this 5 partition limit, I’ll be stuck with just one OS on the SSD, even though it’s 1 TB
I am pretty confident that you do not need two disks. Disclaimer: not tested in production, so recommended knowledge: revival (not reinstallation) of an installation in chroot environment from another install or live system.
Kernel and initramfs are desktop agnostic, it is the root parameter (and subvol when needed) in grub which determines the installation to be started. But basic grub will see one kernel, and take it for itself and the other installation is invisible. With “GRUB_ENABLE_BLSCFG=true” and different /etc/machine-id, grub menu is no longer in grub.cfg, but from files labelled with machineid, so in that case shared boot should work. But you have to update both installs regularly, otherwise the frequently updated install will delete the kernels from the less updated one.
But why do you use a boot partition? Grub can boot from a boot folder in the root partition. If you install the second install with a boot folder on the second partition, and do NOT install grub into the ESP, grubby or grub2-mkconfig of the first installation will find the second one. In that case, better have “GRUB_ENABLE_BLSCFG=false” in the second install to aid grub-mkconfig of the first install. And after each update of the second install you have to update grub of the first one in order to update the boot menu.
Another solution is switch to systemd-boot, which is designed to have all kernels identified by machineid in the EFI partition, but you need space in EFI, (or add /boot to EFI partition), and is not easy to implement afterwards, you should exactly know the file structure to be sure that everything is in place.
What I like most is to disable grub’s OS-prober, and add a custom menu in /etc/grub.d/40-custom, which sources the grub.cfg of the other installations. In that way, pressing e.g. “debian” gives me the native debian grub menu and everything updates without intervention.
Of course this is true, since long time you can select the desired desktop environment on the login screen. Adding a desktop environment is as simple as “dnf groupinstall…”
But the o.p. wanted to have a system for work and a system for leisure, and this is an argument for two installations to prevent messing up the system used for work.
I think Systemd-homed is the answer then, still same single system, different homes.
But yeah, as for dual-boot not working, I haven’t tried it in some time but it used to work with Fedora + another 'Nix Distro or Windows.
swithcing to systemd-boot will avoid overwriting kernels in /boot
use separate EFI partitions for each OS - and use UEFI boot menu to choose which to boot, if “grub” do not list all available OSes.
After installation of each Fedora, rename /boot/EFI/Fedora to /boot/EFI/FEdora.1, etc. Just a few changes required. So next Fedora installation will use /boot/EFI/Fedora without issues.
(To mix Silverblue and Fedora, install Silverblue first.)
Grub still give errors if /boot is in a btrfs partition, although usually it still can boot.
“well documented” for me would mean that there is a guide (in Fedora Docs for example) on how to setup/migrate systemd-homed.
Users that ask a question here are normally not satisfied with a manpage.
Sure, I see your POV, mine would be to consider the manpages as well documented and the user guide as the explicit detailed instructions on how to use it, with examples. Tomaytoes/Tomattoes?!?
