Profile-Migration zu 17.1

[nisto]

@nisto
Mir wäre nicht aufgefallen das beim Wechsel von 17.0 zu 17.1 irgendetwas an der Startkonfiguration (welche Dienste/Treiber wann und unter welchen Bedingungen gestartet/geladen werden) verändert würde.

Ich konnte bei meiner kurzen Suche im Netz auch nichts finden. Es trat aber just das 1.Mal nach dem Profilwechsel auf, vielleicht auch Zufall. Am Wochenende will ich mich noch mal ein bisschen im System umsehen.

[tazinblack]

Heute hat mir "eselect news" ja nahe gelegt ich solle doch mal von meinem 17.0 Profil auf 17.1 migrieren. Die Sache wirkte ziemlich abenteuerlich (vor allem wegen dem Inhalt der News) aber eigentlich war es dann halb so schlimm, es mussten gerade mal drei Pakete neu gebaut und installiert werden.
sys-devel/gcc
sys-libs/glibc
sys-apps/sandbox

Wie wars bei euch? Auch so simpel oder der totale Systemcrash.

Ich habs noch nicht angefangen. Was für ein Profil hast Du denn verwendet / verwendest Du denn genau?
Mir stellt sich die Frage, wie lange das 17.0 Profil noch vorhanden sein wird.

[schmidicom]

Was für ein Profil hast Du denn verwendet / verwendest Du denn genau?

Bei meinem PC und Laptop ging die Reise von "default/linux/amd64/17.0/desktop/plasma/systemd" zu "default/linux/amd64/17.1/desktop/plasma/systemd".

Mir stellt sich die Frage, wie lange das 17.0 Profil noch vorhanden sein wird.

Keine Ahnung aber jetzt wo 17.1 als stable angesehen wird dürfte es wohl nicht mehr lange dauern bis 17.0 als obsolete markiert und dann irgendwann ganz raus fliegt.
Ich selbst müsste noch einen letzten Server umstellen aber das werde ich bei diesem erst machen wenn der Moment günstig ist, wenn also bei einem eventuellen Ausfall nicht all zu viele betroffen sind. Hoffentlich bleibt bis dahin das Profil noch am leben.

[ManfredB]

Ich bin gerade dabei, einen neuen Versuch zu starten:

Installation sofort mit Profil 17.1 - wie gehe ich vor.

Ich habe in einer chroot-Umgebung erst einmal
app-portage/unsymlink-lib installiert,
dann habe ich eins nach dem anderen durchgeführt:
unsymlink-lib --analyze
unsymlink-lib --migrate
unsymlink-lib --finish

Danach eselect profile list,
eselect profile set 23
plasma

emerge --ask --verbose --update --deep --newuse @world

Und nun werden 263 Pakete aktualisiert - ohne Fehler bisher.

Fazit: es geht auch erheblich schneller so.

Ob es am Ende noch irgendein Problem gibt, teile ich mit, wenn dieses Update fertig ist.

Gruß
Manfred

Fazit: das Basis-System ist direkt mit Profil 17.1 erfolgreich installiert worden.

[mike155]

dürfte es wohl nicht mehr lange dauern bis 17.0 als obsolete markiert und dann irgendwann ganz raus fliegt.

Ich habe die Umstellung recht genau mitverfolgt. Bei mir lief alles relativ problemlos - aber in den englischsprachigen Foren gab es viele Support-Anfragen. Teilweise hatten 20-30% der Anfragen damit zu tun. Mittlerweile ist der Anteil der Support-Anfragen wieder etwas geringer geworden. Aber dafür sehe ich viele Anfragen (zu anderen Themen), bei denen aus 'emerge --info' hervorgeht, dass die User noch Profil 17.0 verwenden - und gar nicht planen, auf 17.1 zu wechseln.

Ein größerer Teil der Gentoo User hat also wohl noch gar nicht auf Profil 17.1 umgestellt. Vermutlich werden diese User auch erst denn wechseln, wenn sie müssen. Falls also Profil 17.0 in naher Zukunft entfernt werden sollte, wird es noch mal einen ganzen Schwung verzweifelte User geben.

[Max Steel]

Okay, also ich bin jetzt auch dabei auf einem Arbeits-PC...
Soweit so smooth. beim rebuild der Programme in /usr/lib32 (und co) brechen mir die ganzen libX* Libs mit Fehler während dem Configure ab. ein Blick in die Fehlermeldung und die Buildorder scheint etwas zutage zu befördern:

Code: Select all

checking for nl_langinfo... yes
checking for X11... no
configure: error: Package requirements (xproto >= 7.0.17 xextproto xtrans xcb >= 1.11.1 kbproto inputproto) were not met:

No package 'xcb' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables X11_CFLAGS
and X11_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

In der Buildorder ist libxcb vorhanden. aber erst später:

Code: Select all

These are the packages that would be merged, in reverse order:

Calculating dependencies... done!
[ebuild   R    ] sys-libs/gpm-1.20.7-r2::gentoo  USE="(-selinux) -static-libs" ABI_X86="32 (64) (-x32)" 0 KiB
[ebuild   R    ] dev-db/sqlite-3.28.0:3::gentoo  USE="icu readline secure-delete -debug -doc -static-libs -tcl -test -tools" ABI_X86="32 (64) (-x32)" 0 KiB
[ebuild   R    ] x11-libs/libxcb-1.13.1:0/1.12::gentoo  USE="xkb -doc (-selinux) -static-libs -test" ABI_X86="32 (64) (-x32)" 0 KiB
[ebuild   R    ]  x11-base/xcb-proto-1.13::gentoo  ABI_X86="32 (64) (-x32)" PYTHON_TARGETS="python2_7 python3_6 -python3_5 -python3_7" 0 KiB

Warum er die lib nicht findet, obwohl diese ja offiziell vorhanden sein müsste und nur rebuilded wird, erschließt sich mir nicht ganz.
/usr/lib/libX11-xcb.so
Aber egal, ich hab den mit --keep-going gestartet, also erstmal abwarten, wenn alles gut geht muss ich den rebuild einfach nur nochmal durchführen.

Keine Ahnung.

Edith sagt:

Das selbe passiert beim Paket dev-libs/glib wegen libmount (aus dem Paket sys-apps/util-linux)

Edith die 2.:
für glib hat sich das bewahrheitet.

Okay. also wird der Rest auch durchreiten.

Edith die letzte:

Wie gesagt, ein zweiter Run von emerge -1v --deep /lib32 /usr/lib32 /usr/lib/llvm/*/lib32 lief jetzt problemlos durch. Er hat z.G. auch beim zweiten mal nur die Ebuilds mit Fehlern gezogen.
Auf jedenfall war das seltsam.

[ChrisJumper]

Auf zwei Systemen hatte ich bisher keine Probleme. Zuerst immer aktuallisiert und dann wie in den News vorgegangen.

Aber jetzt....:

Code: Select all

# unsymlink-lib --analyze
/usr/lib needs to be a symlink to lib64!

Code: Select all

 /usr # ls -lah lib
lrwxrwxrwx 1 root root 7 11. Jul 03:14 lib -> ./lib64

Übersehe ich etwas? Aktuell verwende ich das Profil 17.0.

Edit: Solved.

Code: Select all

 # cd /usr
# rm lib && ln -s lib64 lib

Dann geht's. Es hatte sich wohl nur an dem relativen Angabe verschluckt. Ich musste lediglich zwei drei alte Pakete noch entfernen wie: x11-apps/mkfontdir, oder x11-libs/libXp.

Aber das wurde dann gemeldet mit dem Hinweis das es im aktuellen Tree ein solches Paket nicht mehr gibt und das System diese Abhängigkeit deswegen nicht mehr neu bauen kann.

Tipp: an alle die es noch vor sich haben:
- Zuvor schauen das emerge -u @world durch gelaufen ist. Wie in der Anleitung der News von Profil 17.0 auf 17.1 zu wechseln ist dann relativ unkompliziert.

Wenn man es noch nicht gemacht hat, also ein sehr altes System auf den neuen Stand hebt, vielleicht auch noch pearl und python zuvor aktualisieren. Wenn man es verwendet auch die qt Pakete.

Läuft dann emerge -u @world durch und findet auch keine weiteren Aktualisierungen sieht es schon sehr gut aus.

Tipp 2:
Wenn man sich sicher ist das man bestimmte Compilervarianten nicht in mehreren Slots benötigt sollte man die vorher entfernen.
Beispielsweise unnötige Slots bei

sys-devel/gcc
sys-devel/llvm
dev-lang/rust

Wobei bei Rust halt kein Slot da ist, aber eine Updatemöglichkeit. Ich freue mich auf schwächeren Systemen über rust-bin. :)

[ManfredB]

Heute habe ich eine Neuinstallation begonnen
und dabei habe ich festgestellt,
daß im Basis-Verzeichnis keine /lib32 und /usr/lib32 mehr vorkommen,
außerdem ist bei der Auswahl des Profils bereits 17.1. voreingestellt,
was man dann noch auswählen kann im selben Profil, zB plasma - wie bei mir - oder
was sonst ausgewählt wird.

Damit ist der ganze Prozess des Ummodelns überflüssig geworden.

Gruß
Manfred

P.S. Das geht nur mit einer Neuinstallation.
Bestehende Installationen mit älteren Profilen müssen den Umwandlungsprozess dennoch durchführen.

[ChrisJumper]

Damit ist der ganze Prozess des Ummodelns überflüssig geworden.

Hi ManfredB,

aber so muss man dann ja die Daten trotzdem migrieren oder das Backup nutzen. Ich vermute auch das man halt mehr Compilieren muss. Aber generell ist es vorteilhaft mal alles zu entfernen was man nicht braucht... als auch ein Backup zu haben, für den Fall das ein Krypto-Trojaner zuschlägt.

Ich fand den Wechsel aber bisher gar nicht so schwierig... muss jetzt nur noch die Server migrieren.

Gruß

Chris

[ManfredB]

Und nun kommt der Hammer:

/usr/portage gibt es nicht mehr.

Unter /var/cache findet man nun 2 Verzeichnisse,
/distfiles
/binpkg

Das zweite ist neu.

Die /usr/portage-Verzeichnisse liegen unter /var/db/repos/gentoo

Ein deutlicher Umbau des Systems - wie ich finde, aber kein Problem.

Gruß
Manfred

[ManfredB]

Ich habe in den letzten Tagen 2 Neuinstallationen durchgeführt.

Eine gentoo-stable und eine gentoo (ACCEPT_KEYWORDS="~amd64")

Ich muss sagen, daß - nach der Einführung von Profil 17.1 - jetzt wieder alles
so einfach ist wie bisher.

Nur die Sache mit /usr/portage (die bei emerge-webrsync als fehlend gekennzeichnet wurde)
hat sich doch aus /usr nach /var verlagert, dort allerdings jetzt mit dem neuen Verzeichnis
/var/db/repos/gentoo.

Bisher habe ich für das Verzeichnis /usr eine 20Gb-Partition zur Verfügung gestellt (33%),
für /var nur 10G (11 %).
Die /root-Partition (10 GB) wird nur mit 36% belastet, das heisst, ich könnte die auch kleiner anlegen.

Aber da ich genügend Platz zur Verfügung habe, spielt das bei mir keine so große Rolle.

Bei der amd64-Installation ist etwas merkwürdiges passiert.
Ein Paket konnte nicht installiert werden, da liefen irrsinnig viele Seiten von Infos über den Bildschirm,
nichts davon konnte ich lesen, weil das Tempo geradezu rasend war.

In der build.log habe ich nichts gefunden, was diesen Fehler verursacht hat.
Da bin ich in mein Verzeichnis, wo ich die buildpkgs speichere, gegangen und habe nach diesem Programm geschaut.
Ich habe es gefunden, auch dieselbe Version, habe statt
emerge --ask sys-~/~
einfach
emerge --ask -k sys-~/~
eingegeben, und was ich kaum glauben konnte,
das Paket wurde anstandslos installiert.

Damit war das Problem auf sehr einfache Weise behoben und ich konnte die restlichen Pakete
auch noch installieren.
Leider weiß ich den Namen des Pakets nicht mehr.

Fazit für mich:
Es macht auf der Basis von Profil 17.1 genauso viel Spaß wie zuvor.

Das wünsche ich allen Gentoo-Freunden, die sich an eine Neuinstallation heranmachen.

Gruß
Manfred

P.S. nun wollte ich die systemd-Variante auch ausprobieren, doch die ist noch nicht so weit.

[ManfredB]

Fazit:

1. Bei einer Umstellung eines bestehenden Systems auf Profil 17.1 bleibt /usr/portage.

2. Bei einer Neuinstallation von gentoo ändert sich das in /var/db/repos/gentoo

Gruß
Manfred