Bug#458154: Processed: Re: Bug#458154: network-console: long time-out time during install
retitle 458154 [NSLU2] ssh connection should not time out
tags 458154 + moreinfo
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
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
> >> 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
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