Illegal instruction(solved)

[hedmo]

hi all

i have upgraded my box from fx8150 to ryzen and now everything i try to do gives me : Illegal instruction

Code: Select all

livecd 
/ # emerge --info
Illegal instruction
livecd / # gcc-config -l
 * gcc-config: Could not get portage CHOST!
 * gcc-config: You should verify that CHOST is set in one of these places:
 * gcc-config:  - //etc/portage/make.conf
 * gcc-config:  - active environment
 livecd / #cat /etc/portage/make.conf | grep CHOST
# WARNING: Changing your CHOST is not something that should be done lightly.
CHOST="x86_64-pc-linux-gnu"
livecd / #nano -w /etc/portage/make.conf
Illegal instruction
livecd / # 

regards hedmo

[bunder]

This means your fx8150 had cpu instructions that the ryzen does not have. In order to fix this, you'll probably want to (edit: never mind), but that's probably going to break a lot of stuff. you might be better off making a backup and reinstalling.

[NeddySeagoon]

hedmo,

DON'T extract a stage 3 over your existing install.
Your existing install will be destroyed.

You may want to do binary installs of a few carefully selected packages until you get a working portage and toolchain.
At that point, the system can rebuild itself.

Code: Select all

/ # emerge --info
Illegal instruction

suggests that python will not run on your Ryzen.

[hedmo]

hedmo,

DON'T extract a stage 3 over your existing install.
Your existing install will be destroyed.

You may want to do binary installs of a few carefully selected packages until you get a working portage and toolchain.
At that point, the system can rebuild itself.

Code: Select all

/ # emerge --info
Illegal instruction

suggests that python will not run on your Ryzen.

NeddySeagoon

okej i am in the rescue chroot and installing some packages(/usr/portage/scripts/bootstrap.sh and emerge -ave system).i dont fully understand all off it.

1.what is happening to my old install
2.when can i reboot to my old install and what shall i do

regards hedmo

[krinn]

1. Nothing special, you didn't took care of it prior the migration, you should had rebuild everything or critical packages to use a more generic cflags or compatible with the next cpu ; i'm not amd specialist, but i think amd has drop 3dnow and 3dnowext for ryzen ; so, just invalid opcodes for a ryzen.

2. once you have succeed at rebuilding "critical" packages that you would use to rebuild other incompatible packages.

I have cite twice time "critical packages", the list could be long, but it's just packages that would allow you to build another one (ie: the python use by portage, portage, gcc, glibc, binutils...). Once those ones are running fine, you could rebuild less critical ones with proper cflags set for the ryzen.
NeddySeagoon's link will help you get critical ones back, others will be handle by emerge -e

[NeddySeagoon]

hedmo,

You are using the rescue chroot to build things that will run on your Ryzen.
Once they are built in the rescue chroot, they need to be installed into your real system, using the binary packages.
That's what

Code: Select all

emerge -K

does.

If emerge cannot be used each binary package is like a single package stage3 tarball.
It can be installed using tar, just like a stage3. If you need to do this, its essential to untar the package to the correct location, so it overwrites the package that generates the illegal instructions. There are probably more than one of them.

If python is a problem, you will need to use the tar method as portage is written in python.
Once emerge works, switch to

Code: Select all

emerge -K

-- edit --

krinns "critical packages" are the things needed to be able to chroot and build more packages. Its a part of the @system set.

We don't know what will fail. It depends on the instructions gcc used. Just because 3DNow! was available on the old CPU does not mean that gcc actually used it in a particular binary.
The only way to tell is trial and error.

[hedmo]

okay so if i get

Code: Select all

(chroot) livecd / # emerge -avK dev-lang/python
Illegal instruction

i have to use the tar option

Code: Select all

root #tar --xattrs -xpf /mnt/gentoo/usr/portage/packages/<package/atom> -C /mnt/gentoo

to every package i want to install

ragards hedmo

[Naib]

personally I would go for a reinstall. You will be up very,very quickly if you backup your /etc and /home (and some of /var)
Is it possible to recover from this? sure... selectively laying out binary packages until the toolchain is functional. HOWEVER... you may end up running into more blockers burning more time.

[NeddySeagoon]

hedmo,

The simple answer is Yes.

That message indicates that the selected python is probably broken.
You got into the chroot, so at least some of bash works and some of glibc. In fact, bash needs

Code: Select all

 $ lddtree /bin/bash
/bin/bash (interpreter => /lib64/ld-linux-x86-64.so.2)
    libreadline.so.7 => /lib64/libreadline.so.7
        libncurses.so.6 => /lib64/libncurses.so.6
            libdl.so.2 => /lib64/libdl.so.2
    libc.so.6 => /lib64/libc.so.6

so all those things are in use.

After you use the tar method for your active python, try emerge -K again.

A long time ago someone told me that it wasn't possible to do a Gentoo install using the liveDVD.
That would be late 2009, when the Gentoo 10fh birthday liveDVD was produced.
That was a challenge. :)
Here's how, look at section 5.
That's a list of all the packages I needed in an empty dir to be able to chroot and use emerge -K
Versions will have changed and there may be a few more dependencies but it will give you some idea of package names that may need tar.

Your chroot is your real system that's not working.

[hedmo]

hedmo,

The simple answer is Yes.

That message indicates that the selected python is probably broken.
You got into the chroot, so at least some of bash works and some of glibc. In fact, bash needs

Code: Select all

 $ lddtree /bin/bash
/bin/bash (interpreter => /lib64/ld-linux-x86-64.so.2)
    libreadline.so.7 => /lib64/libreadline.so.7
        libncurses.so.6 => /lib64/libncurses.so.6
            libdl.so.2 => /lib64/libdl.so.2
    libc.so.6 => /lib64/libc.so.6

so all those things are in use.

After you use the tar method for your active python, try emerge -K again.

A long time ago someone told me that it wasn't possible to do a Gentoo install using the liveDVD.
That would be late 2009, when the Gentoo 10fh birthday liveDVD was produced.
That was a challenge.
Here's how, look at section 5.
That's a list of all the packages I needed in an empty dir to be able to chroot and use emerge -K
Versions will have changed and there may be a few more dependencies but it will give you some idea of package names that may need tar.

Your chroot is your real system that's not working.

NeddySeagoon

Before i do more damage!!!!!!!

Code: Select all

livecd / # tar --xattrs -xpf /mnt/gentoo/usr/portage/packages/dev-lang/python-3.5.4-r1.tbz2 -C /mnt/gentoo

bzip2: (stdin): trailing garbage after EOF ignored
livecd / # tar --xattrs -xpf /mnt/gentoo/usr/portage/packages/sys-devel/binutils-2.29.1-r1.tbz2 -C /mnt/gentoo

bzip2: (stdin): trailing garbage after EOF ignored
livecd / # chroot /mnt/gentoo /bin/bashlivecd / # emerge --info
bash: emerge: command not found
livecd / # ls /usr/bin | grep  emerge
emerge
emerge-webrsync
livecd / # 

"emerge is symlinks that does not exist"

do you want me to continue with section 5https://web.archive.org/web/20120102130 ... 0_10.1.xml.......

regards hedmo

[Tony0945]

I've been googling to find the forum thread discussing the instruction set backward comparability but haven't found it. Supposedly march=k10 was OK but bulldozer was not.

IF the original hardware is still available (i.e. you just moved the hdd to a new drive" and you don't want to follow Neddy's procedure (I've done it and it's most educational) then I suggest you try the following which will consume real time but not much of your time.

1. Put the HDD back into the original box.
2. Change CFLAGS to march=generic and run "emerge -e world --keep-going"
3. A day or two later when emerge finishes and you have done any emerge-resumes required (you shouldn't have any with =generic)
4. Put the HDD back into the new box.
5. Restore your CFLAGS to zenver1 and ...
6. Run "emerge -e world --keep-going" again. It should take less than a day, maybe six or seven hours.

This was basically what I planned for ryzen upgrade, except now I have a Bristol Ridge (excavater/bulldozer) AM4, so I need only do the first emerge -e world, replace the CPU & cooler then boot up and do the second emerge -e world.

If you only changed motherboard, weigh the mechanical work vs the software work.


And yet... Doing it Neddy's way WILL teach you a lot about how your software system works.

So weigh your time priorities and decide.

[hedmo]

I've been googling to find the forum thread discussing the instruction set backward comparability but haven't found it. Supposedly march=k10 was OK but bulldozer was not.

IF the original hardware is still available (i.e. you just moved the hdd to a new drive" and you don't want to follow Neddy's procedure (I've done it and it's most educational) then I suggest you try the following which will consume real time but not much of your time.

1. Put the HDD back into the original box.
2. Change CFLAGS to march=generic and run "emerge -e world --keep-going"
3. A day or two later when emerge finishes and you have done any emerge-resumes required (you shouldn't have any with =generic)
4. Put the HDD back into the new box.
5. Restore your CFLAGS to zenver1 and ...
6. Run "emerge -e world --keep-going" again. It should take less than a day, maybe six or seven hours.

This was basically what I planned for ryzen upgrade, except now I have a Bristol Ridge (excavater/bulldozer) AM4, so I need only do the first emerge -e world, replace the CPU & cooler then boot up and do the second emerge -e world.

If you only changed motherboard, weigh the mechanical work vs the software work.




And yet... Doing it Neddy's way WILL teach you a lot about how your software system works.

So weigh your time priorities and decide.

Tony0945

Code: Select all

/ # emerge --info
Illegal instruction 

and after the:

Code: Select all

livecd / # tar --xattrs -xpf(the packages i have unpacked )

=

Code: Select all

livecd / # emerge -k
bash: emerge: command not found
livecd / # 

i can not emerge a thing

i have to find the sources that have emerge in it and "tar in right order".i hope

regards hedmo

[NeddySeagoon]

hedmo,

Try running emerge explicitly.

Code: Select all

/usr/bin/emerge -K ...

[Tony0945]

Code: Select all

livecd / # emerge -k
bash: emerge: command not found
livecd / # 

i can not emerge a thing

i have to find the sources that have emerge in it and "tar in right order".i hope

regards hedmo

That was after restoring the hardware.

[Naib]

I just want to point out, you would have had a new install up and running by now

[Tony0945]

I just want to point out, you would have had a new install up and running by now

With all the packages built and configuration set? Crontab restored? Better to just untar /bin, /lib, /usr/lib, /usr/bin from a snapshot instead of a full re-install then emerge -e world with march=native.

[krinn]

you can also quickpkg packages from a livecd and use these binaries to install them in your chroot, they are generic (else livecd would fail) and you just need toolchain & friends (far less than world rebuild), i would say binutils, gcc, glibc, portage, python, automake, libtool ; maybe one or two more.

or even easier if someone point him to "generic binaries" provided by a farm, but i always forget the link to them

once the "critical packages" are fine, he can -e world with proper cflags set.

[hedmo]

okej.

emerge is up and running and i can install the binarys but not any other program

Code: Select all

livecd / # emerge -av python
hese are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  NS    ] dev-lang/python-3.6.5:3.6/3.6m::gentoo [2.7.14-r1:2.7::gentoo, 3.5.4-r1:3.5/3.5m::gentoo] USE="gdbm ipv6 ncurses readline sqlite ssl (threads) xml -build -examples -hardened -libressl {-test} -tk -wininst" 0 KiB

Total: 1 package (1 in new slot), Size of downloads: 0 KiB

Would you like to merge these packages? [Yes/No] 

>>> Verifying ebuild manifests
Illegal instruction
livecd / # 

regards hedmo

[NeddySeagoon]

hedmo,

Now that emerge works, you can do

Code: Select all

emerge -eK @system

to do the whole of the system set in one go.
That's a lot more than you should need but it will be fast anyway.

If that fails due to missing binaries, change the -K to -k, then it will try to build things if it needs to.

[hedmo]

hedmo,

Now that emerge works, you can do

Code: Select all

emerge -eK @system

to do the whole of the system set in one go.
That's a lot more than you should need but it will be fast anyway.

If that fails due to missing binaries, change the -K to -k, then it will try to build things if it needs to.

NeddySeagoon.no i can not

Code: Select all

* Sanity check to keep you from breaking your system:
 *  Downgrading glibc is not supported and a sure way to destruction
 * ERROR: sys-libs/glibc-2.25-r11::gentoo failed (pretend phase):
 *   aborting to save your system

[Naib]

I just want to point out, you would have had a new install up and running by now

With all the packages built and configuration set? Crontab restored? Better to just untar /bin, /lib, /usr/lib, /usr/bin from a snapshot instead of a full re-install then emerge -e world with march=native.

um yes

Posted: Sun Apr 08, 2018 9:48 am

personally I would go for a reinstall. You will be up very,very quickly if you backup your /etc and /home (and some of /var)
Is it possible to recover from this? sure... selectively laying out binary packages until the toolchain is functional. HOWEVER... you may end up running into more blockers burning more time.

Posted: Sun Apr 08, 2018 11:37 pm

I just want to point out, you would have had a new install up and running by now

Thats 14h 49min.
30min to layout a stage3, compile kernel, grub etc to be booting to your systems cli. Then it is just adding what you want
I built a ryzen system last year and I was into X very quickly (helps I am an openbox user so a light build) and I was playing CS:GO within 6hours

sure I held off the likes of openoffice (but that doesn't take too long to build). I was also installing to an M.2 and using old ssd's as rag drives so I was able to just mount the old drives to copy selective etc, home, var while compiling was occuring.

[NeddySeagoon]

hedmo,

glibc in your rescue install is older that the one in the install you are trying to rescue.
You need to build the right version of glibc or pass --exclude="glibc" to the emerge command.

Code: Select all

 *  Downgrading glibc is not supported and a sure way to destruction
 * ERROR: sys-libs/glibc-2.25-r11::gentoo failed (pretend phase):
 *   aborting to save your system

is quite correct. Its a very bad thing to do.

[hedmo]

hedmo,

glibc in your rescue install is older that the one in the install you are trying to rescue.
You need to build the right version of glibc or pass --exclude="glibc" to the emerge command.

Code: Select all

 *  Downgrading glibc is not supported and a sure way to destruction
 * ERROR: sys-libs/glibc-2.25-r11::gentoo failed (pretend phase):
 *   aborting to save your system

is quite correct. Its a very bad thing to do.

NeddySeagoon

yes it was older and my portage was broken to. had to --sync and chroot back to my rescue to build more pkgs.i am up and running
and rebuilding my @system and @world but some packages are still failing with:

Code: Select all

Illegal instruction

cmake is one of the packages that fails and it fails with the line :

Code: Select all

 cmake-utils_src_configure

regards hedmo

[NeddySeagoon]

hedmo,

The failure will be related to a tool package, not the package being built.
The packages being built is not being executed. Well, there are a few corner cases where the build system builds something then runs it as apart of the build.

Its the something that cmake is using, or a library called by that something that is the problem.
Its also something that has not yet been rebuilt but that may not help find it.

In short, building cmake triggers the problem but its not the cause.

Build cmake with MAKEOPTS="-j1" to get a nice easy to read build log them pastebin the entire build leg.

[hedmo]

NeddySeagoon

here you go:

Code: Select all

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

regards hedmo