| View previous topic :: View next topic |
| Author |
Message |
rsnfunky
Tux's lil' helper
Joined: 30 Dec 2007
Posts: 109
|
 Posted: Sun Jan 26, 2025 10:19 am Post subject: Cross Compiling gentoo for an Old PC |
 |
|
Hi I think this would have been discussed many times in the past, have tried various methods.
I have 2 desktops:
1) Old Athlon 4 core running on Openrc (8GB RAM)
2) Latest AMD 8 core running systemd (64 GB RAM)
I wanted to use the latest PC to compile software for the old PC. Tried DistCC but it worked for a very few packages and only used 5-10% CPU of the new PC. (Not useful method)
I read the post on https://forums.gentoo.org/viewtopic-p-8763943.html?sid=
The issue here was once I chrooted on the new install to make the binpkgs instead of the upgrade of 22 packages (which were required on the old system) the new system was making the whole 1052 packages.
Alternate Approach:
1) Export the / of the old PC via nfs using the no_root_squash option
2) mount this NFS share on the new PC as root
3) Chroot on this mount on new PC
4) build normally on the New PC. It seems to use the CPUs on the New PC and install the final build directory on the NFS share (which is on the Old PC and chrooted on the new pc)
5) To improve the compile time and reduce the network file transfers I used --bind /var/tmp/portage/ to the Chroot location (thereby all compiles were on the local hdd and only final build directory was being transferred via nfs)
The commands used are as under:
| Code: | #!/usr/bin/env bash
if [[ $UID != 0 ]]; then
echo "This must be run as root."
exit 1
fi
chroot=/nfs
#mount $chroot
mount --rbind /dev "$chroot"/dev
mount --make-rslave "$chroot"/dev
mount -t proc /proc "$chroot"/proc
mount --rbind /sys "$chroot"/sys
mount --make-rslave "$chroot"/sys
mount --rbind /tmp "$chroot"/tmp
mount --bind /run "$chroot"/run
mount --make-slave "$chroot"/run
mount --rbind /var/tmp/portage/ "$chroot"/var/tmp/portage/
cp --dereference /etc/resolv.conf $chroot/etc
chroot $chroot /bin/bash
source /etc/profile
export PS1="(chroot) ${PS1}"
|
The source /etc/profile and export PS1="(chroot) ${PS1}" do not seem to work with the script, maybe its post Chroot and therefore these commands donot come into the chrooted environemnt.
Question:
1) the emerge commands seem to work in the chroot environment. Have not proceeded further on this after building a couple of packages
2) What are the issues that one can face, what all can break on the old PC? (Assuming that both the PCs are switched on and on same wifi network) |
|
| Back to top |
|
 |
pingtoo
Veteran
Joined: 10 Sep 2021
Posts: 1456
Location: Richmond Hill, Canada
|
| Posted: Sun Jan 26, 2025 12:33 pm Post subject: Re: Cross Compiling gentoo for an Old PC |
|
|
| rsnfunky wrote: | Question:
1) the emerge commands seem to work in the chroot environment. Have not proceeded further on this after building a couple of packages
2) What are the issues that one can face, what all can break on the old PC? (Assuming that both the PCs are switched on and on same wifi network) |
I see no major issue with your approach. if your target build is a desktop environment for every day usage, I think 99% of packages will just work. There could be few that very will optimized packages that know CPU specific and if you choose to enable (or disable) that during the build you may end up with illegal instruction error during the build and fail on that package. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54776
Location: 56N 3W
|
| Posted: Sun Jan 26, 2025 1:45 pm Post subject: |
|
|
rsnfunky,
There is Build In A Chroot too.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 23050
|
| Posted: Sun Jan 26, 2025 3:24 pm Post subject: Re: Cross Compiling gentoo for an Old PC |
|
|
| rsnfunky wrote: | | The issue here was once I chrooted on the new install to make the binpkgs instead of the upgrade of 22 packages (which were required on the old system) the new system was making the whole 1052 packages. |
I can think of a few ways that could have happened. Full output would be helpful in identifying exactly why it happened, if you want to debug that route rather than pursue your current one. | rsnfunky wrote: | | 5) To improve the compile time and reduce the network file transfers I used --bind /var/tmp/portage/ to the Chroot location (thereby all compiles were on the local hdd and only final build directory was being transferred via nfs) |
I would also bind in the Portage tree, and probably distfiles, for the same reason. | rsnfunky wrote: | | Code: | | #!/usr/bin/env bash |
|
I think you could assume that bash is /bin/bash. Even on a merged-usr system, that path will work, due to the symlink. | rsnfunky wrote: | | Code: | | if [[ $UID != 0 ]]; then |
|
This could be done using a numeric test: | Code: | | if [[ UID -eq 0 ]]; then |
Yes, I left out the $. Yes, it works anyway. | rsnfunky wrote: | | Code: | | echo "This must be run as root." |
|
Traditionally, such messages should be sent to stderr, in case the user hid stdout. | rsnfunky wrote: | | Code: | | cp --dereference /etc/resolv.conf $chroot/etc |
|
This will write buildhost's resolv.conf onto the target host. Is that what you want? The target host probably has valid DNS settings already. If the two machines deliberately use different DNS, then overwriting target's DNS is wrong. Consider using a bind mount of buildhost's resolv.conf instead. | rsnfunky wrote: | | Code: | | chroot $chroot /bin/bash |
|
This should be quoted. | rsnfunky wrote: | | Code: | source /etc/profile
export PS1="(chroot) ${PS1}" |
The source /etc/profile and export PS1="(chroot) ${PS1}" do not seem to work with the script, maybe its post Chroot and therefore these commands donot come into the chrooted environemnt. |
Correct. As written, they execute after the chroot'd bash exits. Worse, since they are only meaningful for an interactive script, which this is not, they do no good even once they do run. | rsnfunky wrote: | Question:
1) the emerge commands seem to work in the chroot environment. Have not proceeded further on this after building a couple of packages |
This is not a question.  | rsnfunky wrote: | | 2) What are the issues that one can face, what all can break on the old PC? (Assuming that both the PCs are switched on and on same wifi network) |
As pingtoo hinted at, but which I want to elaborate on, the big risk is that you build a program that can only run correctly on New PC, but it then gets installed on Old PC. This is an especially high risk if your CFLAGS include -march=native, since native means the CPU executing the build, which would be New PC's CPU. However, there are other ways to get this wrong, such as overly optimistic CPU_FLAGS_X86, or badly behaved build systems.
Although you did not ask, I will note that your setup script does not clean up after itself. You should either run it in a mount namespace (preferred) or unmount the binds when you are done. |
|
| Back to top |
|
|
sublogic
Guru
Joined: 21 Mar 2022
Posts: 303
Location: Pennsylvania, USA
|
| Posted: Mon Jan 27, 2025 2:39 am Post subject: |
|
|
@rsnfunky, your idea should work if the 8-core AMD's instruction set is a superset of the Athlon's instruction set.
I do something similar with an amd64 helper and an old i686 laptop. The helper's kernel has CONFIG_IA32_EMULATION=y so it can run 32-bit code.
My chrooting script works about like yours but it ends like this: | Code: | echo chroot ...
linux32 chroot $chroot_dir /bin/bash /root/fix-env.sh
echo back from chroot.
[ cleanup code omitted ] |
where the /root/fix-env.sh on the client is: | Code: | #! /bin/bash
# tweak portage environment for a chroot from helper computer
echo -n updating profile ...
source /etc/profile; echo
echo -n updating FEATURES ...
export FEATURES=-distcc; echo
echo -n updating MAKEOPTS ...
export MAKEOPTS="-j10"; echo
PS1='(chroot) \u:\W \$ ' /bin/bash --norc -s |
You get the idea. The --norc -s is the only way I could find to make the PS1 assignment stick.
Note: the client's make.conf already has CFLAGS="-march=pentium-m ..." and not -march=native , because it can also emerge locally with distcc.
Before building, I run emerge --fetchonly from the client and I sync the clock with sftp from net-misc/ntp . That way the downloads are already done and there is no clock skew to confuse the build. (I should bind-mount the helper's distdir and portage tree as Hu suggested!) |
|
| Back to top |
|
|
rsnfunky
Tux's lil' helper
Joined: 30 Dec 2007
Posts: 109
|
| Posted: Mon Jan 27, 2025 9:13 am Post subject: Solved. |
|
|
It functioned perfectly and updated the system. My make.conf does not have -march=native but the amdfam10.
The only issue which I faced was when the emaerge finished and I rebooted the New PC, it was unable to unmount all the binds and the New PC hanged.
@HU will take the script prepared by @NeddySeagoon from the guide going forward.
Was not implementing the tmpfs and was doing all compiles on NvMe / SSDs. Will implement that too. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Installing Gentoo
