#1135 Issue closed: ReaR recovery system boot screen unintelligible on Dell PowerEdge T630

Labels: support / question, fixed / solved / done, special hardware or VM

r2evans opened issue at 2016-12-21 01:12:

Relax-and-Recover (rear) Issue Template

Please fill in the following items before submitting a new issue (quick response is not guaranteed with free support):

  • rear version (/usr/sbin/rear -V):

    (cloned today)

    Relax-and-Recover 1.19 / Git

  • OS version (cat /etc/rear/os.conf or lsb_release -a):

    No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.1 LTS
Release:        16.04
Codename:       xenial

  • rear configuration files (cat /etc/rear/site.conf or cat /etc/rear/local.conf):

    (directly from the example)

    ### write the rescue initramfs to USB and update the USB bootloader
OUTPUT=USB
### create a backup using the internal NETFS method, using 'tar'
BACKUP=NETFS
### write both rescue image and backup to the device labeled REAR-000
BACKUP_URL=usb:///dev/disk/by-label/REAR-000

  • Brief description of the issue

    On boot, the screen is showing garbage (sometimes just a few lines), though they tend to be "responsive" to arrow keys. When I press enter, it boots to the local drive. Once booting has started, the local-drive linux console works fine, all boot messages work fine. This is a server, no GDM or X installed.

    I have seen this before with linux when the console video driver was not correct. I don't know how to set it here. I have been able to successfully boot to other linux distro boot-USBs.

  • Work-around, if any

    None found yet. I have only done mkrescue, nothing else; referencing the examples in "Booting from USB storage device" (04-scenarios.adoc line 240), I don't know how many arrows I need to get to a certain menu. I've tried twice and ended up booting local or entering grub. I'd much prefer to not have to navigate the menus blindly.

Thanks for all the work.

jsmeix commented at 2016-12-21 11:31:

I am afraid I cannot help with setting the right console video driver.
Perhaps the attached image of a ReaR recovery system boot screen
could help you a bit to navigate blindly for now as a workaround:
In particular:
The preselected entry boots from the first local disk
(i.e. that usually boots your installed system).
The topmost entry boots the ReaR recovery system.
When you hit many times the up arrow key it does not wrap around
at the topmost entry - i.e. to boot the ReaR recovery system use
many times the up arrow key and then the enter key.

rear_recovery_boot_screen

jsmeix commented at 2016-12-21 11:38:

The image of a ReaR recovery system boot screen
is for traditional BIOS boot, for (U)EFI it is different.

r2evans commented at 2016-12-21 17:53:

That's helpful, thanks for the updated image. The no-wrap is helpful, too. Thanks!

(It is traditional BIOS, not (U)EFI, so I don't think that's the issue. The server is a Dell PowerEdge T630, for reference.)

jsmeix commented at 2016-12-22 10:19:

ReaR uses syslinux/isolinux for creating
its bootable recovery ISO image, cf.
https://github.com/rear/rear/issues/764

When you set in /etc/rear/local.conf

KEEP_BUILD_DIR="yes"

then "rear mkbackup/mkrescue" will not remove its
build directory of the form /tmp/rear.XXXXXXXXXXXXXXX
(cf. "TMPDIR" in /usr/share/rear/conf/default.conf)
so that you can after "rear mkbackup/mkrescue" inspect
in detail what your ReaR recovery system contains.

For example on my test system I get two identical

/tmp/rear.MRb3SRJ7wUq9pKs/tmp/isofs/isolinux/isolinux.cfg
/tmp/rear.MRb3SRJ7wUq9pKs/tmp/isolinux/isolinux.cfg

which contain things like

MENU label Recover f79
...
append initrd=initrd.cgz root=/dev/ram0 vga=normal rw selinux=0 console=ttyS0,9600 console=tty0

The 'vga=normal' string appears in the ReaR sources in those files
usr/share/rear/lib/bootloader-functions.sh
usr/share/rear/output/PXE/default/810_create_pxelinux_cfg.sh
usr/share/rear/output/USB/Linux-i386/300_create_extlinux.sh

There is no other 'vga=' string in the ReaR sources
which means 'vga=normal' is set hardcoded
and that has always worked (as far as I know).

The make_syslinux_config function in
usr/share/rear/lib/bootloader-functions.sh is called in
usr/share/rear/output/ISO/Linux-i386/300_create_isolinux.sh and
usr/share/rear/output/OBDR/Linux-i386/300_create_isolinux.sh

When I run "rear -s mkbackup" on my test system
I get in particular

# rear -s mkbackup
...
Source output/ISO/Linux-i386/300_create_isolinux.sh

which indicates that it is the make_syslinux_config function
in usr/share/rear/lib/bootloader-functions.sh
that sets the 'vga=normal' kernel command line parameter
when booting the ReaR recovery system.

You could play around with the kernel command line
settings of the make_syslinux_config function in
usr/share/rear/lib/bootloader-functions.sh
to try out if something makes it work for you.

Alternatively
and even better from my point of view, cf:
https://github.com/rear/rear/issues/951#issuecomment-239836711

Because 'vga=normal' should work on any system
(I never had an issue with an unintelligible
ReaR recovery system boot screen)
I assume there is something special on your particular
hardware why it does not work with 'vga=normal'.

Therefore I would first of all recommend to try to find out
if you could make your particular hardware behave "normal"
so that it works with with traditional 'vga=normal'.

Only if that is not possible I would try to adapt ReaR
especially for your particular hardware.

jsmeix commented at 2016-12-22 10:29:

Correction:

With "OUTPUT=USB" it is
usr/share/rear/output/USB/Linux-i386/300_create_extlinux.sh
that is used.

On my test system I had "OUTPUT=ISO" and then
the make_syslinux_config function in
usr/share/rear/lib/bootloader-functions.sh is called in
usr/share/rear/output/ISO/Linux-i386/300_create_isolinux.sh

@r2evans
in your case - if you need to adapt ReaR - you must change
usr/share/rear/output/USB/Linux-i386/300_create_extlinux.sh

gdha commented at 2016-12-22 11:32:

I would start with updating syslinux and extlinux. The problem is most of the times an outdated version of the video driver within one of those packages

Verstuurd vanaf mijn iPhone

Op 22 dec. 2016 om 11:29 heeft Johannes Meixner notifications@github.com het volgende geschreven:

Correction:

With "OUTPUT=USB" it is
usr/share/rear/output/USB/Linux-i386/300_create_extlinux.sh
that is used.

On my test system I had "OUTPUT=ISO" and then
the make_syslinux_config function in
usr/share/rear/lib/bootloader-functions.sh is called in
usr/share/rear/output/ISO/Linux-i386/300_create_isolinux.sh

@r2evans
in your case - if you need to adapt ReaR - you must change
usr/share/rear/output/USB/Linux-i386/300_create_extlinux.sh

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

r2evans commented at 2016-12-22 16:53:

Many thanks for all of the suggestions. Because I'm dealing with a "commercial Dell server", I'm not surprised that "normal" is not quite right. When I speak with others with similar servers about similar issues, they all report using the high-end commercial configurations, including vSphere and others provided directly from Dell. Not a bad thing, mind you, but many non-standard BIOS extensions/configurations seem to mess with doing things "my way" (i.e., not through Dell).

The pointers and walk-through are very-much appreciated, I'll report back if I find something meaningful.

jsmeix commented at 2016-12-23 08:40:

@r2evans
you can forget all what I wrote above about the
'vga=normal' kernel command line parameter.
That setting has nothing to do with the ReaR
recovery system boot screen.

Reason:

The ReaR recovery system boot screen is
not shown by the kernel of the ReaR recovery system.

Instead the ReaR recovery system boot screen is
shown by the ReaR recovery system boot loader
i.e. by syslinux/isolinux/extlinux.

While the ReaR recovery system boot screen is shown
no kernel is loaded - loading the kernel happens after
you selected a boot entry on the ReaR recovery system
boot screen.

When the ReaR recovery system boot loader has loaded
the kernel, then kernel command line parameters
come into effect.

jsmeix commented at 2016-12-23 09:37:

Only a blind guess:

Syslinux supports two user interface modules
menu.c32 (text mode only) and vesamenu.c32 (graphical).

ReaR uses always menu.c32.

Perhaps in your particular case you need vesamenu.c32?

See
http://www.syslinux.org/wiki/index.php?title=Menu

The simple menu system is based on a module located
at com32/menu/vesamenu.c32 (graphical)
or com32/menu/menu.c32 (text mode only).
...
To use the menu system, simply make sure [vesa]menu.c32
is in the appropriate location for the boot medium (the same
directory as the configuration file for SYSLINUX, EXTLINUX
and ISOLINUX, and the same directory as pxelinux.0 for
PXELINUX), and put the following options in the configuration
file :

DEFAULT menu.c32
PROMPT 0

Another alternative, using the UI directive:

UI menu.c32

On my test system I have in my
/tmp/rear.MRb3SRJ7wUq9pKs/tmp/isolinux/isolinux.cfg
at the bottom

default menu.c32

and I have both syslinux user interface modules
menu.c32 and vesamenu.c32
/tmp/rear.MRb3SRJ7wUq9pKs/tmp/isolinux/menu.c32
/tmp/rear.MRb3SRJ7wUq9pKs/tmp/isolinux/vesamenu.c32
so that it seems one can also use

default vesamenu.c32

I changed in usr/share/rear/lib/bootloader-functions.sh

    echo "default menu.c32"

to

    echo "default vesamenu.c32"

and for me it worked.

I get now the ReaR recovery system boot screen
in graphical mode (with same textual content).

@r2evans
because you use "OUTPUT=USB" you may try out if it
works for you to change in
/usr/share/rear/output/USB/Linux-i386/300_create_extlinux.sh

    syslinux_write "default menu.c32"

to

    syslinux_write "default vesamenu.c32"

jsmeix commented at 2017-01-18 13:41:

I assume it somehow works because "no news is good news".

r2evans commented at 2017-01-18 15:22:

Generally a necessary assumption, though I haven't been able to test it (been on travel). It sounds fair, though, so coding it is fine for now. I'll come back when I'm able to confirm or not. Thanks, by the way, for the suggestions.

jsmeix commented at 2017-01-18 15:53:

If it does not work you can reopen this issue.

If other/unrelated issues appear, please submit
each of them as a new separated issue.

[Export of Github issue for rear/rear.]