[gelöst] Nach Kernelupdate bei Ubuntu Server 14.04: /lib/modules/<KERNELVERSION>/ fehlt!

User

Registrierungsdatum: 25.04.2006

24.06.2015, 13:05

Hallo Fredl,

danke inzwischen; interessante Analyse!

Es ist übrigens noch nicht ein ext4-Dateisystem. Aus historischen Gründen ist die Boot-Partition vom Typ ext2, die anderen Partitionen sind vom Typ ext3.

Ich such dann mal nach Infos...

LG
Werner

Zum Seitenanfang

Fredl

Ubuntu-Forum-Team

Beiträge: 11 331

24.06.2015, 14:39

ext3 ist sogar noch besser, da es eigentlich genügend Erfahrungen in alle möglichen Richtungen geben müsste.

Mich würden mal die aktiven Optionen das Filesystems interessieren:

	Quellcode
1	tune2fs -l /dev/sdaX

(X=Nummer der root-Partition)

Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.

me is all sausage
but don't call me Ferdl

Zum Seitenanfang

WernerS

User

Beiträge: 23

Registrierungsdatum: 25.04.2006

25.06.2015, 08:47

Aber gern, bitte sehr:

Quellcode

root@tux0:~# tune2fs -l /dev/sda8
tune2fs 1.42.9 (4-Feb-2014)
Filesystem volume name:   Root
Last mounted on:          /
Filesystem UUID:          c54766aa-5dff-44dc-b63b-17cc373be0eb
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              1220608
Block count:              4882432
Reserved block count:     244121
Free blocks:              4078639
Free inodes:              1070212
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1022
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Filesystem created:       Wed Jun 11 10:18:14 2014
Last mount time:          Wed Jun 24 11:03:14 2015
Last write time:          Wed Jun 24 11:03:14 2015
Mount count:              119
Maximum mount count:      -1
Last checked:             Wed Jun 18 11:18:31 2014
Check interval:           0 (<none>)
Lifetime writes:          64 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      0c13b6a6-3528-41e7-b8f1-1e54d764bda1
Journal backup:           inode blocks
root@tux0:~#

LG
Werner

Zum Seitenanfang

Fredl

Ubuntu-Forum-Team

Beiträge: 11 331

25.06.2015, 11:37

War die da gemountet oder nicht?

"needs_recovery" sollte nur im ungemounteten Zustand auftauchen. Wenn sie dabei gemountet ist, würde das schon auf ein Problem mit dem Journal hindeuten. Dann wäre fsck mit Option '-f' der nächste Test. Wenn Reparatur nötig wird, wäre eine zweite Platte hilfreich. Ein paar Hinweise dazu kannst Du leicht googeln.

Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.

me is all sausage
but don't call me Ferdl

Zum Seitenanfang

WernerS

User

Beiträge: 23

Registrierungsdatum: 25.04.2006

25.06.2015, 14:48

Hallo Fredl,

die obige Ausgabe erfolgte im gemounteten Zustand.
Im ungemouneten (Boot von "grml" über DVD) sind die Attribute:
has_journal ext_attr resize_inode dir_index filetype sparse_super large_file

Bei "fsck -v /dev/sda8" wird kein Fehler angezeigt; ebensowenig bei den anderen Partitionen.

Aber ich glaube, ich weiß jetzt wo das Problem liegt!

Ich hatte einmal vor einiger Zeit eine Kopie der "/"-Partition auf einer zweiten Partition angelegt. Obwohl ich in der fstab nicht über die UUID (die wäre, wie ich gesehen habe, bei beiden Partitionen gleich), sondern über die Device-Bezeichnung mounte, scheint manchmal die falsche Root-Partition angesprochen zu werden.
Hier sind in "/lib/modules" dann übrigens genau die Kernel-Versionen zu finden, die ich im Fehlerfall sehe...

Laut /etc/fstab sollte /dev/sda6 als "/" gemountet werden; im Moment ist allerdings (wenn /lib/modules/<KERNELVERZ> vorhanden ist) /dev/sda8 als "/" gemountet.
Da "/etc/ in der von "/"-Partition liegt, muss der Fehler schon früher in der Boot-Partition passieren.

Jetzt muss ich noch die Ursache dafür herausfinden.

LG
Werner

Zum Seitenanfang

Fredl

Ubuntu-Forum-Team

Beiträge: 11 331

25.06.2015, 15:20

Die schönsten Eier sind die, die man sich selber legt. :thumbsup:

Schau mal im Bootloader die kernel-Parameter durch. Falls Grub (wenn nicht aus "historischen Gründen" noch lilo

), dann gibt's da einige in Frage kommende Zeilen.
Am schnellsten kannst Du im laufenden System mit "cat /proc/cmdline" sehen, was dem gerade laufenden Kernel so alles mitgegeben wurde.

P.S. identische UUID ist immer problematisch und deshalb auch nur mit besonderer Absicht zu erreichen. Ich habe auch immer eine Kopie von /, aber ich vertraue auf LABELs, die entsprechend benannt werden.

Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.

me is all sausage
but don't call me Ferdl

Zum Seitenanfang

WernerS

User

Beiträge: 23

Registrierungsdatum: 25.04.2006

25.06.2015, 16:10

Hallo Fredl,

wieder einmal danke für die Tipps.

Sooo historisch ist der Rechner dann doch nicht, dass ich noch LILO verwenden würde, es ist schon Grub 2.

Es wurde wirklich vom Grub die UUID übergeben.

Ich habe jetzt /dev/sda8 auf /dev/sda6 kopiert, in /etc/default/grub die Zeile

	Quellcode
1	GRUB_DISABLE_LINUX_UUID=true

aktiviert und mit "update-grub" übernommen.

In der /etc/fstab steht weiterhin /dev/sda6 für das Mounten auf "/".

Nach dem Reboot habe ich jetzt noch überprüft, was in /proc/cmdline steht: die UUID-Übergabe ist wirklich verschwunden.

Allerdings wird immer noch /dev/sda8 gemountet!

Da bin ich also noch dran...

LG
Werner

Zum Seitenanfang

Fredl

Ubuntu-Forum-Team

Beiträge: 11 331

25.06.2015, 18:04

Unabhängig davon, wo das herkommt, hast Du ja zwei identische /-Partitionen rumliegen. Somit auch zwei /etc/fstab. Wenn aus irgend einem (noch zu suchenden Grund) der Kernel zuerst auf die falsche Partition gelangt, nimmt er auch die falsche fstab. Hast Du die auch abgeändert?

Wie dem auch sei. Ich würde die unbenutzte UUID mit tune2fs abändern (und die fstab und grub-conf auf LABEL statt dev oder UUID ummodeln)

.

Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.

me is all sausage
but don't call me Ferdl

Zum Seitenanfang

WernerS

User

Beiträge: 23

Registrierungsdatum: 25.04.2006

27.06.2015, 09:43

Hallo Fredl,

ich komme leider erst voraussichtlich am Montag dazu, deine letzten Vorschläge umzusetzen.
Hoffentlich bringe ich es damit hin, dass die richtige Root-Partition gemountet wird.

Eigentlich sollten in beiden Partitonen die /etc/fstabs passen.

Sobald ich das hingebracht habe, melde ich mich natürlich wieder.
Danke inzwischen!
Du hast noch ein PN von mir.

LG
Werner

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »WernerS« (27.06.2015, 10:30)

Zum Seitenanfang

WernerS

User

Beiträge: 23

Registrierungsdatum: 25.04.2006

29.06.2015, 14:54

Hallo,

vorläufig habe ich die Dinge wieder zum Laufen gebracht.

Ich habe die doppelten UUIDs geändert mittels "

	Quellcode
1	tune2fs -U random /dev/sda8

- (brachte allein noch keine Verbesserung), ebenso die Beseitigung der doppelten Labels mittels "e2labels".

Da nun immer noch die falsche Root-Partition eingehängt wurde, habe ich in /etc/grub/grub.cfg einiges umgebogen:

	Quellcode
1	set root='hd0,msdos8'

auf

	Quellcode
1	set root='hd0,msdos6'

Weiters in den "search"-Zeilen:

	Quellcode
1	... --fs-uuid ... <UUID>

umgeändert auf

	Quellcode
1	... --label ... "Root"

Anschließend habe ich noch (gefühlte hundert mal) geändert:

	Quellcode
1	root=UUID=<Nummer>

auf

	Quellcode
1	root=LABEL="Root"

Nach einem

	Quellcode
1	update-grub

scheint beim nächsten Reboot alles zu passen...

Also danke nochmals, Fredl, für deine Hilfe!

LG
Werner

Zum Seitenanfang

Fredl

Ubuntu-Forum-Team

Beiträge: 11 331

30.06.2015, 00:06

Gerne.

Aber wenn auf dem Rechner, was ich annehme, nur ein System läuft (ich meine Linux, mit maximal 1-2 Vorversionen als Fallback), wäre dann nicht entweder die Deaktivierung der ganzen Such-Automagie von Grub2 eine Option? Das ist für laufend erneuerte (Dualboot-)Systeme sicherlich Anwender/Einsteiger-freundlich. Leute, die sich gelegentlich die root-Partition klonen, zähle ich aber eher nicht zu den Einsteigern. Und wie man sieht, können gerade die sich mit den fortschrittlichen Features von Grub2 auch ordentlich ins Knie schießen

Ich würde bei so einem System eher zu Grub-Legacy tendieren, der bei sowas noch wesentlich transparenter zu manipulieren ist/war. Ich persönlich habe zumindest immer noch diesen im Einsatz. Eben weil ich bei dem Wildwuchs an Partitionen auf meiner Platte gerne selbst Herr der Lage sein möchte und auf die OS-Suche bei jedem Bootvorgang verzichten kann. Ich weiß ja schon vorher, was ich booten kann und will.

Aus ähnlichen Gründen habe ich übrigens auch noch gut drei Jahre an Lilo festgehalten, als Grub (der heutige Legacy) längst stabil war. Einen SOHO-Server kann man mit herkömmlichen Mitteln kaum schneller booten.

Wie dem auch sei: Freut mich, daß wir Dein Problemchen über einige Umwege isolieren konnten! :thumbup:

Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.

me is all sausage
but don't call me Ferdl

Zum Seitenanfang

WernerS

User

Beiträge: 23

Registrierungsdatum: 25.04.2006

30.06.2015, 20:08

Hallo Friedl,

du hast natürlich recht; ich habe auch den Eindruck, dass da einiges in der ganzen Grub-Konfiguration überflüssig bzw. etwas aufgeblasen ist.

Vielleicht versuch ich einmal (wie üblich bei solchen Dingen: "wenn ich einmal Zeit habe" :rolleyes:

), das ganze Spielchen zu vereinfachen; im Moment bin ich aber froh, dass es funktioniert.

Nach der Urlaubszeit kommt wieder ein anderer Rechner dran für eine Neuinstallation, vielleicht schaffe ich es da...

LG
Werner