# Hardare upgraden und System erhalten

## s|mon

Nach langer Zeit will ich mir mal wieder ein Hardware Upgrade gönnen. Aktuell

nutze ich einen Intel Core 2 Quad 9550 auf einem Intel DP45SG Board (Knapp 10 Jahre alt).

Geplannt sind ein Ryzen 3700x auf einem x570 Board. Aufgrund der Unterschiede

werde ich natürlich mein System nicht 1:1 wieder nutzen können, möchte aber

auch nicht bei 0 starten.

Aktuell plane ich folgende Schritte:

1. Erstellen eines Systembackups (Boot und Root Partitionen)

2. Brennen einer aktuellen Live-CD falls nötig 

3. Kernel update um die neue CPU zu unterstützen

 *Quote:*   

> CONFIG_NR_CPUS : 8
> 
> 	CONFIG_PERF_EVENTS_AMD_POWER
> 
> 	CONFIG_MICROCODE_AMD	
> ...

 

Abgleich mit https://wiki.gentoo.org/wiki/Ryzen

4. Anpassen der make.conf mit leeren oder neutralen CFLAGS

	Aktuell enthalten sind:

 *Quote:*   

> CFLAGS="-march=native -O2 -pipe -w"
> 
> 	CPU_FLAGS_X86="mmx mmxext sse sse2 sse3 sse4_1 ssse3"
> 
> 	CXXFLAGS="${CFLAGS}"
> ...

 

Reicht es wenn ich -march=native entferne?

5. Emerge -ev @System 

6. Clonen der Partitionen ins neue System

7. Booten ins neue System

8. Anpassen der make.conf auf die neue HW (march=native oder znver1 oder geht schon znver2 mit gcc-9.2.0?)

9. Emerge -av @world 

10. Warten & reboot

Oder gibt es sinnvollere alternativen (z.B. eine Stage3 Neuinstallation und

anschließendes ersetzen von /etc und world-file?)

Hinweise bezüglich Hardwareauswahl unter Linux sind sehr willkommen, von Problemen mit dem Chipsatz unter Linux habe ich jedoch noch nichts gelesen.

Danke vielmals

s|mon

----------

## firefly

Der Intel Core 2 Quad ist so alt das alle features, welche die CPU unterstützt AFAIK vom den Ryzen 3xxx unterstützt werden.

Daher sollte das System starten, nachdem der kernel an die Unterschiede vom Mainboard angepasst wurde.

Was du auch machen kannst ist via einer live-cd zu booten und dann ein chroot in dein gentoo system zu machen und dort dann den rebuild aller pakete anzustoßen (wobei das vermutlich nicht notwendig ist)

----------

## s|mon

Das hört sich ja gut an. D.h. nach Backup und Clonen (+Kernelfeatures) direkt ein Bootversuch und wenn  der nicht klappt mittels chroot rebuild.

Dürfte auf alle Fälle Zeit sparen.

Danke schon einmal für den Hinweis - muss eh noch auf die Hardware warten.

----------

## mike155

s|mon, der von Dir beschriebene Weg ist der "sichere" Weg. Auf "wichtigen" Produktivsystemen würde ich es vermutlich so oder so ähnlich machen.

Auf meinen eigenen System wäre ich etwas experimentierfreudiger - um Zeit zu sparen und meine Abenteuerlust zu befriedigen.  :Smile: 

Wie Firefly schon schrieb, ist die Wahrscheinlichkeit hoch, dass Dein altes System auch mit dem neuen Mainboard und der neuen CPU läuft. Also würde ich die alte Festplatte einfach mal an das neue System hängen und schauen, was passiert. Notfalls kannst Du ja von der Live-CD booten und mit chroot ins System wechseln, wie schon von Firefly beschrieben.

Bezüglich clonen: 

Das Gentoo ebuild Repository liegt neuerdings nicht mehr unter /usr/portage, sondern unter /var/db/repos/gentoo. Das würde ich bei der Migration gleich mit umziehen. Dafür muss unter /var natürlich genug Platz sein.

Wenn Deine neue Festplatte eine SSD ist, würde ich für das Clonen nicht "dd" nehmen, sondern "cp -a" o.ä. Hierbei muss sichergestellt werden, dass auch "extended attributes" und "file capabilities" richtig kopiert werden (falls Dein altes System das verwendet, siehe bspw. "/bin/ping"). Da Du ja hinterher sowieso ein "emerge -e @world" starten willst, werden zumindest die von Gentoo-Paketen verwendeten "extended attributes" und "file capabilities" notfalls wieder neu angelegt.

Ansonsten wünsche ich Dir viel Spaß! Dein neues System wird ein ganzes Stück schneller sein!  :Smile: 

----------

## s|mon

Danke für den Hinweis das mit dem ebuild repository wusste ich ich noch gar nicht. werde wohl bis auf home und die distfiles und boot alles in eine root partition legen wie bisher.

Die alte platte ist zwar auch schon eine ssd, allerdings etwas klein.

Die extended attributes sind auch schon aktiv - war mir aber nicht mehr bewusst, danke.

----------

## kurisu

Alles Wesentliche wurde bereits gesagt. Der übliche, und auch mein vielfach bewährter Weg ist chroot via Gentoo Minimal Live ISO. Falls ein brandaktueller Kernel vonnöten ist, bietet sich auch das Arch Live ISO an. Ich hatte erst kürzlich den Fall mit AMD NAVI, das bekanntlich Linux 5.3 voraussetzt.

Im Kern sollte es genügen, den Kernel entsprechend der neuen Hardware neu zu bauen sowie gegebenenfalls die /etc/fstab anzupassen und im Falle von EFI-Stub das NVRAM via efibootmgr zu beschreiben.

Mit gcc-9.2.0 ist -march=native die beste Wahl. Selbst mit einem neuen Ryzen 3000 bzw. Zen 2.

Ein emerge -e @world in der chroot Umgebung ist angesichts der zuvor verwendeten Hardware nicht nur nicht zu empfehlen, sondern auch völlig überflüssig. Denn wie schon von firefly dargelegt, beherrscht deine CPU selbstverständlich alle Features eines Core 2 Quad.

----------

## s|mon

Danke nochmal und eine kurze Rückmeldung nachdem das gröbste geschafft ist:

Alle Tipps hier waren gut und haben geholfen - habe natürlich dennoch einige (z.T. selbst gemachte) Stolperstellen gehabt.

1. Ich hatte zwar nvme support im Kernel aber nur als Modul und selbiges nicht geladen was dem boot von einer nvme Platte nicht förderlich ist.

2. FB Support - Nachdem ich aktuell im UEFI Mode boote musste ich noch CONFIG_FB_EFI=y setzen da ich sonst vom booten bzw. hilfreichen Meldungen zu Fehlern nichts bekommen würde.

3. Ich habe auch aktuell noch eine boot Partition zusätzlich zur extra EFI die ich aktuell nicht nutze - hier muss ich noch raus finden was ich Konfigurieren muss das der Kernel auch dort gefunden würde (aktuell habe ich /boot als Verzeichnis auf root=

4.  *Quote:*   

> BusID          "PCI:1:0:0"

  zum Device bei xorg.conf ist nicht nur unnötig sondern verhindert den X-start wenn die  Grafikkarte nun woanders steckt  :Wink: 

5. Bug 667362 zu nvidia-udev.sh hat mir einige neue graue Haare gebracht - die nächste Karte wird wohl eher AMD, aber ein Wechsel steht eigentlich nicht an - ist ja noch schnell genug. Der Workaround scheint zu helfen aber ist keine Dauerlösung.

6. Falsche Konfiguration für den Ethernet Chip im Kernel - habe ich schlecht geraten (die Support Seiten der Hersteller sparen ja auch gerne mit wichtigen Informationen) - aber kostet ja nur einen Reboot

Offene Baustellen - sobald mal wieder etwas mehr Zeit ist.

1. der Switch zu "/var/db/repos/gentoo" aus dem Hinweis von mike155

2. Nach suspend/resume war das System sehr träge: browser scroll mit Verzögerung usw.

3. nvidia-udvev.sh (siehe bug)

Irgendwas fehlt immer noch  :Wink:  - aber ich bin froh das mein Gentoo System wie gewohnt läuft nur eben ein wenig flotter.

P.S. und ein Lob auf Magic SysRq

----------

