From Fedora Project Wiki
No edit summary
No edit summary
Line 27: Line 27:
* 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
* 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.
* 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 `root37` or whatever you named the snapshot. If you see `root` as in this example, oops! You're still working on your original root.
`/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==
==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!" Therefore you could consider adding an `exclude=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.
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!" Therefore you could consider adding an `exclude=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.
==Reboot
==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 36
* `grubby --set-default=/boot/vmlinuz-5.19.0-65.fc37.x86_64` to boot Fedora 37
==Limitations==
==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
# `/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

Revision as of 23:29, 7 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.
  1. cd /boot
  2. sudo tar -acf bootefibackup.tar efi

Actions

Make snapshots

  1. Use the df command to find the /dev node+partition for your / mount point, e.g. $BTRFSPOOL = "/dev/nvme0n1p5"
  2. mount $BTRFSPOOL /mnt; cd /mnt; ls -l
  3. You should see two directories, root and home. These are Btrfs subvolumes, which we can snapshot.
  4. btrfs subvolume snapshot root root37 #any name will do

Create a bootloader entry using grubby

  1. grubby --default-kernel
  2. grubby --default-title
  3. Using the information above about your system, construct a command using the example below:

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

  1. 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 with ls -l /boot/loader entries.
  2. 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
  3. 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 the root37 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 step on the bootloader in /boot/efi. It shouldn't be a problem unless there are bugs and then "wheee!" Therefore you could consider adding an exclude=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:

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 36
  • grubby --set-default=/boot/vmlinuz-5.19.0-65.fc37.x86_64 to boot Fedora 37

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
    1. configure the test Fedora instances' dnf.conf such exclude=kernel-*;
    2. 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
    3. put /boot on a Btrfs subvolume.