Gentoo Archives: gentoo-dev

From: Steev Klimaszewski <steev@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
Date: Mon, 09 Dec 2013 18:49:54
In Reply to: Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up by Rich Freeman
1 On Mon, 2013-12-09 at 10:28 -0500, Rich Freeman wrote:
2 > Ok, now the concern is becoming more clear. You're intending to boot
3 > directly to the stage3 and not chroot into it, and so you want the
4 > stage3 to be a fully-functional userspace, though you don't actually
5 > need it to contain a kernel/bootloader.
6 >
8 A stage3 is pretty much fully functional if you just create net.ethX and
9 ln it in the default runlevel. (It will currently use busybox's udhcpc
10 for dhcp client)
12 > How do you even log into the stage3? Do we not disable the root
13 > password by default?
15 You can easily echo a password into /mnt/gentoo/etc/shadow - see code
16 listing 5.4 on
19 >
20 > Can you boot off of the minimal install image instead? Not sure if we
21 > have one of those for ARM. Actually, any boot image that sets up a
22 > network and supports chroot would work fine for your purposes. I do
23 > realize that many (all?) ARM platforms don't have a flexible
24 > bootloader like x86 typically does - so I'll let you speak to what
25 > makes sense here.
27 We don't really have any minimal boot images for ARM as each device is
28 different. Some devices have a u-boot that will boot an sdcard, some
29 require you to put u-boot on the sdcard, some require a button press
30 while having u-boot on the sdcard... so on and so forth. I'm not sure
31 we really want to put out an image for each card (though it is something
32 I'd like to discuss if the arm@ team would freaking reply to the thread
33 on arm@ about having a freaking team meeting)
35 >
36 > Following the handbook, the network is established by the boot CD and
37 > all you do before chrooting is copy over your resolv.conf. In that
38 > environment there is no need to have a networking system pre-installed
39 > on the stage3.
40 >
42 You can do this with a qemu chroot on an amd64/x86 machine - but as ZC
43 mentioned, it's slow - really slow - qemu emulates an arm processor
44 running about 200mhz slow, and really NOT ideal at all. I currently
45 suffer through it to build wpa_supplicant as a lot of my arm devices use
46 wifi, but it really sucks. Even building on an rpi is faster than
47 through qemu.
49 > Oh, and if I'm not mistaken the stage3 is based on the system set
50 > which is established by the profile, so if it made sense to keep
51 > networking around for ARM that would be an option.
52 >
53 > Rich
54 >