Qemu CD/DVD device and actual optical drives should have the same
dependency. I know the example case [1] it was a BIOS bug that
syslinux was able to work around with an update. We'd never find such
a thing unless someone runs into it with affected hardware, which did
happen and that's how it ended up getting fixed in the same release
cycle.
If you're certain about this, that would be good news, because it would mean that
limited bare-metal testing is not a big problem (generic problems would be detected by
OpenQA). I believe it's still needed to do bare-metal testing at least with Final RC
images, because the code paths are still different, and even if there was a specific
firmware bug like in [1], we can still get "lucky" and hit it in our testing.
But it also means we can limit our manual testing to just a single Live image, single
netinst image, etc, and still trust the results reasonably well.
Whereas a more recent problem, where both ISO file attached to a
qemu
cd/dvd device and also burned to an optical disk would work, but
imaged using dd to a USB stick would not, was due to a missing
boot.img/stage 1 bootloader. If that same ISO were attached with a
qemu hard drive device instead, it too would fail. How the bootloader
is located by the firmware differs depending on whether it's an
optical device (El Torito provides the hint) or a disk drive, and a
USB stick is treated as a disk drive.
That is interesting. I poked Jan Sedlak and asked him to look whether we could mount some
images as hdd devices in OpenQA, so that potential dd-related problems are discovered
immediately.
>
> [1]
>
https://bugzilla.redhat.com/show_bug.cgi?id=1148087