From Fedora Project Wiki
Chrismurphy (talk | contribs) mNo edit summary |
Chrismurphy (talk | contribs) No edit summary |
||
Line 2: | Line 2: | ||
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. | |||
* Freshen your backups, just in case | |||
* Backup `/boot/efi`, just in case, e.g. | |||
## cd /boot | ## cd /boot | ||
## sudo tar -acf bootefibackup.tar efi | ## sudo tar -acf bootefibackup.tar efi | ||
==Actions== | ==Actions== | ||
# | ====Make snapshots==== | ||
# | # Use the `df` command to find the `/dev` node/partition for your `/` volume | ||
# | # Run `mount /dev/nvme0n1p5 /mnt`; cd /mnt; ls -l | ||
# | # You should see two directories, `root` and `home`. These are Btrfs subvolumes, and we can snapshot them; e.g | ||
# `btrfs subvolume snapshot root root37` #any name will do | |||
# Optional: `btrfs sub snap -r home home.20220806` #creates a read-only snapshot of home, should things go really sour for some reason, you can copy over files or configurations from the read-only snapshot back into `home` on a case by case basis | |||
# Optional: You can modify files in the snapshot `nano /mnt/root37/etc/dnf/dnf.conf` before rebooting. See below "One bootloader" and "Limitations" sections for some reasons you might modify dnf.conf. | |||
====Create a bootloader entry==== | |||
# `ls -l /boot/loader/entries` | |||
# Dup the most recent snippet, e.g. `cp /boot/loader/entries/799c3cd1115b414cbe5c030fc6dc0d16-5.18.15-200.fc36.x86_64.conf /boot/loader/entries/799c3cd1115b414cbe5c030fc6dc0d16-5.18.15-200.fc36.x86_64-UPGRADE.conf` | |||
# Edit the copy `nano boot/loader/entries/799c3cd1115b414cbe5c030fc6dc0d16-5.18.15-200.fc36.x86_64-UPGRADE.conf` | |||
## `title` line, add any distinctive word anywhere in this line such as "UPGRADE" or "SNAPSHOT" | |||
## `options` line, find `rootflags=subvol=root` and change it to match your snapshot name `rootflags=subvol=root37` | |||
## save and exit | |||
# Optional: Instead of creating a snippet file, you can show the GRUB menu on reboot, and modify the entry manually. You'll do this twice: once to boot the snapshot to do `system-upgrade download`; and then again immediate following `system-upgrade reboot` | |||
==One bootloader== | ==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`. | 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`. |
Revision as of 18:38, 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
- Install Fedora 36. Any desktop, using Automatic partitioning.
- Freshen your backups, just in case
- Backup
/boot/efi
, just in case, e.g.
- cd /boot
- sudo tar -acf bootefibackup.tar efi
Actions
Make snapshots
- Use the
df
command to find the/dev
node/partition for your/
volume - Run
mount /dev/nvme0n1p5 /mnt
; cd /mnt; ls -l - You should see two directories,
root
andhome
. These are Btrfs subvolumes, and we can snapshot them; e.g btrfs subvolume snapshot root root37
#any name will do- Optional:
btrfs sub snap -r home home.20220806
#creates a read-only snapshot of home, should things go really sour for some reason, you can copy over files or configurations from the read-only snapshot back intohome
on a case by case basis - Optional: You can modify files in the snapshot
nano /mnt/root37/etc/dnf/dnf.conf
before rebooting. See below "One bootloader" and "Limitations" sections for some reasons you might modify dnf.conf.
Create a bootloader entry
ls -l /boot/loader/entries
- Dup the most recent snippet, e.g.
cp /boot/loader/entries/799c3cd1115b414cbe5c030fc6dc0d16-5.18.15-200.fc36.x86_64.conf /boot/loader/entries/799c3cd1115b414cbe5c030fc6dc0d16-5.18.15-200.fc36.x86_64-UPGRADE.conf
- Edit the copy
nano boot/loader/entries/799c3cd1115b414cbe5c030fc6dc0d16-5.18.15-200.fc36.x86_64-UPGRADE.conf
title
line, add any distinctive word anywhere in this line such as "UPGRADE" or "SNAPSHOT"options
line, findrootflags=subvol=root
and change it to match your snapshot namerootflags=subvol=root37
- save and exit
- Optional: Instead of creating a snippet file, you can show the GRUB menu on reboot, and modify the entry manually. You'll do this twice: once to boot the snapshot to do
system-upgrade download
; and then again immediate followingsystem-upgrade reboot
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
- GRUB menu shows boot options: variant+version+kernelversion for switching between the two; or
- 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- configure the test Fedora instances' dnf.conf such
exclude=kernel-*
; - 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 - put /boot on a Btrfs subvolume.
- configure the test Fedora instances' dnf.conf such