#1240 Issue closed: Recover: boot_debug=2 kernel option causes Rear to wait for "enter" key press

Labels: fixed / solved / done, minor bug

ProBackup-nl opened issue at 2017-03-14 13:43:

  • rear version (/usr/sbin/rear -V): 2.00 git
  • OS version (cat /etc/rear/os.conf or lsb_release -a): Arch rolling 4.11.9-1
  • UEFI boot, systemd-bootloader (f.k.a. gummiboot)
  • Brief description of the issue: recover has USB keyboard failure (absent), I added kernel parameter boot_debug=2 in the (systemd-bootloader) boot menu, now the Recover boot process waits for "enter" key press.

What I have understood is that boot_debug level 2 does output lots of extra debugging information. Whereas boot_debug level 3 will run shells at various points.

I only needed extra information, so choose for boot_debug=2.

Expected

Only extra output on screen.

Reality

What happens is that the boot process stops early, waiting for keyboard input.

[ OK ] Started udev Kernel Device Manager.
        Starting Initialize Rescue System...
---> DEBUG MODE ENABLED, starting shell on tty9 <---

* * * Configuring Rescue System * * *
Press ENTER to run 00-functions.sh [ OK ] Started Relax-and-Recover boot script.
[ OK ] Started udev Coldplug all Devices.

Fix suggestion

Do not require keyboard input at boot_debug level 2 below 3.

ProBackup-nl commented at 2017-03-14 13:48:

Note: identical behaviour (asking for Press ENTER) occurs with boot_debug=1
And without boot_debug, Rear-Recover boots till I see the ReaR localhost login: prompt.

gdha commented at 2017-03-14 17:16:

@ProBackup-nl You will find the reason in the script ./skel/default/etc/scripts/system-setup:

function debug() {
    read -r </proc/cmdline
    case "$REPLY" in
        (*debug*) return 0 ;;
        (*) return 1;;
    esac
}

which means all entries with debug on the kernel command line will end up in the debug function.

jsmeix commented at 2017-03-22 16:03:

At least for me it seems to work much better with
https://github.com/rear/rear/pull/1259

ProBackup-nl commented at 2017-03-22 20:27:

My point here, is that the created recovery medium, responds differently then what users might expect from boot behaviour of Linux distributions. From both the Debian boot parameter documentation and Ubuntu boot parameters documentation:

Setting this boot parameter to 2 will cause the installer's boot process to be verbosely logged. Setting it to 3 makes debug shells available at strategic points in the boot process. (Exit the shells to continue the boot process.)

BOOT_DEBUG=0

This is the default.

BOOT_DEBUG=1

More verbose than usual.

BOOT_DEBUG=2

Lots of debugging information.

BOOT_DEBUG=3

Shells are run at various points in the boot process to allow detailed debugging. Exit the shell to continue the boot.

At boot_debug level 0, 1 and 2, I wouldn't expect keyboard entry.
For boot_debug level 3, I do expect keyboard entry.

When one is diagnosing a keyboard issue, I would set boot_debug=2 and don't expect breakpoints to be set.

gdha commented at 2017-03-23 08:21:

@ProBackup-nl Pull request #1259 of @jsmeix will fix this. Just wait until it is merged (tomorrow)

jsmeix commented at 2017-03-27 08:43:

With
https://github.com/rear/rear/pull/1259
merged, this issue should be fixed.

jsmeix commented at 2017-03-27 08:47:

@ProBackup-nl
regarding that you wrote
"boot_debug level 3 will run shells at various points"
with https://github.com/rear/rear/pull/1259 merged
you can now also specify on which tty ReaR will
run its debug mode shell or skip that to avoid conflicts
with other stuff that runs shells on whatever ttys.


[Export of Github issue for rear/rear.]