Chrismurphy (talk | contribs) No edit summary |
Chrismurphy (talk | contribs) No edit summary |
||
Line 41: | Line 41: | ||
* `/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: | * `/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-*`; | # configure the test Fedora instances' dnf.conf such `exclude=kernel-*`; | ||
# consider deleting the "rescue" initramfs and kernel for the test instances, | # consider deleting the "rescue" initramfs and kernel for the test instances, and the "rescue" snippet in `/boot/loader/entries/`, and removing `dracut-config-rescue-056-1.fc36.x86_64` from them so these files aren't recreated. | ||
==How to delete the test instance== | ==How to delete the test instance== | ||
# Boot the menu entry for the instance you want to keep | # Boot the menu entry for the instance you want to keep |
Revision as of 01:45, 8 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/
mount point, e.g. $BTRFSPOOL = "/dev/nvme0n1p5" mount $BTRFSPOOL /mnt
; cd /mnt; ls -l- You should see two directories,
root
andhome
. These are Btrfs subvolumes, which we can snapshot. btrfs subvolume snapshot root root37
#any name will do
Create a bootloader entry using grubby
grubby --default-kernel
grubby --default-title
- Using the information above about your system, construct a command using this example:
grubby --add-kernel=/boot/vmlinuz-5.18.16-200.fc36.x86_64 --copy-default --title="Fedora Linux (5.18.16-200.fc36.x86_64) 36 (Workstation Edition) UPGRADE" --make-default
- There will be a message indicating an entry for this kernel exists and another is being created with
~custom
appended to the name. You can confirm the new drop-in file withls -l /boot/loader entries
. grubby --remove-args="rootflags=subvol=root" --update-kernel=/boot/vmlinuz-5.18.16-200.fc36.x86_64 --config-file=/boot/loader/entries/64db766697e04179a6d3f7a67c2941e1-5.18.16-200.fc36.x86_64.0~custom.conf
grubby --args="rootflags=subvol=root37" --update-kernel=/boot/vmlinuz-5.18.16-200.fc36.x86_64 --config-file=/boot/loader/entries/64db766697e04179a6d3f7a67c2941e1-5.18.16-200.fc36.x86_64.0~custom.conf
- Optional 1: After the system is upgraded, you can find this ~custom.conf file and delete it.
- Optional 2: You could choose to reveal the hidden GRUB menu, and edit the default entry, modifying
rootflags=subvol=root
to match the name you used for the snapshot, e.g.root37
. You'd do this twice: once to boot theroot37
snapshot to download the upgrade RPMs; and the following boot after that so it boots root37 thus initiating the offline upgrade.
Reboot
- If you used grubby, the
--make-default
option already made the "UPGRADE" menu entry the default so all you need to do is reboot. - If you didn't use grubby, use
grub2-set-default 64db766697e04179a6d3f7a67c2941e1-5.18.16-200.fc36.x86_64.0~custom
which happens to be the filename of the /boot/loader/entries you want to use without the*.conf
ending - Once you reboot, confirm
/
is actually using the snapshot you made:mount | grep btrfs
e.g.
/dev/vda3 on / type btrfs (rw,relatime,seclabel,compress=zstd:1,space_cache=v2,subvolid=257,subvol=/root)
you should see subvol=/root37
or whatever you named the snapshot. If you see root
as in this example, oops! You're still working on your original root, figure out what went wrong.
One bootloader
As each Fedora performs updates, it'll occasionally update the bootloaders on /boot/efi
. This shouldn't be a problem. But then there's sometimes bugs, so if you don't want to be testing Rawhide bootloaders, consider addingexclude=grub2-*
in the test instance's dnf.conf
. The time to do this is after the first boot into root37
snapshot, before starting upgrade download.
Initiate the system upgrade
Either of these, just like you normally would:
- https://fedoraproject.org/wiki/QA:Testcase_upgrade_dnf_current_workstation
- https://fedoraproject.org/wiki/QA:Testcase_upgrade_gnome-software_current_workstation
Switching between the two roots
- You'll need to reveal the GRUB hidden menu to make manual choices, OR
ls -l /boot
to see a list of kernels so you can complete the path based on which release version you want to boot, e.g.grubby --set-default=/boot/vmlinuz-5.18.15-200.fc36.x86_64
to boot Fedora 36grubby --set-default=/boot/vmlinuz-5.19.0-65.fc37.x86_64
to boot Fedora 37
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, and the "rescue" snippet in
/boot/loader/entries/
, and removingdracut-config-rescue-056-1.fc36.x86_64
from them so these files aren't recreated.
How to delete the test instance
- Boot the menu entry for the instance you want to keep
- Confirm you've booted it
mount | grep btrfs
does the subvolume name match what you want to keep? btrfs sub list -t /
##find the ID in the left column that matches the subvolume snapshot name you want to deletebtrfs sub del --subvolid $ID /
##Note that/
is the mountpoint for the file system, it's not going to delete your currently running root, it'll delete the ID you specify.