Install Gentoo from another computer

alogim · Tux's lil' helper Joined: 21 Aug 2015 Posts: 131

Hello everyone. Besides my main dekstop computer, I have an old Acer Aspire 5610Z, with the following specifications:

Intel® Pentium® T2060 (1 MB cache, 1,60 GHz, FSB @ 533 MHz);
1 GiB DDR2 RAM;
Intel Graphics Media Accelerator 950;
80 GB HDD;

I had Archlinux installed on it for a long time, however it does not support 32 bit architectures anymore. I tried Lubuntu, but it is really really slow, so I thought that maybe Gentoo would be a little faster.
Since the CPU is rather old, I would like to compile everything from my main desktop PC. Here I found that I could basically do the following:

boot up my main desktop PC with Gentoo and connect the HDD of my laptop;
mount the laptop's HDD on /mnt/gentoo (since it has three partitions, I would mount the root partition /dev/sda2 on /mnt/gentoo, then the boot partition /dev/sda1 on /mnt/gentoo/boot and finally the home partition /dev/sda3 on /mnt/gentoo/home);
then I would follow the x86 handbook starting from here, having care to change the CFLAGS so that they are optimized for the actual laptop's architecture.

Is my idea correct or do I have to follow particular steps? Since I am using my desktop PC with Gentoo I think that it can be considered as if it were the official Minimal Installation CD, am I right?

NeddySeagoon · Posted: Sun Aug 13, 2017 2:10 pm Post subject:

alogim,

Mounting the laptop HDD in your desktop requires that its CPU can execute all the instructions that the laptop can.
If that's not true, you need to determine a common subset.

Actually moving the laptops HDD is one approach.
Mounting it over NFS is another, so it stays in the laptop but appears in the desktops filesystem tree.

There is a third approach. Build everything on the laptop but use cross distcc so that the desktop acts a helper.
This way, the desktop does not execute any of the code that runs on the laptop. Its not as fast as building on the desktop becase the laptop does some of the work.

The simplest is to physically move the HDD. Its likely that the losses for finding a common subset of the instruction sets will be small and confined to the mulimedia extensions. You can rebuild these apps locally if performance is a problem.

You cannot use -march=native in the chroot. There are lots of one liners on the internet to find out what -march=native means. Run one on your laptop, and whatever it shows, set in the chroot CFLAGS.
Now run the same thing on your desktop and compare the two. You may need to remove some options from the chroot CFLAGS
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

alogim · Tux's lil' helper Joined: 21 Aug 2015 Posts: 131

Thank you for the quick answer, NeddySeagoon.

eccerr0r · Posted: Sun Aug 13, 2017 2:42 pm Post subject:

The Intel Pentium T2060 is a Pentium-M class CPU.
I don't think it supports anything special that an Core based 3rd gen machine can't run. However the worry is that you build things that the old Pentium-M can't run, be mindful when setting your CFLAGS and CPU_FLAGS_X86 (i.e. make sure you don't add stuff like avx which the Pentium-M does not support).
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

alogim · Tux's lil' helper Joined: 21 Aug 2015 Posts: 131

eccerr0r · Posted: Mon Aug 14, 2017 4:00 pm Post subject:

I just ran into a similar issue that might be useful:

While I was trying to update my i686 USB Gentoo install. I did this via a chroot from a fast x86_64 box with 32-bit enabled. Most of the packages were able to update just fine with the added benefit of faster build times and despite chrooting into this i686 install with only i686 tools available,

dev-python/m2crypto

failed when it tried to build a file with -D __x86_64__ for absolutely no reason, other than detecting that it was in a 64-bit capable kernel.

I ended up rebooting the machine and building it with a 32-bit kernel... I suppose this is a build bug?
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

Hu · Moderator Joined: 06 Mar 2007 Posts: 21624

Yes, that looks like a build bug to me. As far as I know, the build system should never set that define. When the file is built for an actual amd64 environment, gcc will predefine that symbol[1], making the build system definition unnecessary. When the file is not built for amd64, the symbol will not be defined[2].

[1] As a reserved symbol, I could see an argument that the symbol should not be inspected by user programs at all, but instead should be used only by code which can guarantee it is being built by a compiler that is guaranteed to define that symbol.
[2] As a reserved symbol, I can see an argument that the compiler is free to set or unset that symbol on any platform, and user programs should not care either way because they should not be inspecting it. In practice, it seems to be set only for amd64 targets.

eccerr0r · Posted: Tue Aug 15, 2017 2:17 am Post subject:

Okay, I just found that the bug I encountered was classified by the devs as an upstream issue.

Just anyone who's doing this needs to watch out for stuff like this... And seems that

# setarch i686 chroot [...]

or

# setarch i686 emerge [...]

should work around this problem.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?