mijori
Anmeldungsdatum: 20. Dezember 2006
Beiträge: 110
|
Hallo liebe Ubuntu-Fans, an dieser Stelle bitte ich um Hilfe bei einem Problem, das hier und in den englischsprachigen Foren "sehr nahe Verwandte" hat. - Allerdings, gab es stets kleine Abweichungen zu meinem und auch die angebotenen Lösungen, die dort teilweise Erfolg zu haben schienen, wollten bei mir nicht funktionieren. Nach dem Upgrade von Jaunty auf Karmic kam der große Schreck: Karmic behauptete einfach, dass meine Festplatte mit der UUID soundso nicht existiere und schickte mich in die BusyBox...
...Schön blöd, wenn das die Boot-Device ist, wie bei mir.
Also Live-CD rein, hochgefahren und - was soll ich sagen - sda1 (meine Boot-Device) wurde sofort erkannt, alles lesbar, keine Fehler beim fsCheck etc.
Allerdings blkid lieferte keine UUID für sda1. - Weder die, die von Jaunty her noch in menu.lst und fstab stehen, noch eine "neue"... - Es ließ sich auch mit tune2fs keine neue erstellen (zwar keine Fehlermeldungen, aber eben auch keine neue UUID!)... ...Klar, dass das mit dem Booten ohne "erkannte" UUID nicht klappen kann! - Also kommentierte ich die entsprechenden Zeilen in den zwei Dateien aus, kopierte sie, ersetzte die UUID durch /dev/sda1, aktivierte diese "neuen" Zeilen wieder und konnte nach einem Neustart (von der Festplatte) problemlos in Karmic einloggen. Dort kontrollierte ich /dev/disk/by-uuid/ und siehe da: UUID-Einträge für sda5 und sdb1, aber nicht für sda1...!!! Und genau hier wird's meiner Meinung nach kurios: Ich könnte es ja verstehen, wenn NUR ein Eintrag für sdb1 vorhanden wäre... - Aber einer für sda5 und KEINER für sda1 (also zwar zwei verschiedene Partitionen, aber eben EINE Festplatte)... - Muss man das verstehen (Entweder ich erkenne eine Festplatte oder eben nicht; aber ein "bißchen erkennen"...?)?! Zwar habe ich mir, was das Nutzen von Karmic angeht ja jetzt schon durch meinen kleinen Workaround geholfen. Dass das aber keine dauerhafte Lösung sein kann, versteht sich - denke ich zumindest - von selbst. Was meint Ihr? - Ist es mit dem Warten auf ein Kernel-Update getan oder gibt's für das Problem schon jetzt eine endgültige Lösung? Schon jetzt vielen Dank für Eure Hilfe! Nette Grüße Mijori.
|
primus_pilus
Ehemalige
Anmeldungsdatum: 8. Oktober 2007
Beiträge: 9144
Wohnort: NRW
|
mijori schrieb:
Allerdings blkid lieferte keine UUID für sda1. - Weder die, die von Jaunty her noch in menu.lst und fstab stehen, noch eine "neue"... - Es ließ sich auch mit tune2fs keine neue erstellen (zwar keine Fehlermeldungen, aber eben auch keine neue UUID!)...
Wie bist du genau vorgegangen um die neue UUID zuzuteilen? Neue UUID erstellen lassen:
uuidgen
UUID der Partition zuteilen:
sudo tune2fs -U xxxxxxxxUUIDxxxxx /dev/xxxy
Dann Neustart.
Und genau hier wird's meiner Meinung nach kurios: Ich könnte es ja verstehen, wenn NUR ein Eintrag für sdb1 vorhanden wäre... - Aber einer für sda5 und KEINER für sda1 (also zwar zwei verschiedene Partitionen, aber eben EINE Festplatte)... - Muss man das verstehen (Entweder ich erkenne eine Festplatte oder eben nicht; aber ein "bißchen erkennen"...?)?!
Die einzelnen Partitionen sind ja unabhängig voneinander auch wenn sie auf der gleichen physikalischen Platte liegen. Grüße Thomas
|
mijori
(Themenstarter)
Anmeldungsdatum: 20. Dezember 2006
Beiträge: 110
|
Hallo Thomas, primus pilus schrieb:
Wie bist du genau vorgegangen um die neue UUID zuzuteilen?
...Genau so, wie von Dir beschrieben. Zur Sicherheit hab ich "doppelgemoppelt" und's nach Deinem Beitrag einfach noch einmal gemacht. - Leider bleibt das Ergebnis das gleiche: der tune2fs-Befehl wird ohne Fehlermeldung angenommen, aber nach dem Neustart findet sich unter /dev/disk/by-uuid nach wie vor kein entsprechender Eintrag für meine sda1 (also eine Datei, deren Name dem Ergebnis des uuidgen-Befehls entspricht). Noch weitere Ideen? - Bitte, bitte...!!! 😉 Gruß Mijori.
|
primus_pilus
Ehemalige
Anmeldungsdatum: 8. Oktober 2007
Beiträge: 9144
Wohnort: NRW
|
Mache es nochmal wenn die Partition nicht eingehängt ist.
|
topaz
Anmeldungsdatum: 14. September 2009
Beiträge: 127
|
Hallo, wäre mal interessant zu wissen, ob dieses rätselhafte Verhalten auch im Zusammenhang mit 'Labeln' auftritt. tune2fs -L volumename /dev/sda1
oder
e2label /dev/sda1 neuer_label Anzeigen mit:
tune2fs -l /dev/sda1 Gruss Topaz
|
mijori
(Themenstarter)
Anmeldungsdatum: 20. Dezember 2006
Beiträge: 110
|
Hallo Thomas, primus pilus schrieb: Mache es nochmal wenn die Partition nicht eingehängt ist.
Ich habe beides probiert (eingehängt / ausgehängt)... - Das Problem bleibt... - Leider! Dir werden doch hoffentlich nicht die Ideen ausgehen... 😉 Nette Grüße Mijori.
|
primus_pilus
Ehemalige
Anmeldungsdatum: 8. Oktober 2007
Beiträge: 9144
Wohnort: NRW
|
mijori schrieb: Dir werden doch hoffentlich nicht die Ideen ausgehen... 😉
Wenn ich ehrlich bin schon langsam. Wie sieht es mit dem Label aus wie topaz schrieb?
|
mijori
(Themenstarter)
Anmeldungsdatum: 20. Dezember 2006
Beiträge: 110
|
Hallo Topaz, danke für Deinen Einwurf. - Ich denke, jede neue Idee hilft, das Problem erst einzukreisen und dann zu vernichten...!!! 😉
Oder frei nach Yoda: "Wenn das Problem lösen Du willst, verstehen Du es musst!" 😉 - Im Ernst: Meine Platte hatte ich zuvor noch nicht gelabelt und so habe ich's mit Deinem tune2fs-Befehl gleich einmal ausprobiert. Ergebnis: vorher Label=none, hinterher - wie von mir vergeben - Label=Ubuntu. Hat also geklappt. - Hier einfach 'mal das Ergebnis von tune2fs -l /dev/sda1: tune2fs 1.41.9 (22-Aug-2009)
Filesystem volume name: Ubuntu
Last mounted on: <not available>
Filesystem UUID: 21a9f03d-8426-4c99-b399-e12995d70b58
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal filetype needs_recovery sparse_super
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 985760
Block count: 1969962
Reserved block count: 98498
Free blocks: 406392
Free inodes: 733239
First block: 0
Block size: 4096
Fragment size: 4096
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16160
Inode blocks per group: 505
Last mount time: Mon Nov 30 12:50:09 2009
Last write time: Mon Nov 30 13:53:30 2009
Mount count: 10
Maximum mount count: 30
Last checked: Sat Nov 28 22:22:11 2009
Check interval: 0 (<none>)
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
First orphan inode: 504849
Journal backup: inode blocks Und da zeigt sich auch das wirklich Interessante an Deinem Tip: Das Labeln funktioniert UND - oh Wunder! - die UUID wird angezeigt...
...Der Witz: Der Rest des Systems schert sich einen Dreck um die "bekannte" UUID (blkid bzw. Eintrag unter /dev/disk/by-uuid)
Diese Widersprüchlichkeit ist es, die mich ganz kirre macht, so dass ich einfach nicht weiß, wo ich noch ansetzen soll. - Könnte es letzten Endes doch ein Kernel-Bug sein? Auf jeden Fall erst einmal vielen Dank bis hierher! - Sammeln wir weiter Ideen... 😉 Nette Grüße Mijori.
|
primus_pilus
Ehemalige
Anmeldungsdatum: 8. Oktober 2007
Beiträge: 9144
Wohnort: NRW
|
Mhm, führe mal
sudo blkid -g
aus. Dann nochmal:
sudo blkid
|
mijori
(Themenstarter)
Anmeldungsdatum: 20. Dezember 2006
Beiträge: 110
|
...Also, bei sudo blkid -g gibt's einfach keine Ausgabe (weder Fehler noch Info). Nur die neue Eingabeaufforderung. Dagegen bei sudo blkid kommt die Ausgabe /dev/sda5: UUID="xxxxxxxxxxxxxxxxxxxx" TYPE="swap"
/dev/sdb1: UUID="xxxxxxxxxxxxxxxxxxxx" TYPE="ntfs" Das ganze also unverändert... ...In Verbindung mit der Ausgabe bei tune2fs -l /dev/sda1 (s.o.) verstehe das, wer will... - Seufz...
|
topaz
Anmeldungsdatum: 14. September 2009
Beiträge: 127
|
Hallo Mijori, hatte ich fast vermutet - kann ich ja jetzt leicht sagen - dass Das Problem wohl weniger beim setzen sonder eher beim auslesen zuschlägt.
Habe vor kurzem schon einmal einen Ähnlich Fall betr. 'Label' Erkennung in Karmic: http://forum.ubuntuusers.de/topic/dmcrypt-blkid-keine-labels-mehr-unter-karmic/ .
Entspricht zwar nicht Deinem Problem, zeigt uns aber dass in der Richtung noch etwas 'buggy' ist. Manchmal hilft es weiter wenn man versucht ein Problem auf der untersten Ebene anzugehen um die diversen Fragen beim 'Henne-Ei' Problem zu beantworten. Habe mal bei meiner Platte /dev/sdc7 mit dem Label 'nativ-kubuntu' und der UUID 0eab48f1-8a96-4b99-b0b7-e23360898f4e einen Dump des massgeblichen Bereichs der Partition angefertigt: Prompt: # dd if=/dev/sdc7 skip=2 bs=512 count=1 | hd
1+0 Datensätze ein
1+0 Datensätze aus
512 Bytes (512 B) kopiert, 6,1468 s, 0,1 kB/s
00000000 a0 01 0a 00 8b 04 28 00 3a 00 02 00 a7 0d 1f 00 |......(.:.......|
00000010 12 91 08 00 00 00 00 00 02 00 00 00 02 00 00 00 |................|
00000020 00 80 00 00 00 80 00 00 a0 1f 00 00 f7 f9 07 4b |...............K|
00000030 b6 0d 04 4b 08 00 18 00 53 ef 01 00 01 00 00 00 |...K....S.......|
00000040 4e fe 03 4b 00 4e ed 00 00 00 00 00 01 00 00 00 |N..K.N..........|
00000050 00 00 00 00 0b 00 00 00 00 01 00 00 3c 00 00 00 |............<...|
00000060 42 02 00 00 7b 00 00 00 0e ab 48 f1 8a 96 4b 99 |B...{.....H...K.|
00000070 b0 b7 e2 33 60 89 8f 4e 6e 61 74 69 76 2d 6b 75 |...3`..Nnativ-ku|
00000080 62 75 6e 74 75 00 00 00 2f 00 88 9d 49 2d 01 88 |buntu.../...I-..|
00000090 ff ff e5 0d 83 88 00 00 00 00 38 9d 49 2d 01 88 |..........8.I-..|
000000a0 ff ff 00 1c 50 2d 01 88 ff ff 80 e7 4c 31 01 88 |....P-......L1..|
000000b0 ff ff c0 53 4a 2d 01 88 ff ff 70 dc 1a 81 ff ff |...SJ-....p.....|
000000c0 ff ff d8 9f 77 31 01 88 00 00 00 00 00 00 80 02 |....w1..........|
000000d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000e0 08 00 00 00 00 00 00 00 00 00 00 00 0b b5 32 fe |..............2.|
000000f0 b2 e8 48 df 95 be f4 ec 66 8a e6 48 01 01 00 00 |..H.....f..H....|
00000100 00 00 00 00 00 00 00 00 4e fe 03 4b 0a f3 02 00 |........N..K....|
00000110 04 00 00 00 00 00 00 00 00 00 00 00 ff 7f 00 00 |................|
00000120 00 80 10 00 ff 7f 00 00 01 00 00 00 ff ff 10 00 |................|
00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 |................|
00000150 00 00 00 00 00 00 00 00 00 00 00 00 1c 00 1c 00 |................|
00000160 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000170 00 00 00 00 04 00 00 00 72 8f 34 00 00 00 00 00 |........r.4.....|
00000180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200
Der Markierte Text zeigt: Offset 0x068: zeigt den UUID direkt in Hex an.
Offset 0x078: zeigt den Label an. Mann könnte also an dieser Stelle behaupten, dass beides richtig gesetzt wurde.
Wenn also bei Dir die gleichen Verhältnisse vorherschen, können wir sagen, dass beim Auslesen der UUID's Probleme auftreten. Vieleicht gibt's schon entsprechende Bug-Reports. Wenn ich Dich jedoch richtig verstanden habe, hat schon der GRUB (Grub-Legacy oder Grub2 ?) mit der UUID-Erkennung ein Problem ? . Vergleiche doch bitte einmal den Inhalt des Dumps von /dev/sda1 mit dem von /dev/sda5. Irgendwo muss da ja ein Unterschied erkennbar sein. PS.: Du hast geschieben: ...Also, bei sudo blkid -g gibt's einfach keine Ausgabe (weder Fehler noch Info). Nur die neue Eingabeaufforderung.
Da gibt's bei mir auch keine Ausgabe (sollte auch nicht 😀 ) -g = Garbage Collection only. Gruß Topaz
|
mijori
(Themenstarter)
Anmeldungsdatum: 20. Dezember 2006
Beiträge: 110
|
Hallo Topaz, UUID sda5: 8b82c834-e70e-4d48-b19b-08aa064486de (ohne Label) UUID sda1: 21a9f03d-8426-4c99-b399-e12995d70b58 dump sda5: dd if=/dev/sda5 skip=2 bs=512 count=1 | hd
1+0 Datensätze ein
1+0 Datensätze aus
512 Bytes (512 B) kopiert, 0,00015414 s, 3,3 MB/s
00000000 01 00 00 00 cc 68 01 00 00 00 00 00 8b 82 c8 34 |.....h.........4|
00000010 e7 0e 4d 48 b1 9b 08 aa 06 44 86 de 00 00 00 00 |..MH.....D......|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200 dump sda1: dd if=/dev/sda1 skip=2 bs=512 count=1 | hd
1+0 Datensätze ein
1+0 Datensätze aus
512 Bytes (512 B) kopiert, 0,00017286 s, 3,0 MB/s
00000000 a0 0a 0f 00 2a 0f 1e 00 c2 80 01 00 5b 1c 08 00 |....*.......[...|
00000010 0e 34 0b 00 00 00 00 00 02 00 00 00 02 00 00 00 |.4..............|
00000020 00 80 00 00 00 80 00 00 20 3f 00 00 44 20 15 4b |........ ?..D .K|
00000030 4a c0 13 4b 0b 00 1e 00 53 ef 01 00 01 00 00 00 |J..K....S.......|
00000040 83 94 11 4b 00 00 00 00 00 00 00 00 01 00 00 00 |...K............|
00000050 00 00 00 00 0b 00 00 00 80 00 00 00 04 00 00 00 |................|
00000060 06 00 00 00 01 00 00 00 21 a9 f0 3d 84 26 4c 99 |........!..=.&L.|
00000070 b3 99 e1 29 95 d7 0b 58 55 62 75 6e 74 75 00 00 |...)...XUbuntu..|
00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000000e0 08 00 00 00 00 00 00 00 11 b4 07 00 00 00 00 00 |................|
000000f0 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 |................|
00000100 00 00 00 00 00 00 00 00 00 00 00 00 0a 02 00 00 |................|
00000110 0b 02 00 00 0c 02 00 00 0d 02 00 00 0e 02 00 00 |................|
00000120 0f 02 00 00 10 02 00 00 11 02 00 00 12 02 00 00 |................|
00000130 13 02 00 00 14 02 00 00 15 02 00 00 16 02 00 00 |................|
00000140 17 06 00 00 00 00 00 00 00 00 00 00 00 00 00 08 |................|
00000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000160 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200 Scheint zu passen, oder? Und jetzt? - Viele Ebenen tiefer geht's ja nicht mehr... 😉 Ach ja, übrigens: Klar wollte ich zwar auf Grub2 und ext4 upgraden, aber aktuell ist noch Grub-Legacy und ext3 installiert... - Ich denke, es wäre nicht sonderlich clever da dran zu gehen, bevor nicht das aktuelle Problem sauber gelöst ist, nicht wahr? Ich bin 'mal gespannt, ob wir das noch gebastelt bekommen, bevor ein Kernel-Update kommt und sich das Ganze "wie von selbst" erledigt... Nette Grüße Mijori.
|
primus_pilus
Ehemalige
Anmeldungsdatum: 8. Oktober 2007
Beiträge: 9144
Wohnort: NRW
|
mijori schrieb: Und jetzt? - Viele Ebenen tiefer geht's ja nicht mehr... 😉
Hehe, ihr kennt ja bald alle Bits persönlich ... 😀 Ich weiß es ist keine elegante Lösung und so zu sagen Feigheit vor dem Feind, aber vielleicht legt ihr die Partition einfach neu an? Wenn die P. nicht all zu voll ist könnte das ja ein Ausweg sein.
|
topaz
Anmeldungsdatum: 14. September 2009
Beiträge: 127
|
Hallo,
Scheint zu passen, oder?
Ne, die UUID von sda5 liegt auf Offset 0x000c (falsch) und die von sda1 auf 0x0068 (Richtig).
Erklärt jedoch nicht, warum die Probleme mit sda1 statt mit sda5 auftreten.
Ach ja, übrigens: Klar wollte ich zwar auf Grub2 und ext4 upgraden, aber aktuell ist noch Grub-Legacy und ext3 installiert... - Ich denke, es wäre nicht sonderlich clever da dran zu gehen, bevor nicht das aktuelle Problem sauber gelöst ist, nicht wahr?
Betr. Upgrade auf Grub2 hast Du gut daran getan bei Legacy zu bleiben. Ext4 scheint gut zu laufen. Würde auch meinen, dass der Vorschlag von primus pilus Dich am schnellsten weiterbringt. Grundsätzlich sollte die UUID Erkennung speziel bei Grub-Lecacy gut funktionieren. Bei Deiner SDA1 Partition könnte irgendetwas beim Update auf 9.10 passiert sein. Wenn man die zahlreichen Threads zu GRUB2 liest, kann man leicht zu der Meinung kommen dass eine kleine Wartezeit von ca. 6 Monaten bis zum 'produktiven' Einsatz von GRUB2 sinnvoll wäre. Habe basierend auf meinen bisherigen Erfahrungen beim Einsatz von mehreren Systemen (Sidux, Debian, GRML und Kubuntu) auf einem System, eine eigene 'Boot-Partition' eingerichtet. Auf dieser Partition befinden sich die jeweiligen verschiedenen Kernel + Initrd's sowie Grub-Legacy mit einer 'händisch gepflegten menu.lst. Die 'Boot-Partition' wird in den jeweiligen Systemen als /boot gemountet. Diese Partition hat sch mehrere Betriebssystem-Wechsel 'überlebt'. D.h. Jeder Kernel/Grub hat bislang die UUID's der Partitionen erkannt. Deshalb liegt die Vermutung nahe, dass Deine Partition irgendwie einen 'Schuss' hat. Vieleicht wärst Du bei dieser Gelegenheit gut beraten, Dein '/boot' auf eine eigene (200 Mb sind wohl genug) Partition auszulagern. So ist eine Sicherung und ein Betriebssystem Wechsel/Upgrade einfacher. Gruß Topaz PS: Sehe gerade (Asche auf mein Haupt), dass sda5 eine Swap-Partition ist. Da liegt die UUID wohl an einer anderen Stelle !
|
mijori
(Themenstarter)
Anmeldungsdatum: 20. Dezember 2006
Beiträge: 110
|
Hallo Freunde... 😉 Also, ich hab' Eueren Rat angenommen, und habe die Partition neu angelegt... ...und was soll ich sagen: sda1 hat eine neue UUID, die auch von blkid ausgeworfen wird... 👍 ...im Live-Modus... 🙄 ...Denn beim normalen Booten gibt's jetzt ein anderes Problem. - Alles läuft normal, bis: Begin: Starting AppArmor profiles ...
mount: only root can do that
Failure: AppArmor profiles failed to load
Done.
Mount of root filesystem failed.
A maintenance shell will now be started.
CONTROL-D will terminate this shell and reboot the system.
Give root password for maintenance
(or type Control-D to continue): Allerliebst! 😠 Nun ja, aber immerhin ein Stückchen weiter... 😉 Bekommen wir den Rest auch noch hin? - Ich wär' Euch sehr dankbar! Nette Grüße Mijori.
|