Bug#1026027: graphical installer: using nano in a installer shell fails

[Holger Wansing]

Package: debian-installer
Severity: normal


Hi,

I just noticed that nano cannot be used anymore in the installer shell
(graphical installer):

- start the installer
- choose 'Graphical expert install'
- 'Execute a shell'
- call 'nano /etc/fstab'
---> Error opening terminal: xterm.


This works in Bullseye installer, but fails in every bookworm dailies I have
here (2022-01 - today).
No problem in text installer.


Not sure, which package is responsible for this though (is this busybox?)


Holger


--
Holger Wansing <hwan...@mailbox.org>
PGP-Finterprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076

[Cyril Brulebois]

Holger Wansing <hwan...@mailbox.org> (2022-12-13):

> I just noticed that nano cannot be used anymore in the installer shell
> (graphical installer):
>
> - start the installer
> - choose 'Graphical expert install'
> - 'Execute a shell'
> - call 'nano /etc/fstab'
> ---> Error opening terminal: xterm.
>
>
> This works in Bullseye installer, but fails in every bookworm dailies
> I have here (2022-01 - today).
> No problem in text installer.
>
> Not sure, which package is responsible for this though (is this busybox?)

nano is shipped by nano-udeb, that error seems to come from ncurses
though (https://sources.debian.org/ is wonderful).


Cheers,
--
Cyril Brulebois (ki...@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

[Philip Hands]

Holger Wansing <hwan...@mailbox.org> writes:

> - start the installer
> - choose 'Graphical expert install'
> - 'Execute a shell'
> - call 'nano /etc/fstab'
> ---> Error opening terminal: xterm.

That would seem to be because $TERM is set to 'xterm', whereas there's
no terminfo file available for xterm.

Under /lib/terminfo/*/ we have:

ansi dumb linux screen vt102

and there's also /usr/share/terminfo/b/bterm

In the F1-F3 consoles it's set to 'linux' (as expected), in the text
installer, TERM is set to 'bterm' -- these work.

So as a workaround, one can set e.g: TERM=bterm and then nano works in
the graphical install's shell.

On the 11.5 netinst I just tried out, in the Graphical Install's shell,
TERM=xterm so that's obviously not the cause of the issue, but the
difference would appear to be that it has:

/usr/share/vte/termcap-0.0/xterm

So I guess the fix for this is either to make sure that that termcap
file gets installed again, or to set TERM in the Graphical Install's
shell to something like 'bterm' or 'vt102'.

I suspect restoring the termcap file is the correct fix.

Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/ http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY

[Holger Wansing]

Hi,

Philip Hands <ph...@hands.com> wrote (Tue, 13 Dec 2022 20:34:17 +0100):
> On the 11.5 netinst I just tried out, in the Graphical Install's shell,
> TERM=xterm so that's obviously not the cause of the issue, but the
> difference would appear to be that it has:
>
> /usr/share/vte/termcap-0.0/xterm
>
> So I guess the fix for this is either to make sure that that termcap
> file gets installed again, or to set TERM in the Graphical Install's
> shell to something like 'bterm' or 'vt102'.
>
> I suspect restoring the termcap file is the correct fix.

/usr/share/vte/termcap-0.0/xterm is there on dailies.
And the packages which ships it (libvte-common) did not receive any
updates since buster. So there's no change there I guess.

And on the other side: on debian-11 installer, TERM is also set to
'xterm' as it is now on the dailies, so also no changing here.
But in debian-11 it works nevertheless!


Hmm. Kibi mentioned that this bug comes from ncurses (however I fail to
see any details here), should this be redirected to ncurses then?

Holger


--
Holger Wansing <hwan...@mailbox.org>

PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076

[Philip Hands]

Holger Wansing <hwan...@mailbox.org> writes:

> Hi,
>
> Philip Hands <ph...@hands.com> wrote (Tue, 13 Dec 2022 20:34:17 +0100):
>> On the 11.5 netinst I just tried out, in the Graphical Install's shell,
>> TERM=xterm so that's obviously not the cause of the issue, but the
>> difference would appear to be that it has:
>>
>> /usr/share/vte/termcap-0.0/xterm
>>
>> So I guess the fix for this is either to make sure that that termcap
>> file gets installed again, or to set TERM in the Graphical Install's
>> shell to something like 'bterm' or 'vt102'.
>>
>> I suspect restoring the termcap file is the correct fix.
>
> /usr/share/vte/termcap-0.0/xterm is there on dailies.

Oh, so it is. Hmm, I seem not to have checked that bit, sorry.

Perhaps the presence of the termcap file is irrelevant, or could it be
that nano used to be able to make use of that, and more recently only
supports terminfo?

> Hmm. Kibi mentioned that this bug comes from ncurses (however I fail to
> see any details here), should this be redirected to ncurses then?

Well, ncurses-base provides /lib/terminfo/x/xterm (in normal .deb
packages), so perhaps that's why, although AFAICS it wasn't including
that file in the udeb, even when things were working.

Making it ship a terminfo for xterm in the udeb would probably fix
things, but I think it would also be quite nice to know why it broke.

[Cyril Brulebois]

cc += nano maintainers

Long story short: nano no longer starts in the graphical installer when
started from the menu (meaning integrated via VTE), but does start fine
when started from a console.

Any insight welcome.

Below, latest message on the bug report:

Philip Hands <ph...@hands.com> (2022-12-15):

> Holger Wansing <hwan...@mailbox.org> writes:
>
> > Hi,
> >
> > Philip Hands <ph...@hands.com> wrote (Tue, 13 Dec 2022 20:34:17 +0100):
> >> On the 11.5 netinst I just tried out, in the Graphical Install's shell,
> >> TERM=xterm so that's obviously not the cause of the issue, but the
> >> difference would appear to be that it has:
> >>
> >> /usr/share/vte/termcap-0.0/xterm
> >>
> >> So I guess the fix for this is either to make sure that that termcap
> >> file gets installed again, or to set TERM in the Graphical Install's
> >> shell to something like 'bterm' or 'vt102'.
> >>
> >> I suspect restoring the termcap file is the correct fix.
> >
> > /usr/share/vte/termcap-0.0/xterm is there on dailies.
>
> Oh, so it is. Hmm, I seem not to have checked that bit, sorry.
>
> Perhaps the presence of the termcap file is irrelevant, or could it be
> that nano used to be able to make use of that, and more recently only
> supports terminfo?
>
> > Hmm. Kibi mentioned that this bug comes from ncurses (however I fail to
> > see any details here), should this be redirected to ncurses then?
>
> Well, ncurses-base provides /lib/terminfo/x/xterm (in normal .deb
> packages), so perhaps that's why, although AFAICS it wasn't including
> that file in the udeb, even when things were working.
>
> Making it ship a terminfo for xterm in the udeb would probably fix
> things, but I think it would also be quite nice to know why it broke.


Cheers,

[Benno Schulenberg]

> Philip Hands <ph...@hands.com> (2022-12-15):

>> Perhaps the presence of the termcap file is irrelevant, or could it be
>> that nano used to be able to make use of that, and more recently only
>> supports terminfo?

This is the explanation, I think. Nano removed support for Slang in
version 5.5. The nano-udeb (5.4) that is in Bullseye was still linked
against Slang, which has its own ideas about what which terminals do.

The nano-udeb (7.2) that is in Bookworm links against ncurses, and
ncurses wants TERM to be set to something valid -- something for
which a terminfo file is available.

Benno

[Sven Joachim]

Control: reassign -1 di-utils-terminfo
Control: tags -1 + patch

Indeed. The error message mentioned in Holger's initial report comes
from the ncurses initscr() function which nano (and other curses
applications) calls early. If no terminfo entry for $TERM can be found,
initscr() exits the program.

I have attached the obvious patch.

Cheers,
Sven

[Philip Hands]

Control: tags -1 + pending

Sven Joachim <sven...@gmx.de> writes:
...

> I have attached the obvious patch.

Here's your patch:

https://salsa.debian.org/philh/debian-installer-utils/-/tree/sven-bug/102602

which generates this mini ISO:

https://salsa.debian.org/installer-team/debian-installer/-/jobs/3960725/artifacts/file/public/gtk-mini.iso

wherein the bug is fixed.

That being the case, I've pushed it into the master branch.