From Fedora Project Wiki
(backup boot efi)
(one bootloader,new headers)
Line 1: Line 1:
{{QA/Test_Case
==Description==
|description= This test case creates a dual boot system with two Fedoras of different release versions, using btrfs snapshots, works as expected
This test case creates a dual boot system with two Fedoras of different release versions, using btrfs snapshots, works as expected
|setup=
==Setup==
# Install Fedora 36. Any desktop, using Automatic partitioning.
# Install Fedora 36. Any desktop, using Automatic partitioning.
# Freshen your backups, just in case
# Freshen your backups, just in case
Line 7: Line 7:
## cd /boot
## cd /boot
## sudo tar -acf bootefibackup.tar efi
## sudo tar -acf bootefibackup.tar efi
|actions=
==Actions==
# create a snapshot
# create a snapshot
# edit the dnfconf,  
# edit the dnfconf,  
# dup the most recent bls snippet, modify its `rootflags` entry to match the snapshot name
# dup the most recent bls snippet, modify its `rootflags` entry to match the snapshot name
#  
#  
|results=
==One bootloader==
# GRUB menu shows boot options: variant+version+kernelversion for switching between the two.
As each Fedora performs updates, it'll step on the bootloader in `/boot/efi`. It shouldn't be a problem unless there are bugs and then "wheee!" So you could consider adding an `exclude=grub2-*` in the test instance's `dnf.conf`.
# Can also use `grubby --set-default=/boot/vmlinuz-5.18.15-200.fc36.x86_64`
==How to boot==
# Limitations:
# GRUB menu shows boot options: variant+version+kernelversion for switching between the two; or
## /boot is only 1GiB by default, so this is the limiting factor right now, how many Fedoras you can have installed at one time. Two is safe. Three is iffy unless (a) configure the test Fedora instances' dnf.conf such that the kernel is excluded from updates; (b) consider deleting the "rescue" initramfs and kernel for the test instances, also removing `dracut-config-rescue-056-1.fc36.x86_64` from them so these files aren't recreated; or (c) put /boot on a Btrfs subvolume.
# Use `grubby --set-default=/boot/vmlinuz-5.18.15-200.fc36.x86_64`
}}
==Limitations=
## /boot is only 1GiB by default, so this is the limiting factor right now, how many Fedoras you can have installed at one time. Two is safe. Three is iffy unless (a) configure the test Fedora instances' dnf.conf such `exclude=kernel-*`; (b) consider deleting the "rescue" initramfs and kernel for the test instances, also removing `dracut-config-rescue-056-1.fc36.x86_64` from them so these files aren't recreated; or (c) put /boot on a Btrfs subvolume.

Revision as of 18:08, 6 August 2022

Description

This test case creates a dual boot system with two Fedoras of different release versions, using btrfs snapshots, works as expected

Setup

  1. Install Fedora 36. Any desktop, using Automatic partitioning.
  2. Freshen your backups, just in case
  3. Backup /boot/efi, just in case, e.g.
    1. cd /boot
    2. sudo tar -acf bootefibackup.tar efi

Actions

  1. create a snapshot
  2. edit the dnfconf,
  3. dup the most recent bls snippet, modify its rootflags entry to match the snapshot name

One bootloader

As each Fedora performs updates, it'll step on the bootloader in /boot/efi. It shouldn't be a problem unless there are bugs and then "wheee!" So you could consider adding an exclude=grub2-* in the test instance's dnf.conf.

How to boot

  1. GRUB menu shows boot options: variant+version+kernelversion for switching between the two; or
  2. Use grubby --set-default=/boot/vmlinuz-5.18.15-200.fc36.x86_64

=Limitations

    1. /boot is only 1GiB by default, so this is the limiting factor right now, how many Fedoras you can have installed at one time. Two is safe. Three is iffy unless (a) configure the test Fedora instances' dnf.conf such exclude=kernel-*; (b) consider deleting the "rescue" initramfs and kernel for the test instances, also removing dracut-config-rescue-056-1.fc36.x86_64 from them so these files aren't recreated; or (c) put /boot on a Btrfs subvolume.