-----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
> <zeroch...@gentoo.org> 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-----

Reply via email to