Re: [RFC] Call for review of GNU/screen support for D-I (was Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap)
On May 21, 2016, at 3:05 AM, Roger Shimizu wrote: >> I didn’t try disconnecting, letting it run for a while un-attended, then >> reconnecting because I didn’t have a clear idea of how to do that. >> Specifically, what happens if I type ctl-A ctl-D? Do I get disconnected >> from just the one window or all four of them? If I get disconnected from >> all of them, what will I find myself talking to? Is it an interactive shell >> that I can re-connect to the running disconnected screen by typing >> “screen -R” >> or something else? >> >> If I’m disconnected, can I drop the “cu” connection without causing havoc to >> the running install? If I later re-instate the “cu”, what happens then? Do >> I automatically get my screen session back again, or is there something I >> need to do to to make that happen? > > Resume when re-connecting is mainly for network-console (via SSH). > "screen -r" is done by debian-installer, user don't need anything extra. > >> These are all experiments I could have done during the install, but I >> refrained because I wanted to verify that there weren’t any difficulties >> associated with simply running the installer inside screen. Next time I get >> a few hours, I’ll try installing again and experiment with >> dis-/re-connecting. As you say, disconnecting and re-connecting are things that make more sense with the ssh network-console. I’ll give that a try next time I feel adventurous and have a couple of hours to kill experimenting! > > I really appreciate you helping to confirm it working on other devices > than I have on hand. No problem! It’s always fun trying out a new and useful feature.
Re: [RFC] Call for review of GNU/screen support for D-I (was Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap)
On May 21, 2016, at 3:05 AM, Roger Shimizu wrote: >> First observation is that the way I normally do installations on this >> machine (I keep it around for exactly this kind of testing, so I do a fair >> number of installations on it) is to run screen as a terminal emulator on a >> desktop machine that is connected to the Plug via a USB serial connection. >> If I did that for this experiment, I’d wind up with screen running on the >> Plug inside of screen running on the Desktop and the thought of keeping >> track of all the levels of ctl-A gave me nightmares. > > Indeed. It will be messed up if running screen inside screen. > If you have any suggestion to avoid this, just let me know. > >> So, I changed to using “cu” to run the USB serial connection. That worked >> well enough. This, or some other workaround, will have to be described in the documentation for the feature. I suggest that it go in the release notes for the first official release to contain the feature. A wiki page is probably also appropriate. >> >> The installation proceeded smoothly while I experimented with the ctl-A >> <1-4> options. It would have been nice to have the option of a more >> spacious work-area — larger than 24x80 — but that’s a minor issue. > > I find this size of screen limitation, too. > But I think this limitation is not introduced by GNU/screen, it exists before. The kernel assumes that the default size of a serial console should be 24x80. This probably goes back to the early days of video terminals with UNIX in the 1980s. It is possible to change the assumed size of a serial console using the “stty” command with its “rows” and “columns” options. Unfortunately doing so doesn’t inform “screen” of the new size — you have to do that yourself by resizing the terminal window it’s running in. I can’t think of any way to automate that rather complicated process, so I guess the only sensible approach is to accept 24x80 as a given limitation and just live with it. After all, who are we to argue with 30 years of history! (-: Enjoy! Rick
Re: [RFC] Call for review of GNU/screen support for D-I (was Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap)
Dear Rick, Thanks for your testing report! On Sat, May 14, 2016 at 4:18 PM, Rick Thomas wrote: > > Hi Roger, > > I got a chance to try it on my SheevaPlug. > > Executive summary: It worked as advertised and all the features you mentioned > seem to work (except I didn’t try disconnect and reconnect — see below for > details). I really liked being able to switch between VTs with a couple of > keystrokes! > > Here’s what I did and why I did it: > > First observation is that the way I normally do installations on this machine > (I keep it around for exactly this kind of testing, so I do a fair number of > installations on it) is to run screen as a terminal emulator on a desktop > machine that is connected to the Plug via a USB serial connection. If I did > that for this experiment, I’d wind up with screen running on the Plug inside > of screen running on the Desktop and the thought of keeping track of all the > levels of ctl-A gave me nightmares. Indeed. It will be messed up if running screen inside screen. If you have any suggestion to avoid this, just let me know. > So, I changed to using “cu” to run the USB serial connection. That worked > well enough. > > The installation proceeded smoothly while I experimented with the ctl-A <1-4> > options. It would have been nice to have the option of a more spacious > work-area — larger than 24x80 — but that’s a minor issue. I find this size of screen limitation, too. But I think this limitation is not introduced by GNU/screen, it exists before. > I didn’t try disconnecting, letting it run for a while un-attended, then > reconnecting because I didn’t have a clear idea of how to do that. > Specifically, what happens if I type ctl-A ctl-D? Do I get disconnected from > just the one window or all four of them? If I get disconnected from all of > them, what will I find myself talking to? Is it an interactive shell that I > can re-connect to the running disconnected screen by typing >“screen -R” > or something else? > > If I’m disconnected, can I drop the “cu” connection without causing havoc to > the running install? If I later re-instate the “cu”, what happens then? Do I > automatically get my screen session back again, or is there something I need > to do to to make that happen? Resume when re-connecting is mainly for network-console (via SSH). "screen -r" is done by debian-installer, user don't need anything extra. > These are all experiments I could have done during the install, but I > refrained because I wanted to verify that there weren’t any difficulties > associated with simply running the installer inside screen. Next time I get > a few hours, I’ll try installing again and experiment with dis-/re-connecting. I really appreciate you helping to confirm it working on other devices than I have on hand. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: [RFC] Call for review of GNU/screen support for D-I (was Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap)
On May 9, 2016, at 8:30 AM, Roger Shimizu wrote: > On Mon, May 9, 2016 at 4:21 PM, Rick Thomas wrote: >> Thanks, Roger! >> >> I’ll give it a try on one of my sheevaplug boxes. >> >> As I understand it, I will follow the instructions on Martin’s page at >>https://www.cyrius.com/debian/kirkwood/sheevaplug/install/ >> using the uImage and uInitrd files from your page at >> >> https://drive.google.com/folderview?id=0BzkkBTJUgwbhdjJqY1ZjY2xWem8&tid=0BzkkBTJUgwbhTldTd18yTFZCQ2s#list > > Thanks for helping to test! > > There're 4 folders in my local build for sheevaplug: > kirkwood/netboot/marvell/sheevaplug > kirkwood/netboot/marvell/sheevaplug-esata > kirkwood/netboot/screen/marvell/sheevaplug > kirkwood/netboot/screen/marvell/sheevaplug-esata > > The former two is the same as current d-i daily, without GNU/screen. > The latter two is with GNU/screen support, which you should use. > > So, here it is: > > https://drive.google.com/folderview?id=0BzkkBTJUgwbhM29zYnUxckQzUUk&tid=0BzkkBTJUgwbhTldTd18yTFZCQ2s#list > > Cheers, > -- > Roger Shimizu, GMT +9 Tokyo > PGP/GPG: 17B3ACB1 Hi Roger, I got a chance to try it on my SheevaPlug. Executive summary: It worked as advertised and all the features you mentioned seem to work (except I didn’t try disconnect and reconnect — see below for details). I really liked being able to switch between VTs with a couple of keystrokes! Here’s what I did and why I did it: First observation is that the way I normally do installations on this machine (I keep it around for exactly this kind of testing, so I do a fair number of installations on it) is to run screen as a terminal emulator on a desktop machine that is connected to the Plug via a USB serial connection. If I did that for this experiment, I’d wind up with screen running on the Plug inside of screen running on the Desktop and the thought of keeping track of all the levels of ctl-A gave me nightmares. So, I changed to using “cu” to run the USB serial connection. That worked well enough. The installation proceeded smoothly while I experimented with the ctl-A <1-4> options. It would have been nice to have the option of a more spacious work-area — larger than 24x80 — but that’s a minor issue. I didn’t try disconnecting, letting it run for a while un-attended, then reconnecting because I didn’t have a clear idea of how to do that. Specifically, what happens if I type ctl-A ctl-D? Do I get disconnected from just the one window or all four of them? If I get disconnected from all of them, what will I find myself talking to? Is it an interactive shell that I can re-connect to the running disconnected screen by typing “screen -R” or something else? If I’m disconnected, can I drop the “cu” connection without causing havoc to the running install? If I later re-instate the “cu”, what happens then? Do I automatically get my screen session back again, or is there something I need to do to to make that happen? These are all experiments I could have done during the install, but I refrained because I wanted to verify that there weren’t any difficulties associated with simply running the installer inside screen. Next time I get a few hours, I’ll try installing again and experiment with dis-/re-connecting. That’s what I know now… Enjoy! Rick
Re: [RFC] Call for review of GNU/screen support for D-I (was Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap)
On Mon, May 9, 2016 at 4:21 PM, Rick Thomas wrote: > Thanks, Roger! > > I’ll give it a try on one of my sheevaplug boxes. > > As I understand it, I will follow the instructions on Martin’s page at > https://www.cyrius.com/debian/kirkwood/sheevaplug/install/ > using the uImage and uInitrd files from your page at > > https://drive.google.com/folderview?id=0BzkkBTJUgwbhdjJqY1ZjY2xWem8&tid=0BzkkBTJUgwbhTldTd18yTFZCQ2s#list Thanks for helping to test! There're 4 folders in my local build for sheevaplug: kirkwood/netboot/marvell/sheevaplug kirkwood/netboot/marvell/sheevaplug-esata kirkwood/netboot/screen/marvell/sheevaplug kirkwood/netboot/screen/marvell/sheevaplug-esata The former two is the same as current d-i daily, without GNU/screen. The latter two is with GNU/screen support, which you should use. So, here it is: https://drive.google.com/folderview?id=0BzkkBTJUgwbhM29zYnUxckQzUUk&tid=0BzkkBTJUgwbhTldTd18yTFZCQ2s#list Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: [RFC] Call for review of GNU/screen support for D-I (was Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap)
On May 8, 2016, at 10:50 AM, Roger Shimizu wrote: > On Tue, May 3, 2016 at 4:13 AM, Rick Thomas wrote: >> On Mon, May 2, 2016, at 10:01 AM, Roger Shimizu wrote: >>> On Sat, Apr 30, 2016 at 10:02 AM, Rick Thomas wrote: When I’m installing Debian on one of the serial-console-only boxes, such as the SheevaPlug or OpenRD, I usually use the “network console” option that allows me to use ssh to login and run the Debian installer from the comfort of my office chair — away from the cold noisy machine room! If I need to see the logs or test some parameters, I can always ssh again and get another shell window. Of course, I still have to be there at the start-up, to push the “reset” button and use the serial console to handle the initial bootstrap/installation questions before the ssh server becomes available, but that’s only for a few minutes. >> OK, I think I get it now. This would make the serial console >> installation functionally much closer to the "normal" install (e.g. >> desktop machine with video console). The ability to pick up and resume >> a dropped session is an added bonus. >> >> As I said, I'll be happy to help test it. > > I made a local armel build supporting GNU/screen, and uploaded all > files to my g/drive: > https://drive.google.com/folderview?id=0BzkkBTJUgwbhTldTd18yTFZCQ2s#list > > (there're only two local built udeb file in localudebs/ folder: > libtinfo5-udeb_6.0+20160319-2_armel.udeb > screen-udeb_4.3.1-4_armel.udeb > so this will be official after these two packages get uploaded.) > > So you can have a test on your armel devices. > For devices originally use "netboot" image, please use "netboot/screen" image; > for devices originally use "network-console" image, please use > "network-screen" image. > > You should get GNU/screen started when you connect via serial console or SSH. > You can switch windows by "Ctrl-A [1-4]". (press Ctrl-A, release both > keys, and press the window number) > All operation is exact same as normal GNU/screen usage. > > If you have any question or suggestion, just feel free to let me know. > Thank you! > > Cheers, > -- > Roger Shimizu, GMT +9 Tokyo > PGP/GPG: 17B3ACB1 Thanks, Roger! I’ll give it a try on one of my sheevaplug boxes. As I understand it, I will follow the instructions on Martin’s page at https://www.cyrius.com/debian/kirkwood/sheevaplug/install/ using the uImage and uInitrd files from your page at https://drive.google.com/folderview?id=0BzkkBTJUgwbhdjJqY1ZjY2xWem8&tid=0BzkkBTJUgwbhTldTd18yTFZCQ2s#list Is that correct? Rick
Re: [RFC] Call for review of GNU/screen support for D-I (was Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap)
On Tue, May 3, 2016 at 4:13 AM, Rick Thomas wrote: > On Mon, May 2, 2016, at 10:01 AM, Roger Shimizu wrote: >> On Sat, Apr 30, 2016 at 10:02 AM, Rick Thomas wrote: >> > When I’m installing Debian on one of the serial-console-only boxes, such >> > as the SheevaPlug or OpenRD, I usually use the “network console” option >> > that allows me to use ssh to login and run the Debian installer from the >> > comfort of my office chair — away from the cold noisy machine room! If I >> > need to see the logs or test some parameters, I can always ssh again and >> > get another shell window. Of course, I still have to be there at the >> > start-up, to push the “reset” button and use the serial console to handle >> > the initial bootstrap/installation questions before the ssh server becomes >> > available, but that’s only for a few minutes. >> > > OK, I think I get it now. This would make the serial console > installation functionally much closer to the "normal" install (e.g. > desktop machine with video console). The ability to pick up and resume > a dropped session is an added bonus. > > As I said, I'll be happy to help test it. I made a local armel build supporting GNU/screen, and uploaded all files to my g/drive: https://drive.google.com/folderview?id=0BzkkBTJUgwbhTldTd18yTFZCQ2s#list (there're only two local built udeb file in localudebs/ folder: libtinfo5-udeb_6.0+20160319-2_armel.udeb screen-udeb_4.3.1-4_armel.udeb so this will be official after these two packages get uploaded.) So you can have a test on your armel devices. For devices originally use "netboot" image, please use "netboot/screen" image; for devices originally use "network-console" image, please use "network-screen" image. You should get GNU/screen started when you connect via serial console or SSH. You can switch windows by "Ctrl-A [1-4]". (press Ctrl-A, release both keys, and press the window number) All operation is exact same as normal GNU/screen usage. If you have any question or suggestion, just feel free to let me know. Thank you! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: [RFC] Call for review of GNU/screen support for D-I (was Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap)
On Tue, May 3, 2016 at 1:59 AM, Axel Beckert wrote: > Hi Roger, > > Roger Shimizu wrote: >> However, there's even no network-console (SSH) target for i386/amd64 yet [6]. > […] >> [6] >> https://anonscm.debian.org/cgit/d-i/debian-installer.git/tree/build/config/i386 > > Maybe that's the wrong place to look for. Because I'm very sure I used > that feature already on Intel x86 architectures. And the required > packages exist for quite a while now: Dear Axel, Another place to look is: https://anonscm.debian.org/cgit/d-i/debian-installer.git/tree/build/pkg-lists But still no "network-console" for x86 series. Could you tell which image did you installed on x86 by SSH? Because those settings might change by time. Knowing the filename of working image will help to find the exact config file. Thank you! -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: [RFC] Call for review of GNU/screen support for D-I (was Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap)
On Mon, May 2, 2016, at 10:01 AM, Roger Shimizu wrote: > On Sat, Apr 30, 2016 at 10:02 AM, Rick Thomas wrote: > > When I’m installing Debian on one of the serial-console-only boxes, such as > > the SheevaPlug or OpenRD, I usually use the “network console” option that > > allows me to use ssh to login and run the Debian installer from the comfort > > of my office chair — away from the cold noisy machine room! If I need to > > see the logs or test some parameters, I can always ssh again and get > > another shell window. Of course, I still have to be there at the start-up, > > to push the “reset” button and use the serial console to handle the initial > > bootstrap/installation questions before the ssh server becomes available, > > but that’s only for a few minutes. > > > > How does your proposed change alter that? > > As Martin pointed before (on my original RFC post), screen support > seems not as important for network-console (SSH) target, compared to > netboot (serial console) target. > > But here's some improvement by introducing screen to network-console: > - you only need to have one SSH session to the device you run D-I, and > you can have multiple task in one physical window: 1. run d-i; 2. have > command line; 3. check install log > - if your SSH connection is lost, by any reason, you can reconnect > SSH, and screen will resume the session for you. > > Are you convinced? OK, I think I get it now. This would make the serial console installation functionally much closer to the "normal" install (e.g. desktop machine with video console). The ability to pick up and resume a dropped session is an added bonus. As I said, I'll be happy to help test it. Enjoy! Rick
Re: [RFC] Call for review of GNU/screen support for D-I (was Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap)
On Sat, Apr 30, 2016 at 10:02 AM, Rick Thomas wrote: > When I’m installing Debian on one of the serial-console-only boxes, such as > the SheevaPlug or OpenRD, I usually use the “network console” option that > allows me to use ssh to login and run the Debian installer from the comfort > of my office chair — away from the cold noisy machine room! If I need to see > the logs or test some parameters, I can always ssh again and get another > shell window. Of course, I still have to be there at the start-up, to push > the “reset” button and use the serial console to handle the initial > bootstrap/installation questions before the ssh server becomes available, but > that’s only for a few minutes. > > How does your proposed change alter that? As Martin pointed before (on my original RFC post), screen support seems not as important for network-console (SSH) target, compared to netboot (serial console) target. But here's some improvement by introducing screen to network-console: - you only need to have one SSH session to the device you run D-I, and you can have multiple task in one physical window: 1. run d-i; 2. have command line; 3. check install log - if your SSH connection is lost, by any reason, you can reconnect SSH, and screen will resume the session for you. Are you convinced? Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: [RFC] Call for review of GNU/screen support for D-I (was Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap)
Hi Roger, Roger Shimizu wrote: > However, there's even no network-console (SSH) target for i386/amd64 yet [6]. […] > [6] > https://anonscm.debian.org/cgit/d-i/debian-installer.git/tree/build/config/i386 Maybe that's the wrong place to look for. Because I'm very sure I used that feature already on Intel x86 architectures. And the required packages exist for quite a while now: https://packages.debian.org/search?keywords=network-console Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Re: [RFC] Call for review of GNU/screen support for D-I (was Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap)
Dear Ben, Axel, Philipp, Thanks so much for your comments! On Sat, Apr 30, 2016 at 3:28 AM, Ben Hutchings wrote: > For a rack-mounted server, it is usually possible to attach a > (switched) keyboard and monitor, but there is contention for those > resources and machine rooms are not comfortable places for humans. > IP-KVMs are an option but often awkward to use and may rely on plain- > text authentication, Java applets and other insecure technologies. So > an ssh server and screen could be very useful on PCs too. Glad to know that my software solution can replace some hardware (IP-KVM). However, there's even no network-console (SSH) target for i386/amd64 yet [6]. So this use case, together with screen support, would be added from stretch. I'll skip network-console, and only add a "network-screen" target for i386/amd64. [6] https://anonscm.debian.org/cgit/d-i/debian-installer.git/tree/build/config/i386 On Sun, May 1, 2016 at 12:12 AM, Axel Beckert wrote: > I disagree that screen support for i386 in unnecessary. There are > rather popular x86 boards which only have a serial console and no VGA, > e.g.: > > http://www.pcengines.ch/alix3d2.htm (actually all but two models on > http://www.pcengines.ch/alix.htm) > http://www.pcengines.ch/apu.htm > http://www.pcengines.ch/apu2b2.htm > > So I think adding screen support to D-I on at least i386, too, would > add some value. Thanks for those links for products! Easy for me to understand with spec tables and pictures. So for those boards with serial ports, Debian can be installed by "netboot" image, which is called "netboot-screen" image after the screen support. (Of course network-screen image also can be used by SSH connection) On Mon, May 2, 2016 at 2:22 AM, Philipp Kern wrote: > Also servers with IPMI that only have a virtual serial port. (Yes, there > might be console redirection, but that doesn't always work or might > require an additional license.) I think screen support is worthwhile > everywhere. Or at least not at all detrimental. I'd, however, put an > emphasis on turning it on when the terminal is a serial or remote > console. Although it might not matter too much to have it always on… Good to know my solution can be used to save proprietary software license! I'm not sure about IPMI, but I guess either serial way (netboot-screen) or SSH way (network-screen) should be suitable for that use case. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: [RFC] Call for review of GNU/screen support for D-I (was Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap)
On Sat, Apr 30, 2016 at 05:12:25PM +0200, Axel Beckert wrote: > Roger Shimizu wrote: > > For example, I know for it's necessary to have GNU/screen support for > > armel/armhf/arm64 platform; howover, for i386/amd64 PC, it usually > > have CRT/LCD and physical keyboard attached, so it's easily to switch > > console by Alt-F1 ~ F4 during debian installing.So for i386/amd64 > > netboot targets, GNU/screen support is considered unnecessary. > I disagree that screen support for i386 in unnecessary. There are > rather popular x86 boards which only have a serial console and no VGA, > e.g.: > > http://www.pcengines.ch/alix3d2.htm (actually all but two models on >http://www.pcengines.ch/alix.htm) > http://www.pcengines.ch/apu.htm > http://www.pcengines.ch/apu2b2.htm > > So I think adding screen support to D-I on at least i386, too, would > add some value. Also servers with IPMI that only have a virtual serial port. (Yes, there might be console redirection, but that doesn't always work or might require an additional license.) I think screen support is worthwhile everywhere. Or at least not at all detrimental. I'd, however, put an emphasis on turning it on when the terminal is a serial or remote console. Although it might not matter too much to have it always on… Kind regards Philipp Kern
Re: [RFC] Call for review of GNU/screen support for D-I (was Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap)
Hi Roger, Roger Shimizu wrote: > For example, I know for it's necessary to have GNU/screen support for > armel/armhf/arm64 platform; howover, for i386/amd64 PC, it usually > have CRT/LCD and physical keyboard attached, so it's easily to switch > console by Alt-F1 ~ F4 during debian installing.So for i386/amd64 > netboot targets, GNU/screen support is considered unnecessary. I disagree that screen support for i386 in unnecessary. There are rather popular x86 boards which only have a serial console and no VGA, e.g.: http://www.pcengines.ch/alix3d2.htm (actually all but two models on http://www.pcengines.ch/alix.htm) http://www.pcengines.ch/apu.htm http://www.pcengines.ch/apu2b2.htm So I think adding screen support to D-I on at least i386, too, would add some value. Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Re: [RFC] Call for review of GNU/screen support for D-I (was Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap)
On Apr 29, 2016, at 7:38 AM, Roger Shimizu wrote: > Dear Rick, > > Thanks for your interest in GNU/screen support for D-I activity! > > > I called for review because I want to confirm that those changes are > necessary. > > For example, I know for it's necessary to have GNU/screen support for > armel/armhf/arm64 platform; howover, for i386/amd64 PC, it usually > have CRT/LCD and physical keyboard attached, so it's easily to switch > console by Alt-F1 ~ F4 during debian installing.So for i386/amd64 > netboot targets, GNU/screen support is considered unnecessary. > I want to know this kind of situation for other ARCHs. > > You mentioned Macintosh powerpc -32/-64, I think it's the same > situation like i386/amd64 from point of view of GNU/screen support. > They're unlikely needed. > > For other arm devices you have, I guess it's necessary. > And I'll inform you when the testing images are ready, with instructions. :-D Hi Roger, You’re right, the old Mac hardware is mostly intended for “desktop” use, so you can attach a keyboard/mouse/video to it and install in the standard way. Apple did make a G5-based rack-mount server, but even it had a DVI video port. When I’m installing Debian on one of the serial-console-only boxes, such as the SheevaPlug or OpenRD, I usually use the “network console” option that allows me to use ssh to login and run the Debian installer from the comfort of my office chair — away from the cold noisy machine room! If I need to see the logs or test some parameters, I can always ssh again and get another shell window. Of course, I still have to be there at the start-up, to push the “reset” button and use the serial console to handle the initial bootstrap/installation questions before the ssh server becomes available, but that’s only for a few minutes. How does your proposed change alter that? Enjoy! Rick
Re: [RFC] Call for review of GNU/screen support for D-I (was Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap)
On Fri, 2016-04-29 at 23:38 +0900, Roger Shimizu wrote: > Dear Rick, > > Thanks for your interest in GNU/screen support for D-I activity! > > On Fri, Apr 29, 2016 at 8:17 PM, Rick Thomas wrote: > > > > > > On Apr 24, 2016, at 9:00 AM, Roger Shimizu wrote: > > > > > > > > - ask users of all ARCHs related to check whether the GNU/screen is > > > working well under d-i environment. Maybe need to add a wiki to track > > > things efficiently. > > > > > > What do you think of my plan? > > > Any suggestion is appreciated. Thank you! > > I’m willing to test on a few architectures: Macintosh powerpc-32bit and > > powerpc-64bit, Cubox-i (armhf), Sheevaplug (armel), OpenRC (armel). > > > > If you want me to test any of those, I’ll need some info: > > > > 1) What is this change supposed to accomplish? Do you have a canonical > > use-case I can attempt to model? > > 2) What kinds of test do you want me to perform? And what results are you > > expecting? > Actually, it's in "call for review" status, instead of "call for > testing", because there's no built images ready yet. > Of course you can build everything yourself, but it may take 1-2 hours > for one ARCH, which I think it's too long. > > I called for review because I want to confirm that those changes are > necessary. > > For example, I know for it's necessary to have GNU/screen support for > armel/armhf/arm64 platform; howover, for i386/amd64 PC, it usually > have CRT/LCD and physical keyboard attached, [...] For a rack-mounted server, it is usually possible to attach a (switched) keyboard and monitor, but there is contention for those resources and machine rooms are not comfortable places for humans. IP-KVMs are an option but often awkward to use and may rely on plain- text authentication, Java applets and other insecure technologies. So an ssh server and screen could be very useful on PCs too. Ben. -- Ben Hutchings Tomorrow will be cancelled due to lack of interest. signature.asc Description: This is a digitally signed message part
Re: [RFC] Call for review of GNU/screen support for D-I (was Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap)
Dear Rick, Thanks for your interest in GNU/screen support for D-I activity! On Fri, Apr 29, 2016 at 8:17 PM, Rick Thomas wrote: > > On Apr 24, 2016, at 9:00 AM, Roger Shimizu wrote: > >> - ask users of all ARCHs related to check whether the GNU/screen is >> working well under d-i environment. Maybe need to add a wiki to track >> things efficiently. >> >> What do you think of my plan? >> Any suggestion is appreciated. Thank you! > > I’m willing to test on a few architectures: Macintosh powerpc-32bit and > powerpc-64bit, Cubox-i (armhf), Sheevaplug (armel), OpenRC (armel). > > If you want me to test any of those, I’ll need some info: > > 1) What is this change supposed to accomplish? Do you have a canonical > use-case I can attempt to model? > 2) What kinds of test do you want me to perform? And what results are you > expecting? Actually, it's in "call for review" status, instead of "call for testing", because there's no built images ready yet. Of course you can build everything yourself, but it may take 1-2 hours for one ARCH, which I think it's too long. I called for review because I want to confirm that those changes are necessary. For example, I know for it's necessary to have GNU/screen support for armel/armhf/arm64 platform; howover, for i386/amd64 PC, it usually have CRT/LCD and physical keyboard attached, so it's easily to switch console by Alt-F1 ~ F4 during debian installing.So for i386/amd64 netboot targets, GNU/screen support is considered unnecessary. I want to know this kind of situation for other ARCHs. You mentioned Macintosh powerpc -32/-64, I think it's the same situation like i386/amd64 from point of view of GNU/screen support. They're unlikely needed. For other arm devices you have, I guess it's necessary. And I'll inform you when the testing images are ready, with instructions. :-D Thank you! -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: [RFC] Call for review of GNU/screen support for D-I (was Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap)
On Apr 24, 2016, at 9:00 AM, Roger Shimizu wrote: > - ask users of all ARCHs related to check whether the GNU/screen is > working well under d-i environment. Maybe need to add a wiki to track > things efficiently. > > What do you think of my plan? > Any suggestion is appreciated. Thank you! I’m willing to test on a few architectures: Macintosh powerpc-32bit and powerpc-64bit, Cubox-i (armhf), Sheevaplug (armel), OpenRC (armel). If you want me to test any of those, I’ll need some info: 1) What is this change supposed to accomplish? Do you have a canonical use-case I can attempt to model? 2) What kinds of test do you want me to perform? And what results are you expecting? Thanks for you efforts! Rick
[RFC] Call for review of GNU/screen support for D-I (was Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap)
[Resend: change subject line to meet with current topic] [Add a few people ever expressed interest in GNU/screen for d-i work] On Tue, Apr 12, 2016 at 7:50 AM, Martin Michlmayr wrote: > * Roger Shimizu [2016-04-12 00:48]: >> I was about to write a list on pros and cons, but I only find pros, >> with some reasons/explanation. >> >> - Main purpose is to get ready for screen support, which surely cannot >> fit into qnap's image. > > Sorry for being unclear: I have no objections to introducing the -qnap > or -tiny image. I can see why this makes sense. > > But you also merge the orion5x and kirkwood images into marvell images > and I see a number of downsides with that (and no obvious advantages). > > Can you leave orion5x and kirkwood alone and introduce an > orion5x-qnap, without converting everything to marvell, or do you see > any advantages of combining orion5x and kirkwood into marvell? (If > there are advantages, please let me know.) Thanks for your feedback! I have a new idea which don't need to touch current orion5x/kirkwood anymore. It introduces two new targets: - netboot-screen, which add screen-udeb to previous netboot target - network-screen, which add screen-udeb to previous network-console target - previous netboot and network-console target is kept as it is So qnap images are only removed from armel/orion5x/network-screen.cfg, due to size issue. But it still exists in armel/orion5x/network-console.cfg. I have push the change to branch "netboot-screen" [5]. I don't have experience other than i386/amd64/armel, so for other ARCHs, I need other's help review and test. I plan to - collect feedback of code review before screen-udeb [1] and its dependency [2] get released. Both of the package are tagged as "pending", so I expect them to be released within 2-4 weeks. - modify the change [5] based on review feedback, and push it to master so we can check daily builds are fine for all ARCHs - ask users of all ARCHs related to check whether the GNU/screen is working well under d-i environment. Maybe need to add a wiki to track things efficiently. What do you think of my plan? Any suggestion is appreciated. Thank you! [1] https://bugs.debian.org/819988 [2] https://bugs.debian.org/819397 [5] https://anonscm.debian.org/cgit/d-i/debian-installer.git/commit/?h=netboot-screen&id=302f5f Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
