Dann schiebe die Datei nach /usr/lib/firmware und lösche /lib/firmware.
mv /lib/foo /usr/lib/foo
ist was anderes als 
mv /lib /usr/lib
Also ich bekomme die Kernelpanic nicht weg.
Ich habe jetzt schon alles mögliche versucht aber beim boot bekomme ich immer die selbe Meldung.
Switch_root: faild to execute /sbin/init No soch file or directory
Kernel panic -not syncing: Attempted to kill init! exitcode=0x00
Ich weiß echt nicht mehr was ich versuchen soll.
Cool bleiben.
Hatte ich auch bei einem arch64.

Ich habe die lib und lib64 umbenannt.

Dann das:
fs4000 schriebLiveCD: 
mount /dev/sd?? /mnt
mount -t devtmpfs udev /mnt/dev
mount -t proc proc /mnt/proc
mount -t sysfs sys /mnt/sys
pacman -r /mnt -S glibc
umount /mnt/{sys,proc,dev,}
Das ist schon mal ein guter Anfang von fs4000. Ich musste zusätzlich noch folgendes machen:
pacman -r /mnt -S nvidia linux
Dort wurden die Kernelmodule neugebaut. Dann hat er auch die Basismodule wiedergefunden.

Es war ein langer Weg bis dahin, und ich wollte auch schon das System neu aufsetzen, aber immer nach dem Motto:

"Drei Tage war der Frosch nun krank,
jetzt raucht er wieder, Gott sei Dank"

Gruß ein froher tabbi
Hallo,

ich habe gestern auch eine Fresh-Installation von ArchLinux 08.2011 durchgeführt. In den glibc Fehler bin ich auch gelaufen und habe mir so geholfen, daß ich das vorgeschlagene Pacman-Paket-Update verneint habe und erst mal den Rest aktualisiert habe. Danach die glibc 2.16 installiert und danach ein pacman -Su gestartet.

Das hat soweit funktioniert, aber nach dem Reboot habe ich alle Hooks verloren. Ein erneutes mkinitcpio brachte die Fehlermeldung, daß keine Pfade mehr zu den Modulen/Hooks gefunden werden können. Warum es so schlimm ist, die Hooks nicht mehr starten zu können? Ich habe keine ethX-devices mehr nach einem Start, somit kann ich aus den Repos nichts mehr nachladen. Danach habe ich erst mal gestoppt, denn 2 Stunden für Problemsolving für eine OutoftheBox Installation erschien mir mehr als genug zu sein.

Wann wird eigentlich ein neues ISO Installationsfile von ArchLinux erwartet? Ich glaube, nach so vielen Änderungen an der Basis wäre das ein sehr sinnvoller Schritt.
ich hab das ganze (dummerweise) auch mit --force durchgezogen und landete demzufolge auch hier ... aber wenn ich eins bei Linux gelernt habe, falls man mal so lange am Ast rumgeschnitzt hat, auf dem man sitzt und der wurde so dünn, dass er durchbrach, dann kann man einen neuen Stamm dort einbauen und den Ast von vorn wieder beginnen zu schnitzen

Dank fs4000 und cipher hab ich den initialen Start hinbekommen (etwas abgewandelt)
mount /dev/sd?? /mnt
mount -o bind /dev/ /mnt/dev
mount -t proc proc /mnt/proc
mount -t sysfs sys /mnt/sys
wie weiter unten bei jaxen zu sehen ist, sollten alle anderen Partitionen ebenfalls gemountet werden, entsprechend dem Mountpoint wie sie im System später auch vorhanden sind. Ich hatte nur noch /home, was bei einem Updateprozess nicht wirklich erforderlich ist
dann /lib versetzt und Symlinks erstellt
mv /mnt/lib /mnt/test
ln -s /mnt/usr/lib /mnt/lib
ln -s /mnt/usr/lib /mnt/lib64
und dann glibc noch einmal installiert
pacman -r /mnt -S glibc
anschliessend konnte ich per chroot dort rein wechseln (vorher noch Netzwerk aktivieren)
dhcpcd eth0
chroot /mnt/ /bin/bash
dort dann nochmal den fehlgeschlagenen Updateprozess beenden, sind jedoch deutlich mehr Pakete (vermutlich durch das fehlende lib Verzeichnis)
pacman -Syu
da ich hier noch einige Überreste aus dem alten Filesystem hatte, musste hier ebenfalls noch einmal mit --force arbeiten (leider). Anschliessend war zumindest ein Start des Systems möglich, leider jedoch kein login (er warf mich direkt wieder in die Login-Console ohne Abfrage nach dem Kennwort). Nachträglich nochmal von der CD gebootet und in die Logs geschaut, es gab kein /bin/login. Da die mittlerweile im Paket util-linux liegen, das nochmal nachgeschoben
pacman -S util-linux
und schon ging alles wieder! Da ich meine restlichen Daten Gott-sei-Dank alle noch vorher gesichert und eine separate /home Partition besaß, konnte ich mir das erlauben ... also bitte mit vorsicht behandeln!

Gruß Maddin

P.S.: ich hab jetzt lediglich noch einen Ordner test, quasi den alten "lib" Ordner
# find /lib -exec pacman -Qo -- {} +
Fehler: Kann die Eigentumsrechte am Verzeichnis '/lib' nicht bestimmen
/lib/libnss_hesiod.so.2 ist in glibc 2.16.0-1 enthalten
/lib/libnss_db.so.2 ist in glibc 2.16.0-1 enthalten
/lib/libthread_db.so.1 ist in glibc 2.16.0-1 enthalten
/lib/ld-linux-x86-64.so.2 ist in glibc 2.16.0-1 enthalten
/lib/librt-2.16.so ist in glibc 2.16.0-1 enthalten
/lib/libresolv.so.2 ist in glibc 2.16.0-1 enthalten
/lib/libresolv-2.16.so ist in glibc 2.16.0-1 enthalten
/lib/libpthread-2.16.so ist in glibc 2.16.0-1 enthalten
/lib/libcidn.so.1 ist in glibc 2.16.0-1 enthalten
/lib/libBrokenLocale.so.1 ist in glibc 2.16.0-1 enthalten
/lib/libnss_compat-2.16.so ist in glibc 2.16.0-1 enthalten
/lib/libnss_nis-2.16.so ist in glibc 2.16.0-1 enthalten
/lib/ld-2.16.so ist in glibc 2.16.0-1 enthalten
/lib/libnss_db-2.16.so ist in glibc 2.16.0-1 enthalten
/lib/libpthread.so.0 ist in glibc 2.16.0-1 enthalten
/lib/libcidn-2.16.so ist in glibc 2.16.0-1 enthalten
/lib/libutil-2.16.so ist in glibc 2.16.0-1 enthalten
/lib/libm.so.6 ist in glibc 2.16.0-1 enthalten
/lib/librt.so.1 ist in glibc 2.16.0-1 enthalten
/lib/libthread_db-1.0.so ist in glibc 2.16.0-1 enthalten
/lib/libc-2.16.so ist in glibc 2.16.0-1 enthalten
/lib/libmemusage.so ist in glibc 2.16.0-1 enthalten
/lib/libc.so.6 ist in glibc 2.16.0-1 enthalten
/lib/libnss_nis.so.2 ist in glibc 2.16.0-1 enthalten
/lib/libm-2.16.so ist in glibc 2.16.0-1 enthalten
/lib/libutil.so.1 ist in glibc 2.16.0-1 enthalten
/lib/libnsl-2.16.so ist in glibc 2.16.0-1 enthalten
/lib/libdl-2.16.so ist in glibc 2.16.0-1 enthalten
/lib/libnss_hesiod-2.16.so ist in glibc 2.16.0-1 enthalten
/lib/libnss_nisplus-2.16.so ist in glibc 2.16.0-1 enthalten
/lib/libnss_files-2.16.so ist in glibc 2.16.0-1 enthalten
/lib/libanl-2.16.so ist in glibc 2.16.0-1 enthalten
/lib/libnss_files.so.2 ist in glibc 2.16.0-1 enthalten
/lib/libanl.so.1 ist in glibc 2.16.0-1 enthalten
/lib/libnss_nisplus.so.2 ist in glibc 2.16.0-1 enthalten
/lib/libnss_dns-2.16.so ist in glibc 2.16.0-1 enthalten
/lib/libpcprofile.so ist in glibc 2.16.0-1 enthalten
/lib/libdl.so.2 ist in glibc 2.16.0-1 enthalten
/lib/libcrypt.so.1 ist in glibc 2.16.0-1 enthalten
/lib/libnsl.so.1 ist in glibc 2.16.0-1 enthalten
/lib/libSegFault.so ist in glibc 2.16.0-1 enthalten
/lib/libnss_dns.so.2 ist in glibc 2.16.0-1 enthalten
/lib/libnss_compat.so.2 ist in glibc 2.16.0-1 enthalten
/lib/libBrokenLocale-2.16.so ist in glibc 2.16.0-1 enthalten
/lib/libcrypt-2.16.so ist in glibc 2.16.0-1 enthalten
so getan und trotzdem
# pacman -Su
:: Starte komplette Systemaktualisierung...
Löse Abhängigkeiten auf...
Suche nach Zwischenkonflikten...

Pakete (1): glibc-2.16.0-2

Gesamtgröße der zu installierenden Pakete: 37,58 MiB
Größendifferenz der Aktualisierung:       0,00 MiB

Installation fortsetzen?  [J/n] 
(1/1) Überprüfe Paket-Integrität                                                                                        [########################################################################] 100%
(1/1) Lade Paket-Dateien                                                                                                [########################################################################] 100%
(1/1) Prüfe auf Dateikonflikte                                                                                          [########################################################################] 100%
Fehler: Konnte den Vorgang nicht durchführen (In Konflikt stehende Dateien)
glibc: /lib existiert im Dateisystem
Fehler sind aufgetreten, keine Pakete wurden aktualisiert.
Hast du auch den grep-Aufruf aus dem wiki ausgeführt?

cu
@piet 
# grep '^lib/' /var/lib/pacman/local/*/files | grep -v glibc
/var/lib/pacman/local/tp_smapi-0.41-2/files:lib/
/var/lib/pacman/local/tp_smapi-0.41-2/files:lib/modules/
/var/lib/pacman/local/tp_smapi-0.41-2/files:lib/modules/3.0-ARCH/
/var/lib/pacman/local/tp_smapi-0.41-2/files:lib/modules/3.0-ARCH/extra/
/var/lib/pacman/local/tp_smapi-0.41-2/files:lib/modules/3.0-ARCH/extra/hdaps.ko.gz
/var/lib/pacman/local/tp_smapi-0.41-2/files:lib/modules/3.0-ARCH/extra/thinkpad_ec.ko.gz
/var/lib/pacman/local/tp_smapi-0.41-2/files:lib/modules/3.0-ARCH/extra/tp_smapi.ko.gz
und nu?
Probier doch mal, zunächst tp_smapi einzeln zu installieren und dann die glibc. Wenn das nicht klappen sollte, kannst Du auch temporär die tp_smapi deinstallieren, glibc installieren und tp_smapi wieder nachschieben.

Ich hatte bei meinem Samsung NC10 ein gleichartiges Problem mit dem 'easy-slow-down-manager'.

VLG
Stephan
@Xukashi

Das tp_smapi Paket stammt jawohl aus dem AUR, ist also von dir? Oder?
Scheint ja 'nur' für Einstellungen zu sein und müsste problemlos zu entfernen sein (und deiner Büchse funktioniert weiter). Also runter damit und dann pacman walten lassen.
Anschließend musst du schauen, ob du es aktualisieren musst oder ob die Pfade schon richtig angepasst worden sind.

Mit dem grep-Aufruf bin ich über hal gestolpert und habe ihn entfernt und pacman konnte das neue glibc-Paket installieren.

cu
ah thx, lag an tp_smapi, jetzt gings
Also ich habe jetzt alles wie kruemeltee beschrieben hat gemacht und es hat soweit funktioniert, nur beim updaten hatte ich ein paar Fehlermeldungen, dass Verzeichnisse wie boot nicht gefunden wurden und jetzt findet er /dev/sda7 beim booten nicht.
Ich habe zuerst Ubuntu auf meinem Rechner installiert und dort ist auch grub2 drauf, deshalb habe ich versucht, von Ubuntu aus, ein update zu machen. Jetzt ist der der Eintrag in der grub.cfg auch weg.

Sollte ich das Ubuntu root Verzeichnis mit boot auch mounten?

Vielleicht kann mir ja wer noch bei diesem Problem helfen.
@jaxen

prinzipiell solltest Du vor dem chroot alle mountpoints so setzen, dass sie auch dort gemountet sind, wo sie vorher auch lagen. Bei einigen Verzeichnissen ist dies nicht unbedingt erforderlich (z.B.: home), aber der Ordner /boot sollte beim Updaten auf jeden Fall dabei sein. Grundsätzlich würde ich empfehlen, alle Partitionen zu mounten, und zwar dort wo sie hingehören. Dann das chroot dort hinein und los gehts.
Bei mir war das nicht erforderlich, da das System, welches hier bei mir den Fehler hatte, nicht mein Großrechner war, sondern mein kleiner Homeserver, der lediglich zwei Partitionen hat, nämlich / und /home (SWAP lass ich jetzt mal aussen vor).

Gruß Maddin
Ja danke, man lernt nie aus, obwohl ich mir das hätte denken können.

Die grub.cfg hab ich mittlerweile wieder soweit dass ich einen Eintrag dort habe, auch wenn er noch nicht booted aber dass sollte ich hin bekommen.
r3vilo schrieb... Die Frage stellt sich mir aber trotzdem, warum dass nicht automatisch sauber durchläuft? Bei einem kompletten Systemupgrade, wenn doch bekannt bzw. sogar gewollt ist das /lib nach /usr/lib umzieht, warum wird das nicht auch gleich korrekt eingerichtet? Die Macher wissen doch, wie es sein soll/muss? Warum kommt es zu diesem Komplikationen? Sonst steht doch auch immer DIES-UND-DAS wurde durch DIES-UND-JENES ersetzt o.ä. bzw. /AAA/BBB ist jetzt in /CCC/AAA/BBB. ... Klar kommt ein Warnhinweis durch pacman, aber man sieht ja, was das trotzdem für Probleme auslösen kann...
OK, nach weiterem Einlesen - und ja, das tue ich in der Regel VORHER - ist mir klar geworden, dass das Update eigentlich keine Probleme macht. Klar, es kümmert sich um seine eigenen Sachen - so soll u. kann es ja auch nur sein - und sagt ja auch, dass man andere installierte Programme, die jetzt noch davon abhängen, auch erstmal updaten bzw. neu bauen soll. Und nur dann geht's weiter.

Ich habe das vorher wohl falsch interpretiert u. mich geärgert warum da jetzt bestimmte Fehler auftreten. Und hey, ich habe nichts gegen pacman bzw. das Paketmanagement in Arch. Im Gegenteil: Ich liebe es! Pacman war einer meiner Hauptgründe warum ich damals zu Arch gewechselt bin. Was besseres hab ich noch nicht gesehen! Und das meine ich ernst.

Man sollte nur mal kurz ganz nüchtern darüber nachdenken was man tut bzw. lesen was da steht u. auch nur genau das tun. Dann funktioniert auch alles.

EDIT: Ups, aus versehen meinen ursprünglichen Beitrag editiert, statt neu zu antworten. Jetzt ist er weg. Blöd. ... Naja, der Hauptkern steht ja noch da.

Ergänzung:
Bei mir hat bei einer Kernel Panic das downgraden der glibc geholfen, dass das System erstmal wieder lief bzw. im ZUSTAND VOR DEM UPDATE war.

Voraussetzung ist ein noch vollständiges Verzeichnis /lib in dem noch alle Dateien drin sind. Meines war zerschossen u. es war nur noch eine lib-irgendwas.so.1 und das modules-Verzeichnis drin. Darum habe ich mir das /lib meines Desktop-PCs rübergezogen u. wie gesagt das Downgrade der glibc durchgeführt. Vorher natürlich mit Boot-USB-Stick gebootet u. mein eigentliches root nach /mnt gemountet. Das Downgrade funktioniert dann folgendermaßen:
pacman -r /mnt -U /mnt/var/cache/pacman/pkg/glibc-2.16.0.1-x86_64.pkg.tar.gz
oder bei 32-Bit Systemen
pacman -r /mnt -U /mnt/var/cache/pacman/pkg/glibc-2.16.0.1-i686.pkg.tar.gz
Dazu muss natürlich das alte glibc-Paket noch im cache-Verzeichnis sein. Mit der glibc-2.16.0.1 funktionierte dann ein Reboot, während wie gesagt die Version 2.16.0.2 eine Kernel-Panic hervorrief. So kann man dann erstmal wieder normal weiter arbeiten u. sich überlegen ob man das mit dem Update jetzt durchzieht oder erstmal sein lässt. Je nach dem.
Zu versuchen, einen Paketmanager zu schreiben, der intelligenter ist als der durchschnittliche User, geht in der Regel schief. Da kommt dann sowas wie apt raus, das strunzdumm ist, dir aber vollautomatisch das System zerschießen kann, weil es glaubt, dass es die Fehler doch irgendwie noch automatisch korrigieren zu können. Da hab ich Archs Ansatz ehrlich gesagt lieber, wo pacman dem User überlässt sich ins Knie zu schießen, bzw. vorbeizuzielen. 😉
Das mit dem Verzeichnisinhalt löschen, und dann mit pacman -Su glibc neu installieren hat nicht funktioniert.
pacman -U ... will auch nichts bringen.
Wieso kann man nicht einfach irgendein Verzeichnis irgendwohin kopieren, und dann glibc neu installieren?
Warum muss die Welt nur so kompliziert sein?????

lg, Sanni

  • [gelöscht]

  • Beitrag Nr. 40
sanni schrieb Wieso kann man nicht einfach irgendein Verzeichnis irgendwohin kopieren, und dann glibc neu installieren?
Ist das eine rhetorische Frage?
pacman -Syu --ignore glibc
pacman -Su

liefen bei mir ohne Fehlermeldung durch


$ find /lib -exec pacman -Qo -- {} +
ergibt: /lib ist in glibc 2.16.0-2 enthalten

https://wiki.archlinux.org/index.php/DeveloperWiki:usrlib sagt:

"If any package apart from glibc is listed as owning a file, that package needs to be updated to install its files in /usr/lib. Any files unowned by a package should either be deleted or moved to /usr/lib and any directories within /lib need deleted (after they are empty...)."

Heisst das, ich muss alle Unterverzeichnisse von /lib löschen?