dracut
dracut copied to clipboard
fix(dracut-lib): use poweroff instead of halt
Using halt will keep the HW still powered on. This can be confusing for users. The screen is blank, but for example, the fan is still running, and they have no idea what is going on. So let's call poweroff.
This looks good to me, but for consistency should the following change as well to poweroff instead of halt (in dracut-lib.sh).
source_hook "$hook"
warn "$action has failed. To debug this issue add \"rd.shell rd.debug\" to the kernel command line."
[ -z "$_emergency_action" ] && _emergency_action=halt
This looks good to me, but for consistency should the following change as well to poweroff instead of halt (in dracut-lib.sh).
source_hook "$hook" warn "$action has failed. To debug this issue add \"rd.shell rd.debug\" to the kernel command line." [ -z "$_emergency_action" ] && _emergency_action=halt
Fixed
I see this was done on purpose in e2ecc2d8, unfortunately we don't have access to https://bugzilla.redhat.com/show_bug.cgi?id=1053655 :) I made that one public
Maybe to (at least) see some info on the screen of what caused the
die()
, instead of power off the display? Well, even if so it does not work:) see https://bugzilla.redhat.com/show_bug.cgi?id=2192822
Sure, we can do a follow-up with sleep. I think thirty seconds is a bit too much; ten should be enough.
@aafeijoo-suse what do you think of the latest version of this PR ?
This is a problem for https://bugzilla.redhat.com/show_bug.cgi?id=2246410 . See also https://github.com/dracutdevs/dracut/pull/2545 .
Ten seconds seems waaaaay too short to me. In general, boot takes a while; people get bored and go to do something else while it's happening. For the specific case of media check, it takes longer. You can't assume someone will stay glued to the screen during the process such that they will catch a message that appears for ten seconds before the system suddenly shuts down.
I'd think ten minutes at least is the flat minimum to be reasonably sure someone caught the message.
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 https://github.com/dracutdevs/dracut/pull/2545 .
This issue is being marked as stale because it has not had any recent activity. It will be closed if no further activity occurs. If this is still an issue in the latest release of Dracut and you would like to keep it open please comment on this issue within the next 7 days. Thank you for your contributions.