Bug#844549: network-console broken: no screen to be resumed matching sh

[Samuel Thibault]

Roger Shimizu, on Wed 30 Nov 2016 23:53:31 +0900, wrote:
> Just one issue for SSH (network-console).
> Since the SSH session shares the same screen with serial, the screen
> size is limited to 80x25 (probably, I didn't count the number), which
> is too small to most recent monitor devices.

Sure. Since the serial console is supposed to have 80x25, you can't make
the screen session bigger, it would overflow on the serial console
output. There is no way around that.

Samuel

Bug#844549: network-console broken: no screen to be resumed matching sh

[Roger Shimizu]

On Tue, Nov 22, 2016 at 3:05 AM, Roger Shimizu  wrote:
>
> I'll test the daily image on my Linkstation NAS.

I tested the daily image on my armel devices.
Both serial way and SSH way works fine. And if connect both serial and
SSH (network-console), serial/SSH seems to share the same screen
session, which is good and beyond what I expected.
It's exceeded what I have imagined.

Just one issue for SSH (network-console).
Since the SSH session shares the same screen with serial, the screen
size is limited to 80x25 (probably, I didn't count the number), which
is too small to most recent monitor devices.

Does it deserve a new bug report?
What do you think of it?

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#844549: network-console broken: no screen to be resumed matching sh

[Roger Shimizu]

Seems I'm late for the d-i/screen party, but ..

On Thu, Nov 17, 2016 at 6:39 AM, Martin Michlmayr  wrote:
>
> Oh, good point.
>
> I think that's what we want but I'm not sure.  Maybe Roger can
> comment.  In his old code, there was also a $NETBOOT_SCREEN variable
> which afaict wasn't set set anywhere.

Originally I add screen support to D-I for my orion5x-based
Linkstation NAS, which supports both serial / network console to start
D-I.

I want to support screen in both way (serial / network console), because
 - for serial console, no other option to access command line as free
as anytime.
 - for network console, no way to resume if the network cable gets
unplugged accidentally, or SSH connection disconnects for whatever
reason.

Because I'm new to D-I code base, I want to test the code I injected
in works alright, so I add $NETBOOT_SCREEN variable so that I can test
screen support for "one D-I image" in either serial console way (=1)
or network console way (=0).

The "one D-I image" I chose to test was netboot/network, so the
default of $NETBOOT_SCREEN is 0.
The "one D-I image" is just literally in D-I image filename, built by
same source code except with different $NETBOOT_SCREEN setting.

Maybe it's more clear to remove $NETBOOT_SCREEN after I submit my
patch, but I thought it might need to debug again some time later, so
it was kept as it was until Samuel's "Move" change.

On Sun, Nov 20, 2016 at 8:20 PM, Philip Hands  wrote:
>
> I'd think that the advantage is that one could start a serial install up
> to the point that the network comes up, and then hijack it onto the ssh
> session so that one gets to see the same install (as well as any other
> shells you might have started).
>
> That way, if you think you've preseeded all the pre-network stuff, there
> would be a session to look at via serial if it never gets to the
> network.
>
> Perhaps this is not a real scenario though (I've not played with SSH
> connections to d-i, so I don't know what happens when you log in and
> debconf is already active on the console)

This spec will be fantastic if it's able to be implemented.

On Mon, Nov 21, 2016 at 1:22 AM, Samuel Thibault  wrote:
>
> Mmm, that's a nice idea indeed.  I've eventually uploaded the -x fix,
> which gives us that behavior, and also allowing several people to follow
> the installation, interact, etc.

Thanks for your fixes!
I see another TERMCAP fix related to screen support. So you're really
appreciated!

I'll test the daily image on my Linkstation NAS.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#844549: network-console broken: no screen to be resumed matching sh

[Samuel Thibault]

Hello,

Philip Hands, on Sun 20 Nov 2016 12:20:38 +0100, wrote:
> Martin Michlmayr  writes:
> 
> > * Samuel Thibault  [2016-11-16 23:03]:
> >> But AIUI the intent was to have screen in ssh connections too.
> >
> > I'm not sure what the intent was.  I assume you're right because Roger
> > didn't exclude screen from the network-console images.  Personally,
> > I'm not sure I see the point of screen in that case because you can
> > always open a second SSH connection and open a terminal, but I don't
> > have strong feelings either way if there's an advantage of having
> > screen in such cases.
> 
> I'd think that the advantage is that one could start a serial install up
> to the point that the network comes up, and then hijack it onto the ssh
> session so that one gets to see the same install (as well as any other
> shells you might have started).

Mmm, that's a nice idea indeed.  I've eventually uploaded the -x fix,
which gives us that behavior, and also allowing several people to follow
the installation, interact, etc.

Samuel

Bug#844549: network-console broken: no screen to be resumed matching sh

[Philip Hands]

Martin Michlmayr  writes:

> * Samuel Thibault  [2016-11-16 23:03]:
>> But AIUI the intent was to have screen in ssh connections too.
>
> I'm not sure what the intent was.  I assume you're right because Roger
> didn't exclude screen from the network-console images.  Personally,
> I'm not sure I see the point of screen in that case because you can
> always open a second SSH connection and open a terminal, but I don't
> have strong feelings either way if there's an advantage of having
> screen in such cases.

I'd think that the advantage is that one could start a serial install up
to the point that the network comes up, and then hijack it onto the ssh
session so that one gets to see the same install (as well as any other
shells you might have started).

That way, if you think you've preseeded all the pre-network stuff, there
would be a session to look at via serial if it never gets to the
network.

Perhaps this is not a real scenario though (I've not played with SSH
connections to d-i, so I don't know what happens when you log in and
debconf is already active on the console)

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


signature.asc
Description: PGP signature

Bug#844549: network-console broken: no screen to be resumed matching sh

[Cyril Brulebois]

Hi,

Martin Michlmayr  (2016-11-16):
> * Samuel Thibault  [2016-11-16 23:03]:
> > But AIUI the intent was to have screen in ssh connections too.
> 
> I'm not sure what the intent was.  I assume you're right because Roger
> didn't exclude screen from the network-console images.  Personally,
> I'm not sure I see the point of screen in that case because you can
> always open a second SSH connection and open a terminal, but I don't
> have strong feelings either way if there's an advantage of having
> screen in such cases.
> 
> > I'm also thinking that we perhaps want to add -x when resuming a
> > session, so that somebody can connect trough ssh several times ?
> 
> Yes because right now I get this when I open a 2nd connection:
> 
> debug1: Sending env LC_COLLATE = C
> There is a screen on:
> 1356.network(11/16/16 23:24:12) (Attached)
> 
> Apart from this, the patch works for me.

Then I suggest we get that into git and into unstable sooner rather than
later, so that Stretch Alpha 9 gets a fix. I didn't add an errata entry
for that, but might do so later.


KiBi.


signature.asc
Description: Digital signature

Bug#844549: network-console broken: no screen to be resumed matching sh

[Martin Michlmayr]

* Samuel Thibault  [2016-11-16 23:03]:
> But AIUI the intent was to have screen in ssh connections too.

I'm not sure what the intent was.  I assume you're right because Roger
didn't exclude screen from the network-console images.  Personally,
I'm not sure I see the point of screen in that case because you can
always open a second SSH connection and open a terminal, but I don't
have strong feelings either way if there's an advantage of having
screen in such cases.

> I'm also thinking that we perhaps want to add -x when resuming a
> session, so that somebody can connect trough ssh several times ?

Yes because right now I get this when I open a 2nd connection:

debug1: Sending env LC_COLLATE = C
There is a screen on:
1356.network(11/16/16 23:24:12) (Attached)

Apart from this, the patch works for me.

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#844549: network-console broken: no screen to be resumed matching sh

[Samuel Thibault]

Hello,

Martin Michlmayr, on Wed 16 Nov 2016 12:07:07 -0800, wrote:
> I believe below is the right fix, i.e. start screen when screen exists and
> when we're on serial or when we're NOT on network.

But AIUI the intent was to have screen in ssh connections too.

We could have the case where d-i is first started with the serial
console, running through screen, and enable the network console, which
we'd also want to run through screen.

I'd thus say that we rather want the attached changes, to have one
screen session per terminal type.

I'm also thinking that we perhaps want to add -x when resuming a
session, so that somebody can connect trough ssh several times ?

Samuel
diff --git a/src/lib/debian-installer.d/S70menu 
b/src/lib/debian-installer.d/S70menu
index 7b35fac..2549e29 100644
--- a/src/lib/debian-installer.d/S70menu
+++ b/src/lib/debian-installer.d/S70menu
@@ -14,11 +14,11 @@ else
if [ -x "$screen_bin" -a \( "$TERM_TYPE" = network -o "$TERM_TYPE" = 
serial \) -a "$TERM" != dumb ]; then
# there's GNU/screen binary, run menu in it.
# call this script again with in GNU/screen, possibly in UTF-8 
mode
-   SCREEN_OPT=""
+   SCREEN_OPT="-S $TERM_TYPE"
[ -n "$TERM_UTF8" ] &&
SCREEN_OPT="$SCREEN_OPT -U"
-   [ -d /var/run/screen/S-root -a -e /var/run/screen/S-root/* ] &&
-   SCREEN_OPT="-r" # If GNU/screen is already 
started, just resume it
+   [ -d /var/run/screen/S-root -a -e 
/var/run/screen/S-root/*.$TERM_TYPE ] &&
+   SCREEN_OPT="-r $TERM_TYPE"  # If GNU/screen 
is already started, just resume it
set +e
$screen_bin $SCREEN_OPT sh -c 'printf "\033k%s\033\\" installer 
; /lib/debian-installer/menu'
EXIT=$?

Bug#844549: network-console broken: no screen to be resumed matching sh

[Martin Michlmayr]

* Ben Hutchings  [2016-11-16 21:15]:
> >     rm -f $font
> > -   if [ -x "$screen_bin" -a \( "$TERM_TYPE" = network -o "$TERM_TYPE" = 
> > serial \) -a "$TERM" != dumb ]; then
> > +   if [ -x "$screen_bin" -a \( "$TERM_TYPE" != network -o "$TERM_TYPE" = 
> > serial \) -a "$TERM" != dumb ]; then
> 
> This makes the comparison with 'serial' redundant; the condition will
> be equivalent to:
> 
> [ -x "$screen_bin" -a "$TERM_TYPE" != network -a "$TERM" != dumb ]
> 
> Is that really what we want?

Oh, good point.

I think that's what we want but I'm not sure.  Maybe Roger can
comment.  In his old code, there was also a $NETBOOT_SCREEN variable
which afaict wasn't set set anywhere.

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#844549: network-console broken: no screen to be resumed matching sh

[Ben Hutchings]

On Wed, 2016-11-16 at 12:07 -0800, Martin Michlmayr wrote:
> Package: rootskel
> Version: 1.119
> Severity: serious
> Tags: patch
> 
> Several users have reported to me that the network-console images are
> broken.
> 
> Commit ec6d3c3d79 (Move screen support) moved the screen support
> around and also changed the logic of when screen is used.
> Unfortunately, that change broke all network-console images which now
> lead to:
> 
> installer@192.168.0.102's password:
> There is no screen to be resumed matching sh.
> Connection to 192.168.0.102 closed.
> 
> This is because d-i is already running in screen on the serial console but
> it's active and can't be resumed.
> 
> I believe below is the right fix, i.e. start screen when screen exists and
> when we're on serial or when we're NOT on network.
> 
> Samuel, Roger, does that look correct?
> 
> diff --git a/src/lib/debian-installer.d/S70menu 
> b/src/lib/debian-installer.d/S70menu
> index 7b35fac..14cad7f 100644
> --- a/src/lib/debian-installer.d/S70menu
> +++ b/src/lib/debian-installer.d/S70menu
> @@ -11,7 +11,7 @@ if [ -x "$bterm" ] && [ -e "$font" ] && [ -n "$TERM_UTF8" ] 
> && [ -n "$TERM_FRAME
>   set -e
>  else
>   rm -f $font
> - if [ -x "$screen_bin" -a \( "$TERM_TYPE" = network -o "$TERM_TYPE" = 
> serial \) -a "$TERM" != dumb ]; then
> + if [ -x "$screen_bin" -a \( "$TERM_TYPE" != network -o "$TERM_TYPE" = 
> serial \) -a "$TERM" != dumb ]; then

This makes the comparison with 'serial' redundant; the condition will
be equivalent to:

[ -x "$screen_bin" -a "$TERM_TYPE" != network -a "$TERM" != dumb ]

Is that really what we want?

Ben.

>   # there's GNU/screen binary, run menu in it.
> >     # call this script again with in GNU/screen, possibly in UTF-8 
> > mode
> >     SCREEN_OPT=""
> 
-- 
Ben Hutchings
Time is nature's way of making sure that everything doesn't happen at
once.


signature.asc
Description: This is a digitally signed message part

Bug#844549: network-console broken: no screen to be resumed matching sh

[Martin Michlmayr]

Package: rootskel
Version: 1.119
Severity: serious
Tags: patch

Several users have reported to me that the network-console images are
broken.

Commit ec6d3c3d79 (Move screen support) moved the screen support
around and also changed the logic of when screen is used.
Unfortunately, that change broke all network-console images which now
lead to:

installer@192.168.0.102's password:
There is no screen to be resumed matching sh.
Connection to 192.168.0.102 closed.

This is because d-i is already running in screen on the serial console but
it's active and can't be resumed.

I believe below is the right fix, i.e. start screen when screen exists and
when we're on serial or when we're NOT on network.

Samuel, Roger, does that look correct?

diff --git a/src/lib/debian-installer.d/S70menu 
b/src/lib/debian-installer.d/S70menu
index 7b35fac..14cad7f 100644
--- a/src/lib/debian-installer.d/S70menu
+++ b/src/lib/debian-installer.d/S70menu
@@ -11,7 +11,7 @@ if [ -x "$bterm" ] && [ -e "$font" ] && [ -n "$TERM_UTF8" ] 
&& [ -n "$TERM_FRAME
set -e
 else
rm -f $font
-   if [ -x "$screen_bin" -a \( "$TERM_TYPE" = network -o "$TERM_TYPE" = 
serial \) -a "$TERM" != dumb ]; then
+   if [ -x "$screen_bin" -a \( "$TERM_TYPE" != network -o "$TERM_TYPE" = 
serial \) -a "$TERM" != dumb ]; then
# there's GNU/screen binary, run menu in it.
# call this script again with in GNU/screen, possibly in UTF-8 
mode
SCREEN_OPT=""

-- 
Martin Michlmayr
http://www.cyrius.com/