User:Chrismurphy/Draft/dualboot teststation: Difference between revisions

Revision as of 23:08, 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.

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 and home. 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 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

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.
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: The gist is to dup the most recent /boot/loader/entries snippet, giving it a $NEWFILENAME, edit it and give it a new title, e.g. add "UPGRADE" to the end, and change the options line rootflags=subvol=root to whatever name you used for the snapshot, e.g. root37. So you can either do it CLI style or use grubby; or
Optional 2: You could even just reveal the hidden GRUB menu at boot time, and manually edit the default entry. You only need to do it twice. One boot to boot the snapshot and initiate the upgrade download. And the next boot to actually run the (offline) upgrade. The upgrade will install a new kernel package and its BLS snippet will contain the proper reference to root37 as the root subvolume to use (or whatever name you used).

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
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.

@@ Line 5: / Line 5: @@
 * 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==
 ====Make snapshots====
-# Use the `df` command to find the `/dev` node/partition for your `/` volume
+# Use the `df` command to find the `/dev` node+partition for your `/` mount point, e.g. $BTRFSPOOL = "/dev/nvme0n1p5"
-# Run `mount /dev/nvme0n1p5 /mnt`; cd /mnt; ls -l
+# `mount $BTRFSPOOL /mnt`; cd /mnt; ls -l
-# You should see two directories, `root` and `home`. These are Btrfs subvolumes, and we can snapshot them; e.g
+# You should see two directories, `root` and `home`. These are Btrfs subvolumes, which we can snapshot.
 # `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
+====Create a bootloader entry using grubby====
-# 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.
+# `grubby --default-kernel`
-====Create a bootloader entry====
+# `grubby --default-title`
-# `ls -l /boot/loader/entries`
+# Using the information above about your system, construct a command using the example below:
-# 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`
+`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`
-# Edit the copy `nano boot/loader/entries/799c3cd1115b414cbe5c030fc6dc0d16-5.18.15-200.fc36.x86_64-UPGRADE.conf`
+# 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`.
-## `title` line, add any distinctive word anywhere in this line such as "UPGRADE" or "SNAPSHOT"
+# `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`
-## `options` line, find `rootflags=subvol=root` and change it to match your snapshot name `rootflags=subvol=root37`
+# `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`
-## save and exit
+* Optional 1: The gist is to dup the most recent `/boot/loader/entries` snippet, giving it a $NEWFILENAME, edit it and give it a new title, e.g. add "UPGRADE" to the end, and change the options line `rootflags=subvol=root` to whatever name you used for the snapshot, e.g. `root37`. So you can either do it CLI style or use grubby; or
-# Make it the default `grubby --set-default=/boot/
+* Optional 2: You could even just reveal the hidden GRUB menu at boot time, and manually edit the default entry. You only need to do it twice. One boot to boot the snapshot and initiate the upgrade download. And the next boot to actually run the (offline) upgrade. The upgrade will install a new kernel package and its BLS snippet will contain the proper reference to `root37` as the root subvolume to use (or whatever name you used).
-# Optional: Instead of creating a new drop-in BLS file, you can show the GRUB menu on reboot, and modify the default 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`. And then you won't need to hunt down this BLS snippet and delete it later.
 ==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`.

Search