Created attachment 1897778 [details] Picture of display after failed media check Description of problem: Media check fails with "NA" when starting a Workstation Live image with the "Test this media and start Fedora-Workstation-Live Rawhide". A "checkisomd5...service failed because the control process exited with error code" message is printed. Affected machine is an HP Compaq 8510w using BIOS and USB. UEFI on another machine seems fine. Booting in a VM using BIOS mode works fine. How reproducible: Every time. Steps to Reproduce: 1. Insert USB with Workstation Live image written 2. Select USB option on boot 3. Select "Test this media & start Fedora-Workstation-Live Rawhide" (or wait for timeout) Actual results: Media check fails to start, boot fails. Expected results: Media check passes, boot continues as usual. Additional info: Skipping the media check and booting works fine. First observed with Fedora-Rawhide-20220701.n.0 Workstation Live compose. I have since observed it with the 20220711 and 20220716 composes as well. I have not had a chance to check non Workstation Live composes. I don't have a good way to capture the output, so I have attached a failed boot screenshot.
What happens if you run checkisomd5 on the device after booting? From the error message it looks like it thinks there is no checksum data. That error on line 1 may also be related, if it doesn't setup /dev/label then it won't be able to check.
(In reply to Brian Lane from comment #1) > What happens if you run checkisomd5 on the device after booting? From the > error message it looks like it thinks there is no checksum data. That error > on line 1 may also be related, if it doesn't setup /dev/label then it won't > be able to check. So, if I try to run checkisomd5 against the block device from the booted USB stick, it hangs? No error, just consumes 100% CPU indefinitely. I assume the checksum data must be there as the media check works when the ISO is booted in a VM (either UEFI or BIOS). As for the missing sysctl, that's bug 2102903. I should have noted that initially.
Ok, I am able to reproduce this in a VM. With qemu and -hda I see the same problem as you saw on hardware. The issue is that the new GRUB2 based images have a different partition table layout using GPT. On the old image the /dev/sda1 wasn't really a valid partition, it covered the whole image and doesn't have a type set. But since it starts at sector 0 it can be used to run checkisomd5, and the iso9660 label is detected on it by blkid. On the new GPT layout the partition is valid, and starts at sector 64 so it is missing part of the checksum data at the start, but label detection still works so it is used for the check. I think dracut's 90dmsquash-live module is going to need some changes to handle the new images when they are written to USB.
PR is here - https://github.com/dracutdevs/dracut/pull/1882
Proposed as a Blocker for 37-beta by Fedora user nielsenb using the blocker tracking app because: Fails the of "Release-blocking live images must boot to the expected boot menu, and then to a desktop or to a login prompt where it is clear how to log in to a desktop" clause the [expected boot behavior criteria](https://fedoraproject.org/wiki/Basic_Release_Criteria#Expected_image_boot_behavior). You can boot, but only if you explicitly elect to not test the media.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle. Changing version to 37.
+3 in https://pagure.io/fedora-qa/blocker-review/issue/845 , marking accepted.
I'll create an update ASAP.
https://src.fedoraproject.org/rpms/dracut/pull-request/22
F37: https://bodhi.fedoraproject.org/updates/FEDORA-2022-64b1766c16 Currently in testing.
-> stable