fedora-qa

Clone
Source Code
GIT

#640 new test case: dual boot two Fedora 33's
Opened 3 years ago by chrismurphy. Modified 2 months ago

Open
Close issue as:
Worksforme Fixed Wontfix Duplicate Invalid

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.

  1. Boot the second Fedora 33 installer, make sensible choices
  2. In Installation Destination, click Custom under Storage Configuration
  3. Locate the previous Fedora installation, click on it to reveal existing mount points for reuse
  4. Select /boot/efi or BIOS Boot mount point, on the right hand side at the top, find ''Mount Point'' field, type in /boot/efi, click ''Update Settings'' button.
  5. Select /boot mount point, on the right hand side at the top, find ''Mount Point'' field, type in /boot, do NOT check the ''Reformat'' box, click ''Update Settings'' button.
  6. Select /home mount point, on the right hand side at the top, find ''Mount Point'' field, type in /home, click ''Update Settings'' button.
  7. Click + button to create a new / mount point (this is required to be a new subvolume, reformat will be checked, cannot be uncheck but the underlying Btrfs is not reformatted, optionally change the name of the subvolume from root00 to rootkde or rootjam or whatever it is). Click ''Update Settings'' button.
  8. Click Done
  9. Perform the installation and reboot the machine
  10. After logging in, check that your home directory or /home contains the files you created on your previous system (check their contents as well)
    Note: If you don't delete the previous root subvolume, the installer will create a new subvolume root00 mounted at /. If you delete the previous root subvolume first, the installer will use the same root name for the new one. Both approaches are valid, you can use whichever approach you choose. Other than consuming space, there is no disadvantage to keeping the old root. striking it, because we want to keep the old root

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.
Edited 3 years ago by chrismurphy

Metadata Update from @sumantrom:
- Issue assigned to sumantrom
3 years ago

Writing the test case,right now

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
Edited 3 years ago by chrismurphy

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

Metadata Update from @sumantrom:
- Issue tagged with: test cases
3 years ago

Metadata Update from @sumantrom:
- Issue set to the milestone: Fedora 33
3 years ago

@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)
2 months ago

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.
Edited 2 months ago by chrismurphy

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:

  1. Launch the installer and perform a default clean install to a drive.
  2. Reboot into that installation (add a first user if necessary, make sure it works).
  3. Backup the files in /boot/loader/entries
  4. Launch another Fedora desktop installer (any version), choose the same drive as destination, and use custom partitioning. Ensure the partition scheme pop-up is set to Btrfs.
  5. Create a new / mountpoint, clicking on the + button on the lower left UI, specify / as the mount point, and leave the capacity field empty
  6. Assign existing subvolumes/partitions to mountpoints /home /boot and /boot/efi respectively. (NOTE for BIOSBOOT systems).
  7. Install
  8. Reboot into the 2nd installation. Locate and restore the backup BLS snippets created in step 3, to /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.
Edited 2 months ago by chrismurphy

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.

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.

Installer supports shared or not shared /home on Btrfs, equally easy.
Edited 2 months ago by chrismurphy

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.

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.

Login to comment on this ticket.

Metadata

test cases

None
None
normal
None
Powered by Pagure 5.13.3
Documentation • File an Issue • About • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.