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?!?
Just writing to ask if you went through with the install? What method did you end up using? Did it work for all your needs?
I would like to do the same thing myself: set up one Workstation install for work (zoom calls; patient management etc) and one KDE for play (both will only have apps that look and feel like their parent DEs; CSD based apps for GNOME and broadly, Qt apps and such for KDE… )
My plan A atm was to use two /boot/EFIs two /boot partitions and then individual root and home. My Plan B was to create a second account on the Workstation install and set up KDE completely there (no idea how I’d do that without what’s already set up interfering…
I’m hoping to use your expertise here, please get back to me.
If planning to install two different fedora instances on a single machine with dual boot I suspect the easiest way may be to do a custom partitioning and create a separate efi partition for each, then use the bios boot menu to select the one desired to boot.
This would allow one to be the default boot and easily access the other without the issue of one conflicting with the other when updates are done and would avoid having the conflict caused by attempting to share an efi partition (since that would not work easily as it also would almost force a shared /boot partition).
Thanks for replying!
I was going to set up a different /boot partition for each install, but I think, just to be safe, I’ll set up a separate efi one too…
Do the efi partitions need to be the first and second ones on the drive, or can I get away with using partitions 1 and 5, for instance?
And when I do a third install on my SSD (not a Fedora distro), do I use a distinct efi partition again or can I reuse my original Workstation efi (mount, not format during install, yes)? And do I need to chainload the EFI partitions?
If you use different /boot partitions then it woule seem you must use separate /boot/efi partitions for each. Fedora uses /boot/efi/EFI/fedora/grub.cfg to redirect grub during boot so it reads the /boot/grub2/grub.cfg for booting. Using only one efi partition seems like it would limit one to only one /boot partition.
One should be able to do a custom menu entry in the main grub config so they could boot the other installation.
It would seem much easier to install one on the host bare metal and the other in a VM since that would avoid potential problems in booting, upgrades, etc.
Non-fedora installs may also conflict with booting and again would be best handled with either a VM or using the bios boot menu to select the one to be booted (and have separate efi and boot partitions).
Multi-booting with linux where each installation uses grub to boot quickly becomes a nightmare since the last one to see a grub upgrade commonly takes control of the boot entry in bios and may block access to other installations.
