Hi,
I mentioned this in a QA meeting, and have given it enough testing that I think it's broadly usable. If desired it can be copied out of my user account and put up somewhere where QA folks will see it and can modify it as issues or improvements are discovered.
What is it? The idea is to produce a system that can confidently be used for baremetal testing, without risking the primary operating system. While VM's are a great way to test, it's also a really idealized environment that tends to not expose an assortment of bugs that affect particular hardware. But then quite a lot of folks reasonably don't want to upgrade their daily use hardware early on, because they don't want to always have to debug things, or have to figure out how to undo the upgrade if it really goes badly.
Therefore, I present a dual-boot setup offering: * no re-partitioning; * no installation step, instead system upgrade is used; * reversibility, or undoability, i.e. with just a few steps you can delete the "test OS".
https://fedoraproject.org/wiki/User:Chrismurphy/Draft/dualboot_teststation
-- Chris Murphy
On Sun, Aug 21, 2022, at 2:31 PM, Chris Murphy wrote:
https://fedoraproject.org/wiki/User:Chrismurphy/Draft/dualboot_teststation
I found a small problem, fixed in the latest version.
Gory details:
If you've ever used grubby, an /etc/kernel/cmdline file is created that contains the current subvolume name, e.g. rootflags=subvol=root36. But then when you snapshot it and boot e.g. root37, when performing the upgrade the existence of this file causes /etc/grub.d/10_linux to favor that old root. So the new BLS snippet for Fedora 37 contains rootflags=subvol=root36 instead of root37.
The file can safely be removed or renamed so I added that to the setup section instructions.
On 8/23/22 10:30 AM, Chris Murphy wrote:
On Sun, Aug 21, 2022, at 2:31 PM, Chris Murphy wrote:
https://fedoraproject.org/wiki/User:Chrismurphy/Draft/dualboot_teststation
I found a small problem, fixed in the latest version.
Gory details:
If you've ever used grubby, an /etc/kernel/cmdline file is created that contains the current subvolume name, e.g. rootflags=subvol=root36. But then when you snapshot it and boot e.g. root37, when performing the upgrade the existence of this file causes /etc/grub.d/10_linux to favor that old root. So the new BLS snippet for Fedora 37 contains rootflags=subvol=root36 instead of root37.
The file can safely be removed or renamed so I added that to the setup section instructions.
Under "Setup" it says:
rm /etc/kernel/cmdline /etc/kernel/cmdline
Shouldn't it just be:
rm /etc/kernel/cmdline
Steve
On Tue, Aug 23, 2022, at 10:54 AM, Steven A. Falco wrote:
Under "Setup" it says:
rm /etc/kernel/cmdline /etc/kernel/cmdline
Shouldn't it just be:
rm /etc/kernel/cmdline
Yep. Fixed. Thanks!
However, due to recent changes in grub currently in updates-testing for both 36 and 37, I'm no longer confident in this write up and have to retest. That /etc/kernel/cmdline can contain stale information has broken this use case at the moment, so I need to see if there's a better work around than deleting this file.
I've added a section how to modify /etc/kernel/cmdline in the snapshot before rebooting.
https://fedoraproject.org/wiki/User:Chrismurphy/Draft/dualboot_teststation
-- Chris Murphy
I've refreshed this write-up based on a system with Windows 10 and Fedora 39 on LUKS on Btrfs, "installing" Fedora 40 along side via dnf system-upgrade.
The two installations share /boot, /boot/efi, /home, with the two root file systems on Btrfs in their own subvolumes.
https://fedoraproject.org/wiki/User:Chrismurphy/Draft/dualboot_teststation
Features:
* no re-partitioning; * no resizing; * no extra drive; * no installation or reinstallation, system upgrade is used instead; * reversibility, or undoability, i.e. you can delete the "test OS", or for that matter the older system root, with just a few steps.
-
Chris Murphy -
Steven A. Falco