fix: wait 12 hours before halt on media check fail

[AdamWill]

If a modesetting driver has been loaded by the time the media check happens, halting the system (as we currently do immediately if the check fails) blanks the screen, which is confusing for the user. This adds a warning message and a 12-hour wait before the system is eventually halted, so the user can see the media check failure and (presumably) reboot and fix the medium.

It also tweaks the text of the failure message not to call it a "CD check", since it's not 1998 any more.

https://bugzilla.redhat.com/show_bug.cgi?id=2246410

Checklist

• I have tested it locally
• [-] I have reviewed and updated any documentation if relevant
• [-] I am providing new code and test(s) for it

[AdamWill]

Note, this fixes the problem for live images. Traditional installer images use a different codepath that lives in anaconda, I will send a PR for anaconda to fix the same problem on that path.

[LaszloGombos]

This magic number (12 hours) does not make sense to me. How is waiting this long improves the situation for the user ?

Also, #2332 somewhat related, especially the following point..

For some remote/unattended setup this could even damage the HW.. perhaps poweroff at least safer for the HW.

initramfs images usually not configured for proper power management - e.g. on a laptop this might be fan blasting full speed for a half day.

[AdamWill]

the situation we're concerned about is that the user starts the media check and wanders off to do something else. we want them to come back to a useful error message, not a mysterious blank screen (or, with 2332, powered-off system).

I considered various values from a minute upwards. 12 hours was nirik's suggestion.

[AdamWill]

As for the "unattended" case - presumably, if you choose to run the media check, you're in a position to power off the system after noticing it failed.

[AdamWill]

btw, I wasn't necessarily expecting this to be merged as-is, I was hoping someone had a better idea somehow. But I thought it was good enough for F39 at least, and wanted to submit it upstream before doing the downstream build.

[LaszloGombos]

We also have "rd.debug" in our toolbox. I think dracut already recommends setting "rd.debug" to debug dracut issues for the NOT unattended case.

Users should not just reboot and try again. They should reboot set "rd.debug" in the bootloader and try again instead.

Perhaps if "rd.debug" is NOT set, poweroff is still the best possible action (with not much of a wait).
If and only if "rd.debug" is set, having a long timeout (or even waiting for input before taking an action) is very reasonable.

Crossposted also at #2332 .