# Atom zu CeleronM clonen; ungültiger Maschinenbefehl [solved]

## Randy Andy

Hi Leute,

in der Vergangenheit hab ich schon öfter meine vorhandenen Gentoo-Kisten erfolgreich geklont, als Grundlage um eine bestehenden Installation auf andere Zielhardware anzupassen.

Diesmal klappt es aber nicht wie gewohnt, jedoch ist meine Vorgehensweise diesmal auch eine Andere um Kompilierzeit zu sparen und weil das bestehende Instruction Set nicht kompatibel zu dem meiner Zielarchitektur ist. Trotzdem steh ich irgendwie auf'm Schlauch und frage mich warum das so nicht funktioniert:

Letztlich möchte ich meine 32-Bit Atom-Netbook optimierte Installation (A) auf ein Celeron Notebook (C) übertragen bzw. dafür anpassen.

Da Installation (A) aber auf (C) weder boot noch lauffähig wäre, und ich nach diversen Anpassungen der Hardwaresettings ohnehin ein emerge -e system world machen müsste was auf der Kiste endlos dauern würde, kommt noch mein Boost System (B) (QuadCore 64/32 Bit) ins Spiel.

Ich hab also erst mal (A) auf (B) kopiert und dort per Grub ansprechbar gemacht und die fstab angepasst. 

Nun bootet also (B) der Quadcore das ursprüngliche 32-Bit Atom-System von seiner lokalen Platte, da er als Teilmenge seines Instruction Set auch das des Atom beherrscht.

Dort hab ich dann die CFLAGS in der make.conf an die künftige Zielarchitektur des Celeron angepasst (siehe Settings zu A und C unten).

Nun habe ich auf (B) das gesamte System mit diesen Einstellungen durchkompiliert mittels: emerge -e system world 

Dann das gesamte System nach (C) übertragen, dort grub installiert, fstab hostname hosts angepasst, /etc/udev/rules.d/ 70-persistent-netrules gelöscht, rebootet.

Dann habe ich auf (C) noch einen genkernel erzeugt, Ergebnis:

Erfolgreich booten und einloggen auf der Konsole klappt schon, aber beim aufruf von emerge sagt er mir dann: Ungültiger Maschienenbefehl

Was könnte der Grund dafür sein, was hab ich falsch gemacht wie könnte ich eine Fehlersuche betreiben? (Bitte gezielt, keine Holzhammervorschläge a la neu installieren oder ein stage lokal entpacken)

Früher hat es mit anderen Systemen so auch schon geklappt, allerdings konnte die Zielhardware (Befehlssatz) dann mehr, statt weniger.

(A) = CHOST="i686-pc-linux-gnu"

CFLAGS="-march=atom -O2 -fomit-frame-pointer -pipe"

CXXFLAGS="${CFLAGS}"

(C)=CHOST="i686-pc-linux-gnu"

CFLAGS="-march=pentium-m -O2 -pipe -fomit-frame-pointer"

CXXFLAGS="${CFLAGS}"

Besten Gruß, Andy.

P.S. die CPUInfo's zu beiden gibt's dann wenn ich das nächste mal an den Kisten sitze, hab dann die Safe Cflags dafür verwendet.

----------

## Max Steel

Also ich würde erstmal guggen ob noch irgendwo ein falsch kompiliertes Paket rumfährt.

grep -v march=pentium-m $(find /var/db/pkg | grep CFLAGS) (bitte nicht lachen, ich hab mich mit find noch nicht eingehend beschäftigt)

Auf jeden Fall scheint wohl python noch falsch kompiliert zu sein, hast du evtl python extra CFLAGS gegeben? (unter /etc/portage/env)

----------

## Randy Andy

 *Max Steel wrote:*   

>  Also ich würde erstmal guggen ob noch irgendwo ein falsch kompiliertes Paket rumfährt.
> 
> grep -v march=pentium-m $(find /var/db/pkg | grep CFLAGS) (bitte nicht lachen, ich hab mich mit find noch nicht eingehend beschäftigt)

 

Du meinst sicher nach atom greppen  :Wink: 

Aber die Idee ist schon mal nicht schlecht und setzt mich auf eine neue Fährte.

 *Quote:*   

> Auf jeden Fall scheint wohl python noch falsch kompiliert zu sein, hast du evtl python extra CFLAGS gegeben? (unter /etc/portage/env)

 

Nee, hab ich zwar nicht, aber nun hab ich noch ein paar Ideen wie ich wo ansetzen könnte - danke erst mal für deine Anregung.

Gruß, Andy.

----------

## Max Steel

 *Randy Andy wrote:*   

>  *Max Steel wrote:*    Also ich würde erstmal guggen ob noch irgendwo ein falsch kompiliertes Paket rumfährt.
> 
> grep -v march=pentium-m $(find /var/db/pkg | grep CFLAGS) (bitte nicht lachen, ich hab mich mit find noch nicht eingehend beschäftigt) 
> 
> Du meinst sicher nach atom greppen 
> ...

 

nicht ganz, hiersollte nach allem gegreppt werden das _nicht_ wie march=pentium-m aussieht. Also das Ergebnis praktisch invertiert.

Voraussgesetzt mein Hirn spielt mir mit der Option -v keinen Streich.

(grep --help)

Edith: grade selbst nochmal putty bemüht:

```
grep --help

[...]

  -v, --invert-match        select non-matching lines

[...]
```

Der Vorteil von der Richtung (invertierend nach pentium-m greppen) ist eben das du auch komplett quergeschossene PAkete findest ^^

Edith:

Was mir noch einfällt ist das evtl einfach ein Programm in einer neueren Version mit neuem Slot installiert wurde. (python-2.8 oder python3.2 z.B.) und portage noch auf die Vorgängerversion verweißt (python2.6 oder python3.1 evtl mal mit eselect python update --python2 und eselect python update --python3. DAbei nicht vergessen die versionslose python genauso upzudaten eselect python set <python2.7|python3.2> (je nachdem ob man sich traut python3 systemweit zu verwenden oder weiterhin nur python2), danach sollte nochmal python-updater durchlaufen werden.

----------

## Randy Andy

Hi Max Steel.

Vielen Dank für deine kompetente Hilfe.

Deine grep Syntax hat exakt so wie beschrieben funktioniert.

Danach sah ich dann so ca. 8 nicht mit den neuen CFLAGS übersetzte Pakete.

Speziell die in ihrer Version niederwertigen Python Pakete, die Portage und somit ein emerge benötigt (da ich das so eingestellt habe, bzw ein python-updater das so vorsieht) waren die Ursache.

Das war genau das was ich übersehen hatte und wozu ich einen Denkanstoß brauchte. (Paaf, leichte Schläge auf den Hinterkopf und so...)

Aber so ganz versteh ich trotzdem nicht warum eine --emptytree  Durchlauf nicht konsequent jedes vorhandene Paket neu baut.

Bei einem update system / world baut ja nur die höchste installierte Version neu, dann wär's sowas natürlich vorprogrammiert, hab ich aber nicht gemacht.

Lag's vielleicht daran dass er dann versucht exakt die gleiche Version (wie installiert) zu bauen, die aber nicht mehr verfügbar war, und Portage sie deshalb beim Bau überspringt?

So wie bei nem revdep-rebuild wo man dann per Parameter (-x AFAIR) anweisen kann statt= exakter Version, die nächste verfügbare zu verwenden. - vermutlich gelle.

Na ja, Egal. Das Ergebnis zählt, und nun passt's. 

Vertrauen ist Gut, Kontrolle ist besser. Und nun weiss ich auch wie ich's kontrollieren kann.

Vielen Dank Max. Case is solved. 

Werde in Bälde den Post als solchen markieren....

Gruß, Andy.

----------

## Max Steel

Nein, -e @world sagt nur, "denke es sei nichts vorhanden und löse den Tree normal auf."

d.h. wenn ein altes noch verwendetes Paket existiert aber nicht upgedatet wird, wird dieses garnicht neu gebaut sondern erst der Nachfolger. Oder möglicherweiße wurde hier portage ohne ein python2 Flag installiert, dann heißt die DEP nehme das älteste:

 *Quote:*   

> python_dep="python3? ( =dev-lang/python-3* )
> 
>         !python2? ( !python3? (
> 
>                 build? ( || ( dev-lang/python:2.7 dev-lang/python:2.6[threads] ) )
> ...

 

Und wenn dann python2 ausgewählt ist, läuft portage gegen die Wand.

Zumindest versteh ich das so.

----------

## Randy Andy

Alles Klar,

und nochmals Dank.

Habe den thread nun auf solved gesetzt.

----------

