dracut icon indicating copy to clipboard operation
dracut copied to clipboard

fix(dracut-lib): use poweroff instead of halt

Open lnykryn opened this issue 1 year ago • 7 comments

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.

lnykryn avatar May 10 '23 10:05 lnykryn

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      

LaszloGombos avatar May 10 '23 12:05 LaszloGombos

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

lnykryn avatar May 10 '23 15:05 lnykryn

Sure, we can do a follow-up with sleep. I think thirty seconds is a bit too much; ten should be enough.

lnykryn avatar May 11 '23 09:05 lnykryn

@aafeijoo-suse what do you think of the latest version of this PR ?

LaszloGombos avatar Jul 30 '23 13:07 LaszloGombos

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.

AdamWill avatar Oct 30 '23 23:10 AdamWill

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 .

LaszloGombos avatar Mar 12 '24 01:03 LaszloGombos

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.

stale[bot] avatar Apr 22 '24 06:04 stale[bot]