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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
