Bug#458154: Processed: Re: Bug#458154: network-console: long time-out time during install

[Frans Pop <elendil@planet.nl>]

retitle 458154 [NSLU2] ssh connection should not time out
tags 458154 + moreinfo
thanks

On Friday 04 January 2008, G. Del Merritt wrote:
> Please note: I was not able to recover "gracefully" from the timeout.

That is expected. As the installation process itself runs almost entirely in 
memory and also all "state" information is kept completely in memory, it is 
extremely hard to reliably support resuming installations from a random 
point.

However, you _could_ certainly have resumed the installation from certain 
points after starting a new session:
- it is always safe to resume by starting partitioning again
- it is even possible to restart base installation, though the installer
  may warn that "the base system is dirty"
- once you have successfully passed the "base installation" phase, you
  can resume any step after it

Note that you may have to select steps manually from the main menu when 
repeating multiple steps that had already been completed (which means 
changing to medium or low debconf priority).

If the installer displays real errors, then this should be taken as a sign 
that the installation has been corrupted to such an extend that resuming is 
not possible.

> >> retitle 458154 network-console: long time-out time during install
>
> Really?  I think the prior title was more appropriate: during an
> install, the ssh connection should not time out.

I agree. Changed back.

> >> tags 458154 -unreproducible
>
> No, this was completely reproducible.  It happened to me - identically -
> at least three times.  It only stopped being a problem when I added this
> to my .ssh/config on the host I was using to connect to my slug:

Well, the tag was _removed_, so that should actually make you happy :-)

However, the fact remains that _we_ have so far not been able to reproduce 
the issue. As I've said earlier, I've had an SSH install sitting unused for 
over 4 hours without the connection being lost, with basically default SSH 
settings both on the SSH client machine and in the installer.

So the question still is _why_ ssh drops the connection in your case.
AFAICT from reading the SSH documentation, the default SSH settings that are 
used in the installer do _not_ poll the client to see if it is still there, 
so it is unlikely that the server is responsible for dropping the 
connection.

Maybe you could try running your ssh client with maximum verbosity options 
to see what is going on?

Also, the solution you propose is on the _client_ side, so is not something 
we can fix in the installer. The only thing we could do at this point is 
document it.

Cheers,
FJP