Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up

[Steev Klimaszewski]

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
>