From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1NIgJE-0001U9-Mt for garchives@archives.gentoo.org; Thu, 10 Dec 2009 10:31:44 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B11CFE0762; Thu, 10 Dec 2009 10:31:07 +0000 (UTC) Received: from mail.muc.de (colin.muc.de [193.149.48.1]) by pigeon.gentoo.org (Postfix) with ESMTP id 3EE4BE0762 for ; Thu, 10 Dec 2009 10:31:07 +0000 (UTC) Received: (qmail 54456 invoked by uid 3782); 10 Dec 2009 10:31:06 -0000 Received: from acm.muc.de (pD9E51273.dip.t-dialin.net [217.229.18.115]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Thu, 10 Dec 2009 11:31:05 +0100 Received: (qmail 4482 invoked by uid 1000); 10 Dec 2009 10:36:41 -0000 Date: Thu, 10 Dec 2009 10:36:41 +0000 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Problems setting up sshd on an installation kernel Message-ID: <20091210103641.GB1504@muc.de> References: <20091206144836.GA2599@muc.de> <200912091743.50847.alan.mckinnon@gmail.com> <20091209164611.GE8387@muc.de> <200912092142.56433.alan.mckinnon@gmail.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Archives-Salt: 83cb44c2-f68c-4f3c-865f-eda1bb5ae8dd X-Archives-Hash: 3554eabe991ce4d579a9b01dde3bc650 Hi, Stroller, On Wed, Dec 09, 2009 at 09:57:18PM +0000, Stroller wrote: > On 9 Dec 2009, at 19:42, Alan McKinnon wrote: > >... > >Installation is supposed to be an atomic operation - it starts then > >continues till it ends. It either fully completes or is considered to > >not have happened, meaning that persistence is diametrically opposed > >to what an install is. It's analogous to a compile - terminating > >compilation at some arbitrary point then picking up from where it > >ended at some later point is just not supported. Possible yes, but > >not supported by default. > I'd disagree with you on that point, assuming I'm reading you right. > If a compile fails it shouldn't be an "unsupported" situation. One > should be able to reemerge the package, possibly after emerging a > required dependency first. That should work just fine (and surely it > always does?). > Likewise it's not at all uncommon to make a mistake during the > installation process - to miss out an essential kernel driver or > package, and find that the installation fails to boot. The way I > interpret your statement is that the supported remedy is to start > again completely from scratch. Clearly this is not what one does - one > boots again with the LiveCD, chroots into the installation, makes the > fix and then reboots again to see if the system is now fixed. Every > new Gentoo user has to do this a number of times, it is our standard > advice to them, and we, as experienced users, will still have to do > the same thing occasionally due to our own oversights. Thanks! ;-) > However, I would agree with you that resolving Alan Mackenzie's > problems with ssh should not be a priority. For filesystem checking's sake! My personal problem has been solved. The /dev directory in the newly chrooted system is broken. I simply asked the project to fix it, provided the fix, and the fix is replacing 6 characters in a file with 6 different characters. Now, at this stage, people say "it isn't broken, because you can do everything in it that we've decided you need to do.". Let's just say this isn't in the spirit of free software. ;-) How did this breakage happen? I would guess that at the time the installation procedure was devised, this line # mount -o bind /dev /mnt/gentoo/dev worked perfectly OK, since /dev didn't have any subdirectories. Some time recently, /dev acquired subdirectories (e.g. /dev/pts), but nobody realised this would render the chrooted system less capable. Now, how much work would it cost to replace that line in the manual with # mount --rbind /dev /mnt/gentoo/dev , compared with the cost of all this correspondence? Instead, the maintainer spent all his energy telling me I'm stupid for wanting to do what I wanted to do. > The "standard" procedure should be written for a user sitting in front > of the machine on which Gentoo is being installed. Installing via SSH > is an "advanced" procedure and should be considered to be undertaken > by users who know what they're doing. The requirement to rarely remove > a line from ~/.ssh/known_hosts is really not much hassle. The machine I was installing on was a laptop with no available desk top to place it on. Therefore I decided to get SSH up and running as early as possible so as to do the bulk of the installation from my nice comfy desktop, monitor and keyboard. Starting sshd from inside the chrooted system was obviously the Right Thing. > I am somewhat surprised that Mr Mackenzie managed to waste as much > time as 10 hours attempting to SSH into the "wrong" environment, .... That's starting from "ssh doesn't work", realising that the ssh server was validating my password (or key, I've forgotten which), and then doing nothing. It's the time taken to go through sshd_config looking for stupidities. It's the time taken to read various manual pages, try out various methods of dumping debug info, to the point of getting the vague irritating error message: "file not found". It's the time taken to set up logging facilities, on the (false) hypothesis that it couldn't find a logging file. It's the time taken to post my problem on comp.os.linux.setup, and fail to get an answer there. It's the time taken to post the problem again on this mailing list, and get the answer from Joshua, to whom I'm most grateful. > .... as it has never occurred to me to do it that way around, and > Florian posted appropriate advice to resolve the problem less than 2 > hours after Alan's original post. > I think this is typical of the kind of mistake we all make and learn > from - we have all wasted 10 hours on some occasion, only to kick > ourselves afterwards. When we do this we learn never again to make the > same mistake. With all due respect, it wasn't my mistake, or if you disagree here we'll just have to agree to disagree ;-). /dev is broken. > On 9 Dec 2009, at 16:46, Alan Mackenzie wrote: > >However, setting up /dev completely (with --rbind) costs nothing, adds > >capability, and takes nothing away. > It is not clear to me that this is the "obvious" and "optimal" > solution. It may be. I cannot foresee whether it may introduce side- > effects. I can. There won't be any. Think about it, before /dev/ acquired subdirectories, having a fully functional /dev didn't have negative side effects. So why should restoring it to full functionality have side effects now? > Stroller. -- Alan Mackenzie (Nuremberg, Germany).