From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 66B2113827E for ; Mon, 9 Dec 2013 19:54:52 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A1A61E0B71; Mon, 9 Dec 2013 19:54:45 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 99B06E09F5 for ; Mon, 9 Dec 2013 19:54:44 +0000 (UTC) Received: from [192.168.1.13] (pool-72-95-221-222.pitbpa.fios.verizon.net [72.95.221.222]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: zerochaos) by smtp.gentoo.org (Postfix) with ESMTPSA id B1B2733F49C for ; Mon, 9 Dec 2013 19:54:43 +0000 (UTC) Message-ID: <52A62062.9030109@gentoo.org> Date: Mon, 09 Dec 2013 14:56:18 -0500 From: "Rick \"Zero_Chaos\" Farina" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up References: <20131201102015.GA1219@egeo> <20131202202845.GA8574@linux1> <529CF973.2020008@gentoo.org> <529CFAA1.7080608@gentoo.org> <20131203211130.GA31972@linux1> <52A2B788.3040409@gentoo.org> <20131208222552.GA22567@linux1> <52A5D89A.4080506@gentoo.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 9efb2b3c-e537-4e23-b57b-f2eecb243245 X-Archives-Hash: 8e6d85c02355f04d6b556368fa835ff3 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/09/2013 10:28 AM, Rich Freeman wrote: > On Mon, Dec 9, 2013 at 9:50 AM, Rick "Zero_Chaos" Farina > wrote: >> I can honestly say most of the time when setup my arm systems I'm >> unpacking the arm stage3 on an amd64 and then booting the arm device >> with the base stage3 and fixing things from there. I suppose it is >> possible to use qemu to install things, as long as I don't mind >> pretending it's 1999 due to the slow emulation speeds... Yeah, I really >> don't see an improvement here. It works fine for "I'm an amd64 user and >> that's all I'll ever use" but when you start talking about smaller >> arches it really starts to become a hassle imho. > > Ok, now the concern is becoming more clear. You're intending to boot > directly to the stage3 and not chroot into it, and so you want the > stage3 to be a fully-functional userspace, though you don't actually > need it to contain a kernel/bootloader. Correct > > How do you even log into the stage3? Do we not disable the root > password by default? No, we don't disable it. It's trivial to set without chrooting (steev has details in his response and that isn't he point of this thread) > > Can you boot off of the minimal install image instead? Not sure if we > have one of those for ARM. Actually, any boot image that sets up a > network and supports chroot would work fine for your purposes. I do > realize that many (all?) ARM platforms don't have a flexible > bootloader like x86 typically does - so I'll let you speak to what > makes sense here. Sadly no, again covered by steev in his response we don't off anything bootable for arm at all. > > Following the handbook, the network is established by the boot CD and > all you do before chrooting is copy over your resolv.conf. In that > environment there is no need to have a networking system pre-installed > on the stage3. Well hold on there... the handbook doesn't mention anything about emerging your choice of network manager just yet, and when everything including dhcpcd isn't in the stage3 you will need to do more than copy resolv.conf (which honestly I never do anyway) or it won't work very well. > > Oh, and if I'm not mistaken the stage3 is based on the system set > which is established by the profile, so if it made sense to keep > networking around for ARM that would be an option. > I grant this is an option, but what about guys like steev? He has a large stack of arm devices and like 1 amd64 box. What if he wants to put a stage3 on a disk for his amd64 box from his arm box? I'd love to see him emulate an amd64 from his arm to install dhcpcd. Now granted, that's being a little pedantic, as he could probably use one of the gentoo isos available to boot instead, but the point is we are removing software that gives the user a choice under the guise of giving the user a choice. I really don't like the idea of having no networking in the stage3 by default, however, I'm becoming more open minded on what qualifies as networking. What I'm wrestling with is this, what if I want to slap a stage3 on a device and then access it from the network? Almost nothing in my place has a monitor (amd64 and arm alike) and I use one of my two laptops to talk to everything else. Say I want to rebuild a headless machine, what am I supposed to do? Unpack a stage3, install some network manager manually (netifrc for me) and then boot? Granted, we already have to do this for any device which is wifi only as wpa_supplicant isn't in the stage3, but to remove this ability from wired devices as well.... I'm torn, I really don't think it's a great idea. I really feel that while the rest of the world is trying to get more functionality out of their hardware we are trying to save ~200k and possibly crippling user experience in the process. Is removing ~200k really worth the potential downside? Honestly, if we are going on the merits of smaller downloads let's argue about using xz instead of bzip2 for the stages... - -Zero -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSpiBiAAoJEKXdFCfdEflKuWMP/j7S40wYWxGWbI34Ij2U5dSG l11wJYdAP0k9bLs4rhDvJG56EaTyBJJYvfDCz+W2XF01MyNcdQfH2BzqEifp0ZOD kI0x81xzIqpb4YC1KvJXQxStDvs1Nxp3KbCX+Jg2hdkMv4hlHR7NF/g1gUajC8eA 8tKdLcqIz822REqGtShGLYO9cjLaHZhGr/rFlxyK9ReQqj5cCdmEZ1MKN0Kb/DSa gQf+pmdecXXjCbF3N/5eihcQDrKe2UbXuKM/nNaiVw1ETnI+gjn815ofUNCc3Ynu jXZC4jse+MVQC6D6i3ZJi6o1VSlrGJmGDDxBSUtBPc7kSgFnaAz3AYC/izeIFtb9 VNQEmrcDjO5qKdZphc5ht2NW7uOBCZbpMoFmSj70cZK+NhJhaJPWqzUNu3mJLCUF 72W89HCC3oTbpPtMVQHz9F3nmzYhH+QfrEXGd96woTyjcsZYwXvY8UDm486gsdsR aGNJCN34RXQvsLrsJdxJWaHJex5w2UHkBsi5IQkJniD1grq+CModEWiaqfD6Fo/y WXT1LUr3/1cgsLFU3E5VhgdYl873z2oNUHisWR37XYDN/T3z4AZh1gEYUD30wILw vctPg/8dJAqcLQUkgqFvtAmlWeY/MPUaqpJLOkwcgN/Zmyw5LNfdyPH//5oT5G++ vYyFkaxsIzPnnAb5omme =6FAB -----END PGP SIGNATURE-----