Bug#844549: network-console broken: no screen to be resumed matching sh
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
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
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
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
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
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
* 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
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
* 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
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
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/