[solved] Komisches UUID Verhalten nach einem Mount?

[pangu]

Hi Leute,

ich verstehe gerade folgenden Zusammenhang nicht. Ich habe die Festplatte /dev/sda auf --> /dev/sdb geklont mit

Code: Alles auswählen

dd if=/dev/sda of=/dev/sdb bs=16K

danach sah das Filesystem der Partition sdb logischerweise genauso aus wie die von sda:

# blkid -o list
device fs_type label mount point UUID
---------------------------------------------------------------------------------------------------
/dev/sda1 ext4 dataHD_MAIN /dataHD 40ccfa08-7938-460b-907e-a140f72f9014
/dev/sdb1 ext4 dataHD_MAIN (not mounted) 40ccfa08-7938-460b-907e-a140f72f9014

Dann habe ich der ersten Partition der frisch geklonten sdb einen eindeutigen Label und UUID verpasst, mit dem Befehl )

Code: Alles auswählen

tune2fs -L dataHD_MIRROR /dev/disk/by-id/ata-WDC_WD20EFRX-68AX9N0_WD-WMC301500768-part1 -U bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb

(ich nutze die eindeutige ID, welche auch die Seriennummer der Platte enthält, statt /dev/sdb zu nutzen. Damit umgehe ich die Gefahr, dass sda und sdb vertauscht sein könnten nach einem reboot. Durch diese by-id Wahl bin ich auf Nummer sicher)

Jetzt siehts so aus:

# blkid -o list
device fs_type label mount point UUID
---------------------------------------------------------------------------------------------------
/dev/sda1 ext4 dataHD_MAIN /dataHD 40ccfa08-7938-460b-907e-a140f72f9014
/dev/sdb1 ext4 dataHD_MIRROR (not mounted) bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb

Also bis hier soweit alles in Ordnung und verständlich. Jetzt mounte ich diese geklonte Partition auf ein Verzeichnis mit:

Code: Alles auswählen

# mount /dev/disk/by-id/ata-WDC_WD20EFRX-68AX9N0_WD-WMC301500768-part1 /mirrorHD

Und nun hat die erste Partition von sdb nach diesem Mountbefehl, wieder exakt dieselben Werte wie die von sda ???

# blkid -o list
device fs_type label mount point UUID
---------------------------------------------------------------------------------------------------
/dev/sda1 ext4 dataHD_MAIN /dataHD 40ccfa08-7938-460b-907e-a140f72f9014
/dev/sdb1 ext4 dataHD_MAIN /mirrorHD 40ccfa08-7938-460b-907e-a140f72f9014

Selbst wenn ich diese Platte wieder unmounte, bleiben diese Filesystem-Attribute immer noch so:

Code: Alles auswählen

# umount /mirrorHD

# blkid -o list
device fs_type label mount point UUID
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
/dev/sda1 ext4 dataHD_MAIN /dataHD 40ccfa08-7938-460b-907e-a140f72f9014
/dev/sdb1 ext4 dataHD_MAIN (not mounted) 40ccfa08-7938-460b-907e-a140f72f9014

Und wenn ich wieder versuchen würde mit exakt demselben Mountbefehl die Partition der sdb zu mounten, erhalte ich diese Fehlermeldung:

Code: Alles auswählen

# mount /dev/disk/by-id/ata-WDC_WD20EFRX-68AX9N0_WD-WMC301500768-part1 /mirrorHD
mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

Ich kann mir das nicht erklären?? Ich vermute jedoch stark, dass es mit den /dev/disk/by-id Bezeichnern zusammenhängen könnte und ich da 'nen Denkfehler habe? Diese sehen wie folgt aus:

Code: Alles auswählen

# ls -l /dev/disk/by-id/

insgesamt 0
lrwxrwxrwx 1 root root  9 Okt  2 14:09 ata-TSSTcorp_CDDVDW_TS-H653F -> ../../sr0
lrwxrwxrwx 1 root root  9 Okt  2 14:09 ata-WDC_WD20EFRX-68AX9N0_WD-WMC301466406 -> ../../sda
lrwxrwxrwx 1 root root 10 Okt  2 14:09 ata-WDC_WD20EFRX-68AX9N0_WD-WMC301466406-part1 -> ../../sda1
lrwxrwxrwx 1 root root  9 Nov 11 16:24 ata-WDC_WD20EFRX-68AX9N0_WD-WMC301500768 -> ../../sdb
lrwxrwxrwx 1 root root 10 Nov 12 10:49 ata-WDC_WD20EFRX-68AX9N0_WD-WMC301500768-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Okt  2 14:09 dm-name-r7dt3ld001-home -> ../../dm-5
lrwxrwxrwx 1 root root 10 Okt  2 14:09 dm-name-r7dt3ld001-root -> ../../dm-0
lrwxrwxrwx 1 root root 10 Okt  2 14:09 dm-name-r7dt3ld001-swap_1 -> ../../dm-1
lrwxrwxrwx 1 root root 10 Okt  2 14:09 dm-name-r7dt3ld001-tmp -> ../../dm-4
lrwxrwxrwx 1 root root 10 Okt  2 14:09 dm-name-r7dt3ld001-usr -> ../../dm-2
lrwxrwxrwx 1 root root 10 Okt  2 14:09 dm-name-r7dt3ld001-var -> ../../dm-3
lrwxrwxrwx 1 root root 10 Okt  2 14:09 dm-uuid-LVM-bvzqirkDCV8UOQ3DNIkmwItjKhYff0XtK59iogWCyxttkNn6fpZX4zeeyGvzwo3e -> ../../dm-5
lrwxrwxrwx 1 root root 10 Okt  2 14:09 dm-uuid-LVM-bvzqirkDCV8UOQ3DNIkmwItjKhYff0XtNk3K4oMEIGgypeoXk2zmG6JUSQlur2Tp -> ../../dm-3
lrwxrwxrwx 1 root root 10 Okt  2 14:09 dm-uuid-LVM-bvzqirkDCV8UOQ3DNIkmwItjKhYff0XtOqZ9Gmz4LKhs8qXfwx42jjeZToEtCsFo -> ../../dm-0
lrwxrwxrwx 1 root root 10 Okt  2 14:09 dm-uuid-LVM-bvzqirkDCV8UOQ3DNIkmwItjKhYff0XtpWeWls0Rsym1BdSv2SEUpt0Bbh1d6fVa -> ../../dm-1
lrwxrwxrwx 1 root root 10 Okt  2 14:09 dm-uuid-LVM-bvzqirkDCV8UOQ3DNIkmwItjKhYff0Xtw40Pqmy7YNB2vKua1mxb2UprZVg6jO4e -> ../../dm-4
lrwxrwxrwx 1 root root 10 Okt  2 14:09 dm-uuid-LVM-bvzqirkDCV8UOQ3DNIkmwItjKhYff0XtXz9z2eMTNfxhyJBiJqBrJrn00oI0Vkip -> ../../dm-2
lrwxrwxrwx 1 root root  9 Okt  2 14:09 scsi-3600508e000000000f86ad79392ff850c -> ../../sdc
lrwxrwxrwx 1 root root 10 Okt  2 14:09 scsi-3600508e000000000f86ad79392ff850c-part1 -> ../../sdc1
lrwxrwxrwx 1 root root 10 Okt  2 14:09 scsi-3600508e000000000f86ad79392ff850c-part2 -> ../../sdc2
lrwxrwxrwx 1 root root 10 Okt  2 14:09 scsi-3600508e000000000f86ad79392ff850c-part5 -> ../../sdc5
lrwxrwxrwx 1 root root  9 Okt  2 14:09 scsi-SATA_WDC_WD20EFRX-68_WD-WMC301466406 -> ../../sda
lrwxrwxrwx 1 root root 10 Okt  2 14:09 scsi-SATA_WDC_WD20EFRX-68_WD-WMC301466406-part1 -> ../../sda1
lrwxrwxrwx 1 root root  9 Nov 11 16:24 scsi-SATA_WDC_WD20EFRX-68_WD-WMC301500768 -> ../../sdb
lrwxrwxrwx 1 root root 10 Nov 12 10:49 scsi-SATA_WDC_WD20EFRX-68_WD-WMC301500768-part1 -> ../../sdb1
lrwxrwxrwx 1 root root  9 Okt  2 14:09 wwn-0x50014ee058e13b27 -> ../../sda
lrwxrwxrwx 1 root root 10 Okt  2 14:09 wwn-0x50014ee058e13b27-part1 -> ../../sda1
lrwxrwxrwx 1 root root  9 Nov 11 16:24 wwn-0x50014ee0ae36dd57 -> ../../sdb
lrwxrwxrwx 1 root root 10 Nov 12 10:49 wwn-0x50014ee0ae36dd57-part1 -> ../../sdb1
lrwxrwxrwx 1 root root  9 Okt  2 14:09 wwn-0x600508e000000000f86ad79392ff850c -> ../../sdc
lrwxrwxrwx 1 root root 10 Okt  2 14:09 wwn-0x600508e000000000f86ad79392ff850c-part1 -> ../../sdc1
lrwxrwxrwx 1 root root 10 Okt  2 14:09 wwn-0x600508e000000000f86ad79392ff850c-part2 -> ../../sdc2
lrwxrwxrwx 1 root root 10 Okt  2 14:09 wwn-0x600508e000000000f86ad79392ff850c-part5 -> ../../sdc5
 

Bitte um Aufklärung und Hilfestellung. Danke!

[Natureshadow]

Moin,

was sagt denn dmesg beim mounten?

Und wo kommt die UUID her, die du setzt? Wenn das tatsächlich dieser String aus Bs ist, stelle ich mir vor, dass beim mounten die alte UUID aus einer Kopie des Superblocks wiederhergestellt wird, da das keine gültige UUID ist. In einer gültigen UUID muss der dritte Block mit 1-5 beginnen und der vierte Block mit 8-b. Die erste Bedingunge davon erfüllt deine UUID da nicht.

-nik

[pangu]

nik, das könnte sein. Ich dachte ich könnte als UUID irgendwas nutzen, solange die Syntax stimmt. Also habe ich mich einfach für b's entschieden gehabt. Ich könnte auch random UUID generieren, das wollte ich aber vermeiden, weil ich was fixes wollte dass ich in meinem Skript als "Extrasicherheit" zur Prüfung abfragen kann.

Wäre z.B. die UUID hier gültig?

Code: Alles auswählen

bbbbbbbb-bbbb-1234-890a-bbbbbbbbbbbb

[Natureshadow]

Moin,

das sieht gültig aus. Probiere es mal damit; wenn es das Problem löst ist es gut, wenn nicht, sehen wir weiter !

Der Sinn einer UUID ist es aber, eindeutig zu sein, und deshalb finde ich das da nicht so schick . Aber wenn se meinen ...

-nik

[pangu]

Schade, an der UUID lag's also nicht. Problem besteht immer noch

Hatte die hier genutzt --> bbbbbbbb-bbbb-1234-890a-bbbbbbbbbbbb

[Natureshadow]

Du hast bisher die Frage ignoriert, was dmesg beim mounten / unmounten sagt.

-nik

[Apfelmann]

Hallo

ls -l /dev/disk/by-uuid

ist zum feststellen / auslesen der uuid

LG

[pangu]

Du hast bisher die Frage ignoriert, was dmesg beim mounten / unmounten sagt.

-nik

Nein, hatte sie bloß überlesen, sorry. Also es scheint tatsächlich irgendein Problem zu geben, nachdem mein Klonvorgang fertig ist und versucht wird zu mounten. Hier einige Lines, die das vllt. aufzeigen?

System Events
=-=-=-=-=-=-=
Nov 14 02:33:14 meinhost kernel: [3677282.276143] EXT4-fs (sdb1): recovery complete
Nov 14 02:33:14 meinhost kernel: [3677282.384684] EXT4-fs error (device sdb1): ext4_mb_generate_buddy:739: group 11905, 11896 clusters in bitmap, 11913 in gd
Nov 14 02:33:14 meinhost kernel: [3677282.391983] JBD2: Spotted dirty metadata buffer (dev = sdb1, blocknr = 0). There's a risk of filesystem corruption in case of system crash.

System Events
=-=-=-=-=-=-=
Nov 14 06:22:23 r7dt3ld001 kernel: [3691031.310151] ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Nov 14 06:22:23 r7dt3ld001 kernel: [3691031.317410] ata2.00: hard resetting link
Nov 14 06:22:24 r7dt3ld001 kernel: [3691031.636044] ata2.01: hard resetting link
Nov 14 06:22:24 r7dt3ld001 kernel: [3691032.112105] ata2.00: SATA link down (SStatus 0 SControl 310)
Nov 14 06:22:24 r7dt3ld001 kernel: [3691032.112127] ata2.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Nov 14 06:22:24 r7dt3ld001 kernel: [3691032.136275] ata2.01: configured for UDMA/133

wenn ich nach dem Klonvorgang ein "e2fsck /dev/sdb1" ausführe, dann meckert er gleich auch Fehler an und will diese reparieren. Der ackert dann sehr viele Reparaturen durch, und wenn das filesystem gefixt wurde, kann ich problemlos mounten ohne irgendwelche Fehler oder besonderen Vorkommnisse. Anfangs dachte ich, dass der Klonvorgang irgendwie fehlschlägt, weil ich blocksize=16K verwendete, obwohl ich mir das nicht vorstellen konnte. Also hab ich auch einfach mal ein "dd if=/dev/sda of=/dev/sdb" probiert, aber das brachte keinen Unterschied. Nach dem Klonvorgang ist /dev/sdb1 mit Fehlern behaftet, warum auch immer. Liegt das daran, weil /dev/sda1 gemountet ist, während der Klonvorgang läuft???

[KBDCALLS]

Hallo

ls -l /dev/disk/by-uuid

ist zum feststellen / auslesen der uuid

LG

Kann man auch einfacher haben blkid

[KBDCALLS]

Was heißt denn UUID ? Universally Unique Identifier Die ist normalerweise auch eindeutig. Was bei einer geklonten Partion ja logischerweise nicht der Fall ist. Also muß ich die neu setzen. Und beim Klonen sollte eine Partiton nicht in Benutzung sein.

[pangu]

KBDCALLS, wie bereits zuvor erwähnt und ausprobiert. Es liegt nicht an der UUID und unabhängig davon ob ich sie manuell gesetzt hatte oder nicht, war die UUID eindeutig. Das ist also kein UUID Problem wie ich auch anhand dem test festgestellt habe.

[cosmac]

hi,

KBDCALLS hat's schon gesagt: du kannst eine gemountete Partition nicht 1:1 clonen. Du bekommst damit ein defektes Dateisystem und das mag u.U. zu seltsamen Folgefehlern führen. (Ja, theoretisch ist es möglich, aber in deinem Fall ist es jedenfalls schief gegangen).

Andere (denkbare) Fehlerquellen:
- blkid hat einen Cache und zeigt u.U. einen alten Stand an, d.h. du siehst die Änderung durch tune2fs nicht.
- die Links unter /dev/disk/ sind noch unzuverlässiger, weil udev nicht mitbekommt, was durch dd und tune2fs geändert wurde.

[KBDCALLS]

blkid -g räumt den Cache von blkid auf.

[pangu]

hi cosmac,

das erstere vermute ich auch, deswegen ja auch meine Fragestellung, ob eine gemountete Partition einfach 1:1 geklont werden kann oder nicht. Dann wird's wohl daran liegen, denn die anderen Sachen schließe ich aus:

blkid liest nur aus dem cache file blkid.tab (liegt glaub in /etc) wenn es als non-root user ausgeführt wird. Wenn man als root angemeldet wird, dann wird die Platte direkt befragt. Bei SuSE liegt dieses cache file glaub in /dev/.blkid.tab. Die Links unter /dev/disk sind ja wieder was andres, ich habs ja auch mit den Bezeichnern /dev/sd? probiert gehabt.

Grüße,
Pangu

[smutbert]

Wenn du die gemountete Partition mit dd 1:1 kopierst, ist das Dateisystem iA in keinem konsistenten Zustand. Und selbst wenn das zufälig einmal doch nicht der Fall sein sollte, so ist das Dateisystem auf keinen Fall als sauber geunmountet markiert. Ich kann mir schon vorstellen, dass Linux dann beim Überprüfen des Journals auch gleich die UUID "mitrepariert".

Was passiert denn, wenn du nach einem sauberen Unmount ein weiteres Mal versuchst die UUID zu ändern?

Mir ist auch nicht klar, wieso du nicht einfach ein neues Dateisystem mit einer zufälligen oder auch der speziellen gewünschten UUID erstellst und dann die Dateien mit cp -a oder rsync hinüberkopierst, so kommst du auf Anhieb zu einem konsistenten Dateisystem und bei einem nicht vollem Dateisystem sollte es so auch schneller gehen.

[KBDCALLS]

Hier ein ähnliches Problem

[pangu]

Also, alles durchprobiert. Es liegt definitiv daran, daß die Quellplatte nicht gemountet sein darf. Wenn ich sie sauber unmounte, dann entstehen keine Fehler. Selbst dann nicht wenn ich bbbbbb...-bbbb-bbbb-bbbb-bbb..... als UUID verweden würde. Es lag also nicht an falschen UUIDs, sondern daran, dass meine Quellplatte gemountet war.

@nik: danke trotzdem für den Hinweis mit der besonderen Kennzeichnung für UUIDs (PS: haste mir da 'ne Quelle?)

@all: thanx!

[Natureshadow]

@nik: danke trotzdem für den Hinweis mit der besonderen Kennzeichnung für UUIDs (PS: haste mir da 'ne Quelle?)

Klar: RFC 4122, § 4.1.1

-nik

P.S.: Man sollte tune2fs mal so patchen, dass dein Problem an der ungültigen UUID liegt ...

[pangu]

Danke