After recent Fedora InstallFest event in Brno, we've seen that the common use case of how university students install Fedora has changed compared to past. Now, their notebooks run with UEFI. Also, very often students put in a second drive for Fedora installation. This ticket is a request to cover a frequent installation scenario with OpenQA.
The purpose of this test would be to finish a Fedora installation to a second disk, and leave the first disk untouched.
The installation would be performed on an UEFI system and the first disk would contain an existing partition layout including ESP (EFI system partition). Having the layout resemble default Windows disk layout including NTFS partitions would be a plus. The second disk would be expected to end up with its own ESP. The first disk (and especially its ESP) is expected to get untouched during the installation process. The system is expected to boot properly, when instructed to boot from the second disk (i.e. when the newly created "Fedora" boot option is set as the first one - I'm not sure if anaconda is supposed to do that automatically, would be great to find out).
This scenario would be nice to get automated using both guided partitioning and custom partitioning (of course, having blivet-gui covered as well wouldn't hurt either, but I don't think we need to exhaustively cover everything).
Detailed steps: 1. Prepare an UEFI system with 2 disks. 2. Prepare an existing GPT layout on the first disk, including ESP and some NTFS partitions. No free space. 3. Have the second disk empty. 4. Boot the installer. 5a. In guided partitioning, select only the second disk and perform the installation. 5b. In manual partitioning, select only the second disk, create a working layout and perform the installation. 6. Either confirm that the system is configured to automatically boot from the second disk's OS (using efibootmgr; in case anaconda does this automatically - and if it doesn't, it might be a bug/RFE), or use system firmware to configure "Fedora" to boot as the first option. 7. Boot the installed operating system, verify it boots correctly. 8. Verify that the first disk is untouched (same partition layout, same ESP contents).
efibootmgr
Can you, @adamwill, point me towards creating a VM that would fulfil these requirements to test on that?
well, first, you'll need to patch createhdds to produce a new base disk image with the requirements described in step 2 above. After that you'd just create a new test suite with NUMDISKS set to 2 and HDD_1 set to the new base disk image; openQA will automatically make the second disk an empty one. Then make a job template to run that test suite on the UEFI machine, and whatever else we need to do to make the install tests do step 5 above, and postinstall tests to do the checks in 6 and 8. That should be all that's really necessary.
NUMDISKS
HDD_1
Oh, rather importantly, I should note that the existing test install_multi (when run on the UEFI machine) does almost exactly this: it tests an install with one existing populated disk and one empty disk, installs to the empty disk, and checks the populated disk is untouched.
install_multi
However, it makes the empty disk the first one and the populated disk the second one, and it uses disk_mbr_full as the image for the populated disk, which - as the name suggests - is an MBR-labelled image, not GPT-labelled. So rather than write an entirely new test we could look at tweaking that test I guess.
disk_mbr_full
Ok, thanks. I will look at the test if I can figure out how to tweak it.
So, @kparal and I have tweaked the createhdds.py which is now able to create an image with windows partitions. I will install windows and see what type of partitions it creates and update the description in hdds.json to be able to create a Windows like image any time we wish.
createhdds.py
hdds.json
Metadata Update from @lruzicka: - Issue assigned to lruzicka
Metadata Update from @lruzicka: - Assignee reset
Log in to comment on this ticket.