Laptop dying need to rebuild packages for another architectu

[LIsLinuxIsSogood]

As the post says, my laptop is on its way out. At least for the time being, until I can get it fixed. Help is much appreciated. Thanks


Having recently rebuilt a bunch of packages for the specific architecture (i3 processor), I am now moving it over to a desktop where I can't seem to boot or chroot. The desktop has a Pentium G2120 chip in it. I think it is clearly a result of the recent rebuilding of packages with the architecture issue. Now I'm just wondering in order to prepare the disk to be booted from that other machine, what is the minimum that I need to do. Or in other words, is there some quicker way than with emerge -e @world it wants to build some 900+ packages...that could take too long!

The emerge --info while booted on the laptop is:
https://paste.pound-python.org/show/9GJWXSJQyQDtHtwd2Ne1/


But I do have a point of reference here to go by if it is helpful....a second installation already on the desktop where I am going to need to boot this disk
https://paste.pound-python.org/show/FLHukqQZFRxbrtPqpdRq/

EDIT: NOTE I ALREADY CHANGED THE CFLAGS IN THE MAKE.CONF FILE AND AM ONLY WAITING TO RUN THE APPROPRIATE PACKAGE REBUILD THROUGH PORTAGE, HENCE THE FACT THAT SOMETHING MIGHT LOOK LIKE IT IS "UP WITH" THE FIRST OF THE TWO LINKS ABOVE
(i know it should not need to match identically but whatever suggestions other than rebuilding the entire system that could help me to get there sooner would be great!)

[ct85711]

Ok, assuming you are staying as 64bit system or as a straight 32bit system; you should be able to get by just setting --march=generic; which will make your system generic in that it's not restricted on cpu instruction. Beyond that, the main parts you'd want to do, is recompile gcc, glibc, then do @system, and possibly the kernel (though you'd probably have to recompile that anyways, so could hold off on it). This will make your base system generic, so you can boot from a boot cd, mount into the linux partition, configure a kernel for the new machine and start rebuilding your machine. You won't necessarily have X11 going, so you will be stuck using straight command line; but after you have a working kernel and loaded the linux partition from that you can then do emerge -e world (after updating your march again for the correct system; and be up once again).

You may look through this forum thread, as some of it is still useful even though you may not be using getting a Ryzen (I am assuming you are not, if so even better). Either way, it has some advice on getting your system to be to the point of being most compatible to all cpu's to minimize the issue when transitioning.
https://forums.gentoo.org/viewtopic-p-8075482.html

If you are wanting to transition form 32bit to 64bit, you are better off just coping your world file and start from over...

[LIsLinuxIsSogood]

K, this is no problem. Thanks

Would you recommend for the first few steps using a less integrated way such as ebuild to interface with those, or can emerge still handle most of the lifting when it comes to rebuilds?

[LIsLinuxIsSogood]

How do you suggest I recompile them, do I need to remove them or else tell portage to look elsewhere while I sneakily replace the files?

Help it currently doesn't want to do another action if I just say -new use or -changed-use?

[ct85711]

you should be able to just modify your make.conf to use the new cflags (just use the bare basics for flags, you can later go update them on the new system).

After that, portage will be able to reinstall the packages it's self (it will use the updated cflags you set in your make.conf), just remember to use -1/--oneshot when recompiling the packages.

Note: DO NOT REMOVE THOSE PACKAGES!!! You WILL break your system by doing so, let portage do the work.

[LIsLinuxIsSogood]

Well I just ran into my first problem after installing gcc and glibc successfully.

Package: app-arch/gzip-1.8::gentoo
https://paste.pound-python.org/show/xSwXcqTSHjXNDpW5Q8UT/

Packages that were installed with -march=generic already
https://paste.pound-python.org/show/dXkptP61ic586B0VHNbp/
https://paste.pound-python.org/show/kaixuAwqgRSyhnz6kdQu/

What is it related to anything? Could I be missing a -mtune=switch perhaps some of the current output I am getting from portage looks like it is probably causing issues to have the generic setting for -march without -mtune set properly...

[LIsLinuxIsSogood]

Not really sure what's wrong, but here it goes...it would appear from this configuration log that it could be important

[ct85711]

[LIsLinuxIsSogood]

Does this cross compiling for different archictures present some limits with Portage? I had to undo everything so it is back to the way it was before I made any attempt to change the software for the Pentium chip on my desktop to be able to chroot/boot into it.

I do appreciate the help thus far, and will attempt to do some further research, but from what I was able to gather based on some of the research I did that -mtune is not really what I need, because it does not actually change the way that the architecture code is processed. But moving from i3 to pentium, means that I think you are right to say that -march=x86_64 should work for the cxx flag.

But what about other packages that were going to be built with multilib support, should those packages still work the same in terms of builds?

[NeddySeagoon]

LIsLinuxIsSogood,

This isn't cross compiling. Its changing the way code is tuned to the CPU, so you don't get illegal instruction errors when its in its new home.
Cross compiling is building for say a Raspberry Pi (arm or arm64) on an amd64 or i686 system.

You need to fix your CFLAGS and CPU_FLAGS_X86= to reflect the new CPU.

-mtune="generic" with -mcpu and -march both unset is as generic as you get on amd64. That will produce run anywhere (amd64) code.
_________________
Regards,

NeddySeagoon

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

[ct85711]

As Neddy mentioned, this is only so that you can move your linux system to another machine and it will work there (exception of maybe the kernel not having the new hardware support).

This is usually only needed when you are switching cpu bands, like moving from a intel to an amd CPU. The reason is that amd and intel don't support all of the same instructions. Quite often, moving from a older intel to an new intel cpu, isn't as much of an issue as the new intel often supports all or most of the old intel cpu's instructions. Once your system is fully compiled to be generic, you will be close to what other distro's are set at (they are compiled for as generic as possible), so the same software can be using on as wide of range of computers with only supplying 1 binary package. This is the same of how windows works, in that there is only 2 copies of the same one; one for 32bit and one for 64bit with no optimizations...

[LIsLinuxIsSogood]

I need help again, still recompiling gcc again for like the 4th time.

According to safe CFLAGS article on wiki, the settings for a Pentium are:

Pentium
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Pentium(R) CPU G2020 @ 2.90GHz


FILE /etc/portage/make.conf
CHOST="x86_64-pc-linux-gnu"
CFLAGS="-march=ivybridge -mno-avx -mno-aes -mno-rdrnd -O2 -pipe"
CXXFLAGS="${CFLAGS}"

I don't see how come it should be so difficult to build packages for the two Intel chips then again I am not 100% clear on what chroot actually does other than to change the root folder and call on the shell again?!

I am however afraid that the difference in the models of CPUs between the two machines is somehow in need of the more extreme measure perhaps reinstalling, IDK.

Does the system set, itself even seem necessary just to chroot, shouldn't there be a even more minimal set of packages, that could be applied for the new chrooted environment?

I do not want to reinstall if at all possible.

[LIsLinuxIsSogood]

At least according to the safe CFLAGS article on the wiki, these are the settings that are listed for a Pentium

Pentium

vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Pentium(R) CPU G2020 @ 2.90GHz


FILE /etc/portage/make.conf

CHOST="x86_64-pc-linux-gnu"
CFLAGS="-march=ivybridge -mno-avx -mno-aes -mno-rdrnd -O2 -pipe"
CXXFLAGS="${CFLAGS}"


Now, I tried that and as discussed the problem with this was somehow unable to continue with the compilation on the current system, so it was no good, If I alternatively try to recompile all packages with the -march=x86_64 is that going to be my best bet...so far I've tried everything but that in the hopes of figuring out how the -mtune setting might work, but it has not. I am afraid that the difference in the models of CPUs between the two machines is somehow in need of the more extreme measure.

[ct85711]

Ok, first off; do you know if the new cpu is going to be an intel or not? If you what approximately like what the new cpu is, we can figure out what it supports; then we compare between the 2. If you are staying within the same brand, you may not need to change your cflags at all; as the instructions would already be compatible on the new cpu.

Since we don't know what the new cpu is, we are going by the safest assumption that it is not compatible with the old cpu. That means getting the system as generic as possible.

[LIsLinuxIsSogood]

I agree that was a bit unclear before so here it is... The laptop that I am in need of replacing/repairing is for now on its way out...and what that means is for the time being I will be downgrading CPU (to the desktop Pentium IV?... G2120 , while I attempt to still remain working from within the OS on the hard drive. Since that G2120 chip is an older chip than my laptop, I will eventually like to get a new laptop with a newer (more advanced chip in it). until then, it would appear that my problem could be due to the downgrading of sorts.

From your earlier posts....

[NeddySeagoon]

LIsLinuxIsSogood,

[LIsLinuxIsSogood]

Wouldn't gcc need to necessarily be the last one to be built, otherwise how will it get used if it is compiled for use with a different architecture!?

[LIsLinuxIsSogood]

https://paste.pound-python.org/show/LAvwvnlsmQpzawpiI6a5/

I would be much obliged, if you were to take a look at the output from emerge --info and let me know if the CFLAG and CXXFLAG settings are right.

[NeddySeagoon]

LIsLinuxIsSogood,

[LIsLinuxIsSogood]

So theni would want to use the following

[NeddySeagoon]

LIsLinuxIsSogood,

[LIsLinuxIsSogood]

Ok let's start a couple steps earlier then. How do I get gcc working correctly, and what would be the next steps once it works before moving over the hard drive to the older machine?

Update: My latest attempts to recompile the C compiler, plus libraries needed for the system set, which included the packages here

[NeddySeagoon]

LIsLinuxIsSogood,

That looks good so far.

You will also need to rebuild your kernel and boot loader for the correct or generic CPU. The kernel build system does not use make.conf at all.
Don't forget to reinstall them both too.
When you rebuild your kernel, you need to include hardware support for the motherboard its running on now and the new motherboard, so the same kernel works in both places.

Be careful of the virtuals,

[LIsLinuxIsSogood]

[LIsLinuxIsSogood]

Note, I have not yet attempted to rebuild the kernel but since i am getting impatient with the transfer i will take your suggestion and do.