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 EA91913827E for ; Mon, 9 Dec 2013 18:49:54 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D728FE0BE2; Mon, 9 Dec 2013 18:49:48 +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 E359AE0BB6 for ; Mon, 9 Dec 2013 18:49:47 +0000 (UTC) Received: from [192.168.11.61] (cpe-72-177-217-176.satx.res.rr.com [72.177.217.176]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: steev) by smtp.gentoo.org (Postfix) with ESMTPSA id D516F33F2A1 for ; Mon, 9 Dec 2013 18:49:46 +0000 (UTC) Message-ID: <1386614861.1145.6.camel@oswin.hackershack.net> Subject: Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up From: Steev Klimaszewski To: gentoo-dev@lists.gentoo.org Date: Mon, 09 Dec 2013 12:47:41 -0600 In-Reply-To: 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> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5 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 Content-Transfer-Encoding: 7bit X-Archives-Salt: 3f1f86f8-0424-415c-bb58-9c1ab780f8e8 X-Archives-Hash: e77c8cb44cce338bb36d1f0c3c0b8394 On Mon, 2013-12-09 at 10:28 -0500, Rich Freeman wrote: > 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. > A stage3 is pretty much fully functional if you just create net.ethX and ln it in the default runlevel. (It will currently use busybox's udhcpc for dhcp client) > How do you even log into the stage3? Do we not disable the root > password by default? You can easily echo a password into /mnt/gentoo/etc/shadow - see code listing 5.4 on http://dev.gentoo.org/~armin76/arm/beagleboneblack/install.xml > > 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. We don't really have any minimal boot images for ARM as each device is different. Some devices have a u-boot that will boot an sdcard, some require you to put u-boot on the sdcard, some require a button press while having u-boot on the sdcard... so on and so forth. I'm not sure we really want to put out an image for each card (though it is something I'd like to discuss if the arm@ team would freaking reply to the thread on arm@ about having a freaking team meeting) > > 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. > You can do this with a qemu chroot on an amd64/x86 machine - but as ZC mentioned, it's slow - really slow - qemu emulates an arm processor running about 200mhz slow, and really NOT ideal at all. I currently suffer through it to build wpa_supplicant as a lot of my arm devices use wifi, but it really sucks. Even building on an rpi is faster than through qemu. > 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. > > Rich >