YOU: waiting for /dev/hda5 to appear nach Kernelupdate
Hallo, ich habe heute mal wieder ein Online-Update über meine Suse 9.1 laufen lassen. Kernel wurde ein neuer geholt, was auch funktioniert hat. Ich hab jedenfalls keine Fehler bemerkt. Nur startet die Kiste jetzt nicht mehr. Da wird jetzt beim Booten auf /dev/hda5 gewartet, was meine /-Partition ist. Die erscheint anscheinend nicht, und ich werd in eine "Shell/Prompt"-Wasauchimmer geschmissen. Da geht dann nur noch reboot per STRG-ALT-ENTF. Hab eine Mail in der Liste gefunden, die leider ohne Antwort blieb. Auch eine Google-Suche hat nix ergeben. Und von Windows aus kann ich sonst net viel machen. Was nu? Wer weiss Rat? Danke, OJ -- Insane people throw computers out of windows, sane people...
Am 22.06.2005 21:22 schrieb Johannes Kastl: Was ich noch vergass: Die exakte Meldung lautet:
Waiting for device /dev/hda5 to appear: ....not found -- exiting to /bin/sh sh: can't access tty; job control turned off $
Und die alte Mail in der Liste war vom Date: Tue, 24 May 2005 22:04:38 +0000 Message-Id: <200505242204.38134.20050524@nitwit.de> http://lists.suse.com/archive/suse-linux/2005-May/2143.html OJ -- make bzImage, not war.
Am Mittwoch 22 Juni 2005 21:25 schrieb Johannes Kastl:
Am 22.06.2005 21:22 schrieb Johannes Kastl:
Was ich noch vergass:
Die exakte Meldung lautet:
Waiting for device /dev/hda5 to appear: ....not found -- exiting to /bin/sh sh: can't access tty; job control turned off $
Exakt genauso ist es bei mir! Und ich dachte schon ich wäre der einzige. Das einzige was bis jetzt geholfen hat ist ein booten über die Installations-DVD. Neue Installation und dann installiertes System starten, da funktioniert es dann komischerweise. Ich kriege es auch nicht mehr zum normalen Zustand. Auch ein installieren des Original-Kernels von der DVD hat es nicht mehr in Ordnung gebracht. Gruß Thomas
Am 22.06.2005 22:42 schrieb Thomas Janssen:
Exakt genauso ist es bei mir! Und ich dachte schon ich wäre der einzige. Das einzige was bis jetzt geholfen hat ist ein booten über die Installations-DVD. Neue Installation und dann installiertes System starten, da funktioniert es dann komischerweise.
Booten konnte ich das System auch, nur bin ich dann im Runlevel 3 oder so, und gebootet wird der Kernel von der DVD.
Ich kriege es auch nicht mehr zum normalen Zustand. Auch ein installieren des Original-Kernels von der DVD hat es nicht mehr in Ordnung gebracht.
Hab grad hier http://forums.suselinuxsupport.de/lofiversion/index.php/t14040.html ne Anleitung gefunden, das über nen mkinitrd Aufruf zu reparieren. Werds mal versuche. OJ -- Dort wo man Bücher verbrennt, verbrennt man am Ende auch Menschen. (Heinrich Heine, deutscher Dichter, 1797 - 1856)
Am 22.06.2005 22:46 schrieb Johannes Kastl:
Hab grad hier http://forums.suselinuxsupport.de/lofiversion/index.php/t14040.html ne Anleitung gefunden, das über nen mkinitrd Aufruf zu reparieren. Werds mal versuche.
Hat nicht funktioniert. OJ -- [US-Army droht Cheatern] Sicher? Aus historischer Sicht auf die sog. "Präzisionsschläge" der US Armee würde ich eher vermuten, daß die Cruise Missile ins Wohnzimmer meines Nachbarn (der offline ist) einschlägt.(Christoph Dahlen in drsca)
Johannes Kastl schrieb:
Hat nicht funktioniert.
OJ
Was funktioniert hat, ist ein Installieren des alten Kernels von der DVD. Wenn ich mal Lust habe, dann versuch ich den neuen nochmal zu installieren. Aber nicht mehr heute. OJ -- - Macs sind für die, die nicht wissen wollen, warum Ihr Rechner funzt. - Linux ist für die, die wissen wollen, warum er funzt. - DOS ist für die, die wissen wollen, warum er nicht funzt, und - Windows ist für die, die nicht wissen wollen, warum er nicht funzt.
Am Donnerstag, 23. Juni 2005 00:40 schrieb Johannes Kastl:
Johannes Kastl schrieb:
Hat nicht funktioniert.
OJ
Was funktioniert hat, ist ein Installieren des alten Kernels von der DVD. Wenn ich mal Lust habe, dann versuch ich den neuen nochmal zu installieren. Aber nicht mehr heute.
Moin Johannes, na das ist doch mal ne gute Nachricht ;) Wenn Du nun wieder eine funktionierende SuSE 9.1 mit dem default Kernel von der DVD hast würd ich Dir empfehlen nach der Anleitung von T. Hertweck den Kernel nebst Sourcen aud der RPM Datenbank zu entfernen, um Dir dann anschließend den aktuellen Kernel als zweiten Kernel parallel zu installieren. http://www.thomashertweck.de/kernel26.html#rpm Das hat den Vorteil das Du zum einen immer einen default Kernel verfügbar hast falls mal ein Update nicht funktioniert hat, und zum anderen gibt es Dir die Möglichkeit vor einem Kernel Update in den default Kernel zu booten, um dann von dort aus den zu aktualisierenden Kernel erst mal zu löschen um ihn dann sauber in der aktuellen Version neu zu installieren. Ließ Dir das einfach mal durch ... iss wirklich n einfacher Weg sich 'n ReserveKernel auf dem System zu hinterlegen . Gruß Micha
Hallo Michael, Michael Schueller schrieb:
Moin Johannes, na das ist doch mal ne gute Nachricht ;)
Wenn Du nun wieder eine funktionierende SuSE 9.1 mit dem default Kernel von der DVD hast würd ich Dir empfehlen nach der Anleitung von T. Hertweck den Kernel nebst Sourcen aud der RPM Datenbank zu entfernen, um Dir dann anschließend den aktuellen Kernel als zweiten Kernel parallel zu installieren.
Das wollte ich schon lange mal in Angriff nehmen, und mal den Kernel ein bißchen genauer kennen lernen.
http://www.thomashertweck.de/kernel26.html#rpm
Das hat den Vorteil das Du zum einen immer einen default Kernel verfügbar hast falls mal ein Update nicht funktioniert hat, und zum anderen gibt es Dir die Möglichkeit vor einem Kernel Update in den default Kernel zu booten, um dann von dort aus den zu aktualisierenden Kernel erst mal zu löschen um ihn dann sauber in der aktuellen Version neu zu installieren.
Eigentlich sollte ja das Update per YOU klappen, die haben ja auch alle eine Suse 9.1, und da scheint er ja zu funktionieren. Warum es nicht ging, werd ich rausfinden, wenn ich mal Muse habe.
Ließ Dir das einfach mal durch ... iss wirklich n einfacher Weg sich 'n ReserveKernel auf dem System zu hinterlegen .
gute Idee.
Gruß Micha
OJ -- Arroganz ist die Kunst, auf seine eigene Dummheit stolz zu sein.
Hallo nochmal, Michael Schueller schrieb:
Da steht man kann ein Paket nur "aus der RPM-Datenbank" entfernen, so dass die Dateien noch installiert sind, aber rpm nix mehr davon weiss. Hab das mal probiert mit quanta (weil das das erste war dass mir eingefallen sit das keine Abhängigkeiten hat):
RobinLinux:/Daten4/fuer_apt/archives # suche_rpms quanta quanta-3.2.3-3 RobinLinux:/Daten4/fuer_apt/archives # rpm -e --justdb quanta-3.2.3-3 RobinLinux:/Daten4/fuer_apt/archives # suche_rpms quanta RobinLinux:/Daten4/fuer_apt/archives #
Wie werd ich das Paket denn dann endgültig mal los? Paket wieder installieren und dann deinstallieren? So gins bei mir jetzt, aber wie ist der "offizielle" Weg? OJ -- Ich weiss nicht mehr, wer es war, aber ich habe [...] mal jemanden gehört, der in einer solchen Diskussion die Aussage, AIDS sei eine Strafe Gottes, locker mit "das heisst also, dass die Lesben das auserwählte Volk Gottes sind" gekontert hat. (Adrian Suter)
Hallo Johannes, hallo Leute, Am Donnerstag, 23. Juni 2005 15:34 schrieb Johannes Kastl: [...]
RobinLinux:/Daten4/fuer_apt/archives # rpm -e --justdb
Wie werd ich das Paket denn dann endgültig mal los? Paket wieder installieren und dann deinstallieren? So gins bei mir jetzt, aber wie ist der "offizielle" Weg?
Genau der. Nur wenn RPM Ahnung von einem Paket hat (was nach -e --justdb eben nicht mehr der Fall ist), kann es dieses Paket auch löschen. Das Löschen eines nichtexistenten Pakets wird schwierig ;-) Alternative: Sichere vor dem rpm -e die Dateiliste des Pakets (rpm -ql paket > dateiliste) und lösche die Dateien anschließend von Hand. Viel Spaß dabei. *g* Gruß Christian Boltz -- Wir sind ja nicht nachtragend, Du wirst uns wieder herzlich willkommen sein, wenn der erste Virus Deine Festplatte formatiert haben wird. Und dann ist auch wieder Platz da fuer Linux :-) [Wolfi in suse-laptop]
Hallo, sorry dass die Antwort so lange gedauert hat, aber irgendwie kamen keine neuen Mails mehr an. Warum? Keine Ahnung. Christian Boltz schrieb:
Hallo Johannes, hallo Leute,
Am Donnerstag, 23. Juni 2005 15:34 schrieb Johannes Kastl: [...]
RobinLinux:/Daten4/fuer_apt/archives # rpm -e --justdb Wie werd ich das Paket denn dann endgültig mal los? Paket wieder installieren und dann deinstallieren? So gins bei mir jetzt, aber wie ist der "offizielle" Weg?
Genau der. Nur wenn RPM Ahnung von einem Paket hat (was nach -e --justdb eben nicht mehr der Fall ist), kann es dieses Paket auch löschen. Das Löschen eines nichtexistenten Pakets wird schwierig ;-)
Dann bin ich ja beruhigt.
Alternative: Sichere vor dem rpm -e die Dateiliste des Pakets (rpm -ql paket > dateiliste) und lösche die Dateien anschließend von Hand. Viel Spaß dabei. *g*
Gute Idee. Und Spass werd ich sicher haben...
Gruß
Christian Boltz
OJ -- "To be is to do." - Camus "To do is to be. " - Sartre "Do be do be do." - Sinatra
Christian Boltz wrote:
Am Donnerstag, 23. Juni 2005 15:34 schrieb Johannes Kastl:
[ ... ] [ rpm -e --justdb ] Wie werd ich das Paket denn dann endgültig mal los? Paket wieder installieren und dann deinstallieren? So gins bei mir jetzt, aber wie ist der "offizielle" Weg?
Genau der. Nur wenn RPM Ahnung von einem Paket hat (was nach -e --justdb eben nicht mehr der Fall ist), kann es dieses Paket auch löschen.
Man muss das Paket nicht komplett neu installieren. Es reicht ein "rpm -i --justdb bla.rpm", um es wieder in die RPM-Datenbank einzutragen. Danach kann das Paket samt Dateien mit einem normalen "rpm -e bla" wieder entfernt werden. Die Option "--justdb" sollte man, Johannes, uebrigens nur in Ausnahmefaellen verwenden. Seitdem SuSE Kernelquellen in verschiedene Unterverzeichnisse packt, muesste es theoretisch auch auf anderem Wege gehen, mehrere Kernelquellen per RPM parallel zu installieren. Cheers, Th.
Am Samstag, 2. Juli 2005 12:06 schrieb Thomas Hertweck:
Seitdem SuSE Kernelquellen in verschiedene Unterverzeichnisse packt, muesste es theoretisch auch auf anderem Wege gehen, mehrere Kernelquellen per RPM parallel zu installieren.
ja funktioniert wunderbar, den alten Kernel aus der db entfernen und den neuen installieren, wenn man den Distributionskernel aber aktualisiert haben möchte, anschließend den Eigenbau aus der DB entfernen und wieder den Distrikernel eintragen. Gruß Andreas
Hallo Thomas, Thomas Hertweck schrieb:
Man muss das Paket nicht komplett neu installieren. Es reicht ein "rpm -i --justdb bla.rpm", um es wieder in die RPM-Datenbank einzutragen. Danach kann das Paket samt Dateien mit einem normalen
Interessant, man lernt nicht aus.
"rpm -e bla" wieder entfernt werden. Die Option "--justdb" sollte man, Johannes, uebrigens nur in Ausnahmefaellen verwenden. Seitdem SuSE
Wenn dann wäre es nur der Kernel, und da würde ich die Pakete aufheben, damit man das rückgängig machen kann.
Kernelquellen in verschiedene Unterverzeichnisse packt, muesste es theoretisch auch auf anderem Wege gehen, mehrere Kernelquellen per RPM parallel zu installieren.
Bin grad dabei per apt auf 9.2 upzudaten (zu updaten?) (upgedatet zu haben wolleten sind), und werd das dann mal probieren.
Cheers, Th.
Danke für die Hilfe, OJ -- "Ich werde jeden Tropfen Blut aus Deinem Körper melken." "Wie passend, Du kämpfst wie eine dumme Kuh." (Monkey Island)
Hallo, Am Mon, 04 Jul 2005, Johannes Kastl schrieb:
Bin grad dabei per apt auf 9.2 upzudaten (zu updaten?) (upgedatet zu haben wolleten sind),
"zu aktualisieren" -dn'*gnah*'h -- Give a man a fish and you feed him for a day; give him a freshly-charged Electric Eel and chances are he won't bother you for anything ever again. -- Tanuki
Am 04.07.2005 23:58 schrieb David Haller:
"zu aktualisieren"
Spielverderber ;-) OJ -- Der Mensch hat drei Wege, klug zu handeln. Erstens durch Nachdenken: Das ist der edelste. Zweitens durch Nachahmen: Das ist der leichteste. Drittens durch Erfahrung: Das ist der bitterste. (Konfuzius)
Hallo mal wieder, ich hatte heute das selbe Problem wieder, als ich ein apt dist-upgrade von 9.1 auf 9.2 machen wollte. Da kam wieder die selbe Fehlermeldung. Nun ist mir aufgefallen, dass da immer was von udev drin stand. Und in meiner aktuellen, jetzt funktionierenden 9.1 (ich hab das Image zurückgespielt) taucht in /var/log/boot.msg nix mit udev auf. Was kann man da machen? Wie schalte ich das udev aus, warum kommt das mit einem 9.1-Kernelupdate? Fragen über Fragen. OJ -- Kein Mensch kann ein reiner Spezialist sein, ohne im buchstäblichen Sinn ein Idiot zu sein. (George Bernard Shaw)
Hallo, Johannes Kastl <ojkastl@freenet.de> writes:
Hallo mal wieder, [...] Nun ist mir aufgefallen, dass da immer was von udev drin stand. Und in meiner aktuellen, jetzt funktionierenden 9.1 (ich hab das Image zurückgespielt) taucht in /var/log/boot.msg nix mit udev auf.
Was kann man da machen? Wie schalte ich das udev aus, warum kommt das mit einem 9.1-Kernelupdate?
Befrage doch mal dein System :-.) Ein 'apropos udev' wird dich erhellen. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6
Hallo, da hab ich mich wohl unklar ausgedrückt. Dieter Kluenter schrieb:
Befrage doch mal dein System :-.) Ein 'apropos udev' wird dich erhellen.
Udev ist auch vorher schon installiert, ob es benutzt wird weiss ich nicht, es taucht wie gesagt halt nicht auf während des Bootens. Warum taucht es dann mit dem neuen Kernel auf? OJ -- Insane people throw computers out of windows, sane people...
Johannes Kastl <ojkastl@freenet.de> writes:
Hallo,
da hab ich mich wohl unklar ausgedrückt.
Dieter Kluenter schrieb:
Befrage doch mal dein System :-.) Ein 'apropos udev' wird dich erhellen.
Udev ist auch vorher schon installiert, ob es benutzt wird weiss ich nicht, es taucht wie gesagt halt nicht auf während des Bootens.
Ob udev benutzt wird, hängt doch von dir und deinen Geräten ab. Üblicherweise wird udev über hotplug gesteuert.
Warum taucht es dann mit dem neuen Kernel auf?
weil möglicherweise jetzt udevd gestartet wird? -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6
Hallo, Dieter Kluenter schrieb:
Johannes Kastl <ojkastl@freenet.de> writes:
Ob udev benutzt wird, hängt doch von dir und deinen Geräten ab. Üblicherweise wird udev über hotplug gesteuert.
Da müssten sich doch aber beide Kernel gleich verhalten.
Warum taucht es dann mit dem neuen Kernel auf?
weil möglicherweise jetzt udevd gestartet wird?
Wenn ich den neuen Kernel starte, hängt sich das System auf. Wenn ich den alten starte, gehts. Wieso würde hotplug nur bei einem von beiden auftauchen?
-Dieter
OJ -- "Bei einer Geschichte gibt es immer vier Seiten: Deine Seite, ihre Seite, die Wahrheit und das, was wirklich passiert ist." (Rousseau)
Hallo, Johannes Kastl <ojkastl@freenet.de> writes:
Hallo,
Dieter Kluenter schrieb:
Johannes Kastl <ojkastl@freenet.de> writes:
Ob udev benutzt wird, hängt doch von dir und deinen Geräten ab. Üblicherweise wird udev über hotplug gesteuert.
Da müssten sich doch aber beide Kernel gleich verhalten.
Warum taucht es dann mit dem neuen Kernel auf?
weil möglicherweise jetzt udevd gestartet wird?
Wenn ich den neuen Kernel starte, hängt sich das System auf. Wenn ich den alten starte, gehts. Wieso würde hotplug nur bei einem von beiden auftauchen?
Ich sitze nicht vor deiner Kiste und weiss nicht was du installiert hast. Du must also schon selbst herausfinden, was sich an deinem System verändert hat. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6
Am 06.07.2005 11:11 schrieb Dieter Kluenter:
Ich sitze nicht vor deiner Kiste und weiss nicht was du installiert hast. Du must also schon selbst herausfinden, was sich an deinem System verändert hat.
Das wüsste ich auch gerne. Ich hab meines Wissens nämlich nix verändert, was solche Probleme auslösen sollte. Die rpm-Datenbank ist konsistent, es sind keine bleeding-edge-Pakete installiert. Nur zwei Kernel, nämlich der von der Suse 9.1 DVD, und der YOU-Update Kernel. Boote ich den DVD-Kernel geht das System, boote ich den YOU-Kernel, geht nix. Dann bleibt er hängen. Das einzige was mir einfällt was irgendwie mit udev zu tun haben könnte, ist das Ausschalten von subfs, dass ich aber seit dem Installieren ausgeschaltet hab. http://portal.suse.com/sdb/de/2004/05/hmeyer_91_revert_from_subfs.html Was micht stutzig macht ist dass es mit einem Kernel geht, und mit einem andern nicht. Obwohl beide für 9.1 sind. Wenn ich versucht hätte einen von der 9.3 zu installieren, OK. Aber so? OJ -- "Oh, you may not think I'm pretty, But don't judge on what you see, I'll eat myself if you can find A smarter hat than me." (The Sorting Hat in Harry Potter I)
Am Mittwoch, 6. Juli 2005 19:50 schrieb Johannes Kastl:
Am 06.07.2005 11:11 schrieb Dieter Kluenter:
Ich sitze nicht vor deiner Kiste und weiss nicht was du installiert hast. Du must also schon selbst herausfinden, was sich an deinem System verändert hat.
Das wüsste ich auch gerne. Ich hab meines Wissens nämlich nix verändert, was solche Probleme auslösen sollte. Die rpm-Datenbank ist konsistent, es sind keine bleeding-edge-Pakete installiert.
Nur zwei Kernel, nämlich der von der Suse 9.1 DVD, und der YOU-Update Kernel.
Boote ich den DVD-Kernel geht das System, boote ich den YOU-Kernel, geht nix. Dann bleibt er hängen.
Das einzige was mir einfällt was irgendwie mit udev zu tun haben könnte, ist das Ausschalten von subfs, dass ich aber seit dem Installieren ausgeschaltet hab. http://portal.suse.com/sdb/de/2004/05/hmeyer_91_revert_from_subfs.html
Was micht stutzig macht ist dass es mit einem Kernel geht, und mit einem andern nicht. Obwohl beide für 9.1 sind. Wenn ich versucht hätte einen von der 9.3 zu installieren, OK. Aber so?
OJ bei meiner 9.2 hatte ich Probleme mit den neuen 2.6 Kerneln alles was nach 2.6.8xxx kam ging erst nicht. erst mkinitrd 1.2 mit der glib option -g hat mir ne initrd gebastelt, mit der der Kernel bootete.
tschüss didi
Johannes Kastl wrote:
ich hatte heute das selbe Problem wieder, als ich ein apt dist-upgrade von 9.1 auf 9.2 machen wollte. Da kam wieder die selbe Fehlermeldung.
Nun ist mir aufgefallen, dass da immer was von udev drin stand. Und in meiner aktuellen, jetzt funktionierenden 9.1 (ich hab das Image zurückgespielt) taucht in /var/log/boot.msg nix mit udev auf.
Was kann man da machen? Wie schalte ich das udev aus, warum kommt das mit einem 9.1-Kernelupdate?
udev ist Teil eines Mechanismus, mit dem Device-Knoten dynamisch on the fly kreiert und entfernt werden, wenn der Linux Kernel ein neues Device registriert oder ein Device nicht laenger benoetigt wird. Soweit zum Hintergrund. Das macht in meinen Augen absolut Sinn fuer Geraete, die wirklich dynamisch sind, wie z.B. USB-Geraete o.ae. - letztendlich will man ja nicht, dass ein Device, das dem USB-Drucker zugewiesen wird, irgendwie von der Reihenfolge abhaengt, wie ich meine USB-Geraete anstoepsel, sondern der Drucker soll immer das gleiche Device haben, egal wann ich ihn aktiviere. So etwas laesst sich ueber den im Hintergrund verborgenen Mechanismus, zu dem auch udev zaehlt, bewerkstelligen. SuSE verwendet allerdings dieses System auch z.B. fuer die Root-Partition, was mir bisher keiner logisch begruenden konnte. Ich sehe hier keinen Vorteil, weil das Device fuer die Root-Partition ja stets beim Booten erstellt werden muss und immer gleich ist (man aendert ja nicht staendig seine Root-Partition). Warum kann man hierfuer also nicht wie bisher einen statischen Device-Knoten nehmen? Hmm. Dein Problem deutet jedenfalls darauf hin, dass etwas mit Deiner initrd nicht stimmt, denn dort muss der o.a. Mechanismus quasi enthalten sein, sonst kann es nicht funktionieren, und dann fehlt eben das Device fuer die Root-Partition beim Booten und fuehrt zur bekannten Fehlermeldung "waiting for device [...] to appear" oder so aehnlich *sic*. Du solltest also ueberpruefen, dass Du auch das neuste mkinitrd Paket hast (evtl. gibt es da ein Update, das fuer den neuen Kernel noetig ist), oder aber Du solltest die initrd mal selbst von Hand erstellen und schauen, dass sie auch korrekt ist. Cheers, Thomson
Hallo Thomas, Thomas Hertweck schrieb:
Johannes Kastl wrote: nehmen? Hmm. Dein Problem deutet jedenfalls darauf hin, dass etwas mit Deiner initrd nicht stimmt, denn dort muss der o.a. Mechanismus quasi enthalten sein, sonst kann es nicht funktionieren, und dann fehlt eben das Device fuer die Root-Partition beim Booten und fuehrt zur bekannten Fehlermeldung "waiting for device [...] to appear" oder so aehnlich *sic*. Du solltest also ueberpruefen, dass Du auch das neuste mkinitrd Paket hast (evtl. gibt es da ein Update, das fuer den neuen Kernel noetig ist), oder aber Du solltest die initrd mal selbst von Hand erstellen und schauen, dass sie auch korrekt ist.
auf die Idee bin ich auch mal gekommen. Und hab bei der Ausgabe von mkinitrd folgendes entdeckt: Zuerst die initrd für den DVD-Kernel:
RobinLinux:/boot # mkinitrd Root device: /dev/hda5 (mounted on / as ext3) Module list: jbd ext3
Kernel image: /boot/vmlinuz-2.6.4-52-default Initrd image: /boot/initrd-2.6.4-52-default Shared libs: lib/ld-2.3.3.so lib/libblkid.so.1.0 lib/libcom_err.so.2.1 lib/libc.so.6 lib/libext2fs.so.2.4 lib/libselinux.so.1 lib/libuuid.so.1.2 Usage: hwinfo [options] ... Driver modules: none Filesystem modules: kernel/fs/jbd/jbd.ko kernel/fs/ext3/ext3.ko Including: klibc initramfs udev fsck.ext3 Bootsplash: SuSE (1280x1024) 5361 blocks
Dann das für den neuen YOU-Kernel:
Kernel image: /boot/vmlinuz-2.6.5-7.155.29-default Initrd image: /boot/initrd-2.6.5-7.155.29-default Shared libs: lib/ld-2.3.3.so lib/libblkid.so.1.0 lib/libcom_err.so.2.1 lib/libc.so.6 lib/libext2fs.so.2.4 lib/libselinux.so.1 lib/libuuid.so.1.2 Usage: hwinfo [options]
die hwinfo Ausgabe kommt zweimal.
Driver modules: none Filesystem modules: lib/modules/2.6.4-52-default/kernel/fs/jbd/jbd.ko lib/modules/2.6.4-52-default/kernel/fs/ext3/ext3.ko kernel/fs/jbd/jbd.ko kernel/fs/ext3/ext3.ko
Hier verwendet der Kernel die falsche /lib/modules. Statt 2.6.5-7.155.29-default nimmt er hier das Verzeichnis des alten Kernels. Warum?
Including: klibc initramfs udev fsck.ext3 Bootsplash: SuSE (1280x1024) 5767 blocks
Sonst ist alles gleich geblieben. Warum verwendet der Kernel das flasche /lib/modules-Verzeichnis? OJ P.S. Kann man eigentlich die nicht zu den installierten Kernel gehörigen Verzeichnisse in /lib/modules und /usr/src/ löschen? -- "Wahre Worte sind nicht schön. Schöne Worte sind nicht wahr." (Lao-Tse)
Johannes Kastl wrote:
[...] Und hab bei der Ausgabe von mkinitrd folgendes entdeckt: Zuerst die initrd für den DVD-Kernel: [...] Dann das für den neuen YOU-Kernel:
Kernel image: /boot/vmlinuz-2.6.5-7.155.29-default Initrd image: /boot/initrd-2.6.5-7.155.29-default [...] Filesystem modules: lib/modules/2.6.4-52-default/kernel/fs/jbd/jbd.ko >>[...]
Aha, da kommen wir dem Problem doch schon naeher. Es werden also z.B. Module in die initrd gepackt, die nicht zum Kernel-Image passen. Wie hast Du im zweiten Falle mkinitrd aufgerufen? Du musstest ja sicher Optionen verwendet haben... "mkinitrd" ist IIRC einfach nur ein Skript. Du kannst also genau nachschauen, was es tut und sehen, wo die entsprechenden Daten ermittelt werden, die dann dazu fuehren, dass Module aus dem falschen Module-Verzeichnis genommen werden. Das sollte Dir zeigen, was hier schief laeuft.
P.S. Kann man eigentlich die nicht zu den installierten Kernel gehörigen Verzeichnisse in /lib/modules und /usr/src/ löschen?
Wenn Du unter /lib/modules Unterverzeichnisse hast, die zu keinem auf Deinem System mehr vorhandenen Kernel-Image passen, kannst Du im Prinzip das entsprechende Verzeichnis loeschen. Auch Kernel-Quellen unter /usr/src brauchst Du nur aufheben, wenn Du noch ein zugehoeriges Kernel-Image hast und verwendest oder wenn Du evtl. aus den Kernel-Quellen nochmal ein Image (sprich: einen eigenen Kernel) bauen willst. Falls Du Dir bei manchen Verzeichnissen nicht sicher bist, loesche sie besser nicht, sondern verschiebe sie erst einmal an eine sichere Stelle und schaue, ob Dein System nachwievor einwandfrei funktioniert. Falls nicht, musst Du das Verzeichnis wieder zurueck kopieren. Falls alles geht, kannst Du das erstellte Backup nach einiger Zeit wirklich loeschen. Falls Du Kernel immer nur via RPM installiert hast, sollten die Unterverzeichnisse bei Deinstallation der entsprechenden RPMs eigentlich geleert werden. Cheers, Th.
Hallo, ich kann weiter einschränken. Thomas Hertweck schrieb:
Johannes Kastl wrote:
Filesystem modules: lib/modules/2.6.4-52-default/kernel/fs/jbd/jbd.ko >>[...]
Aha, da kommen wir dem Problem doch schon naeher. Es werden also z.B. Module in die initrd gepackt, die nicht zum Kernel-Image passen. Wie
Und jetzt erst meckert er das auch beim Booten an. Die Fehlermeldung:
Loading /lib/modules/2.6.4-52-default/kernel/fs/... jbd: Disagree
trat vorher nicht auf. Da hatte ich wohl vorher eine andere initrd, die wohl nicht ich mit "mkinitrd" ohne Parameter erzeugt hatte, sondern wohl rpm beim installieren. Jetzt geht nämlich auch der DVD-Kernel nicht mehr.
hast Du im zweiten Falle mkinitrd aufgerufen? Du musstest ja sicher Optionen verwendet haben...
Da werd ich mal schauen, welche das waren.
"mkinitrd" ist IIRC einfach nur ein Skript. Du kannst also genau nachschauen, was es tut und sehen, wo die entsprechenden Daten ermittelt werden, die dann dazu fuehren, dass Module aus dem falschen Module-Verzeichnis genommen werden. Das sollte Dir zeigen, was hier schief laeuft.
Werd mal schnüffeln gehen...
P.S. Kann man eigentlich die nicht zu den installierten Kernel gehörigen Verzeichnisse in /lib/modules und /usr/src/ löschen?
Wenn Du unter /lib/modules Unterverzeichnisse hast, die zu keinem auf Deinem System mehr vorhandenen Kernel-Image passen, kannst Du im Prinzip das entsprechende Verzeichnis loeschen. Auch Kernel-Quellen unter /usr/src brauchst Du nur aufheben, wenn Du noch ein zugehoeriges Kernel-Image hast und verwendest oder wenn Du evtl. aus den Kernel-Quellen nochmal ein Image (sprich: einen eigenen Kernel) bauen willst. Falls Du Dir bei manchen Verzeichnissen nicht sicher bist, loesche sie besser nicht, sondern verschiebe sie erst einmal an eine sichere Stelle und schaue, ob Dein System nachwievor einwandfrei
Ich wäre eh so vorgegangen, dass ich erst mal alles verschiebe. Ich kann ja sorgenfrei basteln, da ich ein Image hab, das funktioniert.
funktioniert. Falls nicht, musst Du das Verzeichnis wieder zurueck kopieren. Falls alles geht, kannst Du das erstellte Backup nach einiger Zeit wirklich loeschen. Falls Du Kernel immer nur via RPM installiert hast, sollten die Unterverzeichnisse bei Deinstallation der entsprechenden RPMs eigentlich geleert werden.
sollten...
Cheers, Th.
OJ -- Ein Experte ist ein Mann, der hinterher genau sagen kann, warum seine Prognose nicht gestimmt hat. (Winston Spencer Churchill)
Hallo, Johannes Kastl schrieb:
Thomas Hertweck schrieb:
Johannes Kastl wrote: trat vorher nicht auf. Da hatte ich wohl vorher eine andere initrd, die wohl nicht ich mit "mkinitrd" ohne Parameter erzeugt hatte, sondern wohl rpm beim installieren. Jetzt geht nämlich auch der DVD-Kernel nicht mehr.
Also, wenn ich per Hand die initrd erzeuge, und dafür mkinitrd -R -u nehme, dann geht es. Auch mit dem neuen Kernel. Nur führt rpm beim Installieren nur "mkinitrd" aus, ohne Parameter. UNd dann geht es nicht. Was mich wundert: Ich hab alle Kernel bis auf den aktuellen YOU-Kernel mit YOU eingespielt, und nie per Hand mkinitrd aufgerufen. Und das ist immer gegangen. Nur der aktuelle YOU-Kernel wollte so nicht. Und jetzt muss ich auch den DVD-Kernel, wenn ich ihn installiere, per Hand die initrd erzeugen, sonst geht der auch nicht mehr. Warum funktioniert der Kernel jetzt nur, wenn man udev in der initrd ausschaltet, und auf initramfs (oder so) verzichtet. Woher könnte denn das kommen? Weil mich das etwas beunruhigt. Klar ich könnte in Zukunft immer mkinirtd -R -u ausführen, sobald ein YOU-Kernelupdate gemacht wurde. Aber das ist halt nur ein Aus-dem-Weg-gehen, kein Lösen. OJ -- Netzwerksicherheits-Legende Nr. 264: Firewalls schützen vor Viren, Trojanern, Kettenbriefen und Taubenscheiße auf dem Autodach. (Martin Schmitt, de.org.ccc, 30.5.1999)
Hallo, großes Aufatmen. Ich hab "den Fehler" gefunden. Der Fehler war eine zu neue mkinitrd-Version, die irgendwie ihren Weg auf meinen Rechner gefunden hat. Anscheinend mit einem apt upgrade, dass ich vor einigen Monaten mal gemacht hab. Da hab ich gar nicht mehr dran gedacht, da seitdem alles funktioniert hat, aber da war anscheinend ein Repository drin, dass zu "bleeding edge" ist. Naja, jetzt gehts wieder. Danke an alle für die Hilfe, und tschulligung für die Aufregung. OJ -- Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.
participants (9)
-
Andreas Loesch -
Christian Boltz -
David Haller -
Dieter Kluenter -
Dietrich Restemeyer -
Johannes Kastl -
Michael Schueller -
Thomas Hertweck -
Thomas Janssen