This is a variation on #638 which has yielded this test case https://fedoraproject.org/wiki/User:Sumantrom/Draft/preserve_home_data
Differences are in bold.
Step 0. Perform a Fedora 33 installation using Automatic partitioning (I used Workstation but any desktop should work because partitioning, subvolume layout, and bootloader stuff is all the same). Reboot and go through g-i-s.
/boot/efi
BIOS Boot
/boot
/home
/
root00
rootkde
rootjam
At step 8, the installer displays a warning banner at the bottom; if clicked,a dialog recommends that /boot be reformatted. This advice needs to be ignored.
Metadata Update from @sumantrom: - Issue assigned to sumantrom
Writing the test case,right now
Issues:
GRUB menu is hidden by default, kinda annoying. grub2-editenv - unset menu_auto_hide
grub2-editenv - unset menu_auto_hide
Bug: Something erases the previous /boot/loader/entries/ snippets. Workaround: edit the entry, find rootflags=subvol= and change it to the name of the root you want to boot. https://bugzilla.redhat.com/show_bug.cgi?id=1874724
https://fedoraproject.org/wiki/User:Sumantrom/Draft/dualboot_f33_btrfs
Issues: GRUB menu is hidden by default, kinda annoying. grub2-editenv - unset menu_auto_hide Bug: Something erases the previous /boot/loader/entries/ snippets. Workaround: edit the entry, find rootflags=subvol= and change it to the name of the root you want to boot. https://bugzilla.redhat.com/show_bug.cgi?id=1874724 I was able to reproduce the bug and have commented on the RHBZ
Bug: Something erases the previous /boot/loader/entries/ snippets. Workaround: edit the entry, find rootflags=subvol= and change it to the name of the root you want to boot. https://bugzilla.redhat.com/show_bug.cgi?id=1874724 I was able to reproduce the bug and have commented on the RHBZ
Metadata Update from @sumantrom: - Issue tagged with: test cases
Metadata Update from @sumantrom: - Issue set to the milestone: Fedora 33
@chrismurphy going by the bug state, it still looks new :) please let me know if I can somehow change the test case or if there is anything to discuss on this ticket?
the bug is still NEW. where are we with this?
Metadata Update from @adamwill: - Issue set to the milestone: None (was: Fedora 33)
It morphed into this https://fedoraproject.org/wiki/User:Chrismurphy/Draft/dualboot_teststation
I'm about to go through it now, I'll end up with a Fedora 39 and Fedora 40 dual boot system as a result.
OK that draft test case is tested and updated for F39->F40
Err, it needs a few minor tweeks but wiki won't update. I'll refresh it tomorrow and try to remember to report back here.
OK it's updated. This issue can probably be closed? If this seems useful to testers, and you want to move the draft somewhere more visible, I'll maintain it there.
that seems a bit. uh. fancy? :D
what I kinda envisioned for this ticket was a more 'straightforward' setup: run through a default fedora install, then run through another install and try to install alongside the first install (either resizing or on a different disk).
That's also possible. The gist is something like this:
/boot/loader/entries
No resize or different drive needed, the 2nd root coexists on the Btrfs file system along with the first. There practical limitation for the number of roots is the free space available on /boot.
Well, the case I was envisaging would be wanting to keep the installs more separate - not with shared /boot, possibly not with shared /home.
I think that would require separate EFI System partitions. Switching boot between the two OS's means using UEFI Boot Manager.
The $ESP/grub.cfg forwards to a specific $BOOT/grub2/grub.cfg, so if $BOOT is not shared, then $ESP also can't be shared.
$ESP/grub.cfg
$BOOT/grub2/grub.cfg
$BOOT
$ESP
Also, 1st default installation leaves no free space. The installer doesn't know how to resize Btrfs, so it'll require some fancy instructions to describe how to do that with CLI, so that there's free space to create $ESP2 and $BOOT2.
$ESP2
$BOOT2
Installer supports shared or not shared /home on Btrfs, equally easy.
I think having a second ESP is fine. It's definitely a better approach when installing to a second drive. When installing to the same drive, two ESPs might violate some UEFI guidelines, perhaps?
Originally, I wanted to suggest that a shared ESP can be achieved by renaming $ESP/EFI/fedora/ to $ESP/EFI/fedora1/ and re-creating the existing efibootmgr entry with the updated path. However, it seems that /boot/efi/EFI/fedora/* is owned by several grub2 subpackages, which means the content of the renamed location wouldn't get updated by future updates, and the original location would get overwritten (if belonging to the second installation) :disappointed: So this is no likely the right way.
$ESP/EFI/fedora/
$ESP/EFI/fedora1/
efibootmgr
/boot/efi/EFI/fedora/*
Log in to comment on this ticket.