| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
On 12/09/2013 10:28 AM, Rich Freeman wrote: |
| 5 |
> On Mon, Dec 9, 2013 at 9:50 AM, Rick "Zero_Chaos" Farina |
| 6 |
> <zerochaos@g.o> wrote: |
| 7 |
>> I can honestly say most of the time when setup my arm systems I'm |
| 8 |
>> unpacking the arm stage3 on an amd64 and then booting the arm device |
| 9 |
>> with the base stage3 and fixing things from there. I suppose it is |
| 10 |
>> possible to use qemu to install things, as long as I don't mind |
| 11 |
>> pretending it's 1999 due to the slow emulation speeds... Yeah, I really |
| 12 |
>> don't see an improvement here. It works fine for "I'm an amd64 user and |
| 13 |
>> that's all I'll ever use" but when you start talking about smaller |
| 14 |
>> arches it really starts to become a hassle imho. |
| 15 |
> |
| 16 |
> Ok, now the concern is becoming more clear. You're intending to boot |
| 17 |
> directly to the stage3 and not chroot into it, and so you want the |
| 18 |
> stage3 to be a fully-functional userspace, though you don't actually |
| 19 |
> need it to contain a kernel/bootloader. |
| 20 |
|
| 21 |
Correct |
| 22 |
> |
| 23 |
> How do you even log into the stage3? Do we not disable the root |
| 24 |
> password by default? |
| 25 |
|
| 26 |
No, we don't disable it. It's trivial to set without chrooting (steev |
| 27 |
has details in his response and that isn't he point of this thread) |
| 28 |
> |
| 29 |
> Can you boot off of the minimal install image instead? Not sure if we |
| 30 |
> have one of those for ARM. Actually, any boot image that sets up a |
| 31 |
> network and supports chroot would work fine for your purposes. I do |
| 32 |
> realize that many (all?) ARM platforms don't have a flexible |
| 33 |
> bootloader like x86 typically does - so I'll let you speak to what |
| 34 |
> makes sense here. |
| 35 |
|
| 36 |
Sadly no, again covered by steev in his response we don't off anything |
| 37 |
bootable for arm at all. |
| 38 |
> |
| 39 |
> Following the handbook, the network is established by the boot CD and |
| 40 |
> all you do before chrooting is copy over your resolv.conf. In that |
| 41 |
> environment there is no need to have a networking system pre-installed |
| 42 |
> on the stage3. |
| 43 |
|
| 44 |
Well hold on there... the handbook doesn't mention anything about |
| 45 |
emerging your choice of network manager just yet, and when everything |
| 46 |
including dhcpcd isn't in the stage3 you will need to do more than copy |
| 47 |
resolv.conf (which honestly I never do anyway) or it won't work very well. |
| 48 |
> |
| 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 |
|
| 54 |
I grant this is an option, but what about guys like steev? He has a |
| 55 |
large stack of arm devices and like 1 amd64 box. What if he wants to |
| 56 |
put a stage3 on a disk for his amd64 box from his arm box? I'd love to |
| 57 |
see him emulate an amd64 from his arm to install dhcpcd. |
| 58 |
|
| 59 |
Now granted, that's being a little pedantic, as he could probably use |
| 60 |
one of the gentoo isos available to boot instead, but the point is we |
| 61 |
are removing software that gives the user a choice under the guise of |
| 62 |
giving the user a choice. |
| 63 |
|
| 64 |
I really don't like the idea of having no networking in the stage3 by |
| 65 |
default, however, I'm becoming more open minded on what qualifies as |
| 66 |
networking. What I'm wrestling with is this, what if I want to slap a |
| 67 |
stage3 on a device and then access it from the network? Almost nothing |
| 68 |
in my place has a monitor (amd64 and arm alike) and I use one of my two |
| 69 |
laptops to talk to everything else. Say I want to rebuild a headless |
| 70 |
machine, what am I supposed to do? Unpack a stage3, install some |
| 71 |
network manager manually (netifrc for me) and then boot? Granted, we |
| 72 |
already have to do this for any device which is wifi only as |
| 73 |
wpa_supplicant isn't in the stage3, but to remove this ability from |
| 74 |
wired devices as well.... I'm torn, I really don't think it's a great |
| 75 |
idea. I really feel that while the rest of the world is trying to get |
| 76 |
more functionality out of their hardware we are trying to save ~200k and |
| 77 |
possibly crippling user experience in the process. |
| 78 |
|
| 79 |
Is removing ~200k really worth the potential downside? Honestly, if we |
| 80 |
are going on the merits of smaller downloads let's argue about using xz |
| 81 |
instead of bzip2 for the stages... |
| 82 |
|
| 83 |
- -Zero |
| 84 |
-----BEGIN PGP SIGNATURE----- |
| 85 |
Version: GnuPG v2.0.22 (GNU/Linux) |
| 86 |
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ |
| 87 |
|
| 88 |
iQIcBAEBAgAGBQJSpiBiAAoJEKXdFCfdEflKuWMP/j7S40wYWxGWbI34Ij2U5dSG |
| 89 |
l11wJYdAP0k9bLs4rhDvJG56EaTyBJJYvfDCz+W2XF01MyNcdQfH2BzqEifp0ZOD |
| 90 |
kI0x81xzIqpb4YC1KvJXQxStDvs1Nxp3KbCX+Jg2hdkMv4hlHR7NF/g1gUajC8eA |
| 91 |
8tKdLcqIz822REqGtShGLYO9cjLaHZhGr/rFlxyK9ReQqj5cCdmEZ1MKN0Kb/DSa |
| 92 |
gQf+pmdecXXjCbF3N/5eihcQDrKe2UbXuKM/nNaiVw1ETnI+gjn815ofUNCc3Ynu |
| 93 |
jXZC4jse+MVQC6D6i3ZJi6o1VSlrGJmGDDxBSUtBPc7kSgFnaAz3AYC/izeIFtb9 |
| 94 |
VNQEmrcDjO5qKdZphc5ht2NW7uOBCZbpMoFmSj70cZK+NhJhaJPWqzUNu3mJLCUF |
| 95 |
72W89HCC3oTbpPtMVQHz9F3nmzYhH+QfrEXGd96woTyjcsZYwXvY8UDm486gsdsR |
| 96 |
aGNJCN34RXQvsLrsJdxJWaHJex5w2UHkBsi5IQkJniD1grq+CModEWiaqfD6Fo/y |
| 97 |
WXT1LUr3/1cgsLFU3E5VhgdYl873z2oNUHisWR37XYDN/T3z4AZh1gEYUD30wILw |
| 98 |
vctPg/8dJAqcLQUkgqFvtAmlWeY/MPUaqpJLOkwcgN/Zmyw5LNfdyPH//5oT5G++ |
| 99 |
vYyFkaxsIzPnnAb5omme |
| 100 |
=6FAB |
| 101 |
-----END PGP SIGNATURE----- |
Archives