#1282 Issue `closed`: Editor problems in Recovery Mode¶

Labels: support / question, won't fix / can't fix / obsolete

dcz01 opened issue at 2017-04-10 09:09:¶

Editor problems in Recovery Mode¶

rear version (/usr/sbin/rear -V): Relax-and-Recover 2.00 / Git
OS version (cat /etc/rear/os.conf or lsb_release -a): RHEL6
rear configuration files (cat /etc/rear/site.conf or cat /etc/rear/local.conf): -
Are you using legacy BIOS or UEFI boot? BIOS
Brief description of the issue: Editing the local.conf for encryption key in recovery mode not simple possible because the editors are working different than in the normal system.
Work-around, if any: None

Is there a bug with the vi or nano program for editing files in the recovery mode?

jsmeix commented at 2017-04-10 09:33:¶

For me 'vi' works o.k. in the ReaR recovery system.

The ReaR recovery system is a very minimal system
so that you cannot expect this or that "comfort" that
you may have in a normal running full featured system.

Perhaps it may help to understand your particular issue
when you even describe what exactly you mean with
"editors are working different than in the normal system"?

dcz01 commented at 2017-04-10 10:09:¶

Well my problem is, that when i edit an file not only by adding a new line but by editing an existing line you should see some strange happening. this happens in nano a lot. and the vi insert does not work for me.

gdha commented at 2017-04-10 13:33:¶

@dcz01 Your error description is not complete I'm afraid. Which console are you using? Physical console or KVM, VirtualBox, vSphere, or something else? iLO perhaps? Which keyboard language are you using? Is there a mismatch between keystrokes and what you normally expect?

dcz01 commented at 2017-04-10 14:03:¶

Yes i'm using vSphere for an test restore and in this console i'm editing the file with this error/happening.
I use always german keyboard layout.
Should i use anything else?

The first picture shows the file in normal with an ssh login.
The second shows the error only by getting over the writing with the arrow keys.

dcz01 commented at 2017-04-12 09:44:¶

@gdha I hope the description and the screenshots can help you to find the problem or to follow.

gdha commented at 2017-04-18 14:06:¶

@dcz01 So you are using nano, right? I'm thinking we are missing some necessary files from nano.

dcz01 commented at 2017-04-25 07:07:¶

@gdha Yes right, i'm using nano always. But the problem occours with vi too...
Maybe it could be the console mode like you said. I'll test it today with an recovery with ReaR.

dcz01 commented at 2017-04-25 12:15:¶

@gdha The problem or bug/error happens in the normal console by the physical server too.
But could this come from files which are not present in recovery?

razorfish-sl commented at 2017-05-13 07:23:¶

I have seen this as well.
REAR 2.00

It is NOT just a nano problem, it looks to be related to the video driver or something.

using a HP 380 gen 7 with a recovery disk off an ibm rack, the boot starts.
whilst the kernel is initing jumps about, text goes large.
finally at the REAR recovery menu screen it is VERY SLOW on video refresh, but fully visible.

if you then select rear recovery and press to edit the line, the cursor does not track the characters correctly, jumping back several spaces or overwriting with other parts of the line.
each backward movement takes 1 second to execute.

after booting , nano is messed up on editing. the screen is shifted as per the image by about 50 %
when you move to a line it jumps to the left.

If you go into the rear hardware inspection system from the rear screen, it is as if the thing is running on a 1960's computer, every screen refresh can be seen.
Like watching the green screen cursor moving from left to right whilst the scren redraws.

dcz01 commented at 2017-06-13 12:11:¶

@razorfish-sl @gdha Yes, i think that must be exactly my problem.
But what can i do then? Integrate more drivers or programs?

razorfish-sl commented at 2017-06-17 08:08:¶

check your video parameters being passed about.
try setting it to the most basic suport.

jsmeix commented at 2017-06-19 12:40:¶

@razorfish-sl
regarding your above
https://github.com/rear/rear/issues/1282#issuecomment-301231233

... the boot starts.
whilst the kernel is initing jumps about, text goes large.
finally at the REAR recovery menu screen ...

While the ReaR recovery system boot screen is shown
the kernel does not run, cf.
https://github.com/rear/rear/issues/1135#issuecomment-268957435

Only as a blind guess - perhaps that is somehow related:
You may have a look at
https://github.com/rear/rear/issues/1135
therein see in particular
https://github.com/rear/rear/issues/1135#issuecomment-268781732
and
https://github.com/rear/rear/issues/1135#issuecomment-268963600

dcz01 commented at 2017-06-21 14:48:¶

Well if no one can find an problem or an solution i'll close this issue now...

dcz01 commented at 2019-04-15 12:40:¶

@jsmeix @gdha @razorfish-sl
Now i think i found the solution.
Is it possible to implement this to the start of the recovery system?
export TERM=linux

jsmeix commented at 2019-04-26 09:17:¶

@dcz01
the scripts in the usr/share/rear/skel directory are those
that are run during ReaR recovery system startup phase.
In our current GitHub master code in those scripts I found

# find usr/share/rear/skel -type f | xargs grep 'TERM='

usr/share/rear/skel/default/etc/profile:
export TERM=ansi

usr/share/rear/skel/default/usr/lib/systemd/system/serial-getty@.service:
Environment=TERM=vt100

usr/share/rear/skel/default/usr/lib/systemd/system/getty@.service:
Environment=TERM=linux

The different TERM values that are set here
indicate that something at least looks inconsistent
regarding the TERM value in our ReaR recovery system.

FYI:
In other scripts I find

usr/share/rear/restore/ZYPPER/default/980_initial_network_setup.sh:
chroot $TARGET_FS_ROOT /bin/bash --login -c "yes '' | TERM=dumb yast2 --ncurses lan add name=eth0 ethdevice=eth0 bootproto=dhcp" || true

usr/share/rear/restore/NSR/default/400_restore_with_nsr.sh:
TERM=linux nsrwatch -p 1 -s $(cat $VAR_DIR/recovery/nsr_server ) </dev/tty8 >/dev/tty8 &

usr/share/rear/lib/layout-functions.sh:
TERM=dumb $@ 2>&1 | sed -rn 's/^[^0-9\.]*([0-9]+\.[-0-9a-z\.]+).*$/\1/p' | head -1

jsmeix commented at 2019-04-26 09:23:¶

The inconsistent TERM values in skel scripts are handled via
https://github.com/rear/rear/issues/2124

[Export of Github issue for rear/rear.]

#1282 Issue closed: Editor problems in Recovery Mode¶