Geisterpartition

[Richard Fonfara]

Debian Bookworm aktueller Stand.

Ich habe eben Backup gemacht und bekam zuerst gemeldet, ich hätte keine
Rechte auf das Verzeichnis. Mir fiel auf, dass ich einen Pfad ausgewählt
hatte, der *sdb* enthielt anstatt *sdd*. Wenn ich aber mit *lsblk* mir
die Laufwerke/Partitionen ansehe, ist da kein *sdb* enthalten. Es gibt
nur sda, sdc und die diversen NVMe-Partitionen.

Wie ist sowas möglich?

Nach Korrektur des Pfads auf *sdd* funktionierte das Backup.

[Marco Moock]

Post by Richard Fonfara
Ich habe eben Backup gemacht und bekam zuerst gemeldet, ich hätte
keine Rechte auf das Verzeichnis. Mir fiel auf, dass ich einen Pfad
ausgewählt hatte, der *sdb* enthielt anstatt *sdd*.

Wie machst du deine Backups?
Normalerweise ist da die Gerätedatei egal, weil man das Backup in einen
Pfad schreibt und sich das Dateisystemgeraffels um die Gerätedatei
kümmert.

[Richard Fonfara]

Post by Marco Moock

Post by Richard Fonfara
Ich habe eben Backup gemacht und bekam zuerst gemeldet, ich hätte
keine Rechte auf das Verzeichnis. Mir fiel auf, dass ich einen Pfad
ausgewählt hatte, der *sdb* enthielt anstatt *sdd*.

Wie machst du deine Backups?
Normalerweise ist da die Gerätedatei egal, weil man das Backup in einen
Pfad schreibt und sich das Dateisystemgeraffels um die Gerätedatei
kümmert.

Ich mache meine Backups auf externe Platten mit Back in Time.

[Gregor Szaktilla]

Post by Richard Fonfara

Post by Marco Moock

Post by Richard Fonfara
Ich habe eben Backup gemacht und bekam zuerst gemeldet, ich hätte
keine Rechte auf das Verzeichnis. Mir fiel auf, dass ich einen Pfad
ausgewählt hatte, der *sdb* enthielt anstatt *sdd*.

Wie machst du deine Backups?
Normalerweise ist da die Gerätedatei egal, weil man das Backup in einen
Pfad schreibt und sich das Dateisystemgeraffels um die Gerätedatei
kümmert.

Ich mache meine Backups auf externe Platten mit Back in Time.

Das Blöde ist, dass die Gerätebezeichnungen unterschiedlich sein können.
Wenn das System einen USB-Stick als /dev/sdd eingebunden hat, kann ein
danach eingestöpseltes Gerät /dev/sde bekommen. Deshalb ist es seit
einiger Zeit sinnvoller, mit UUIDs zu hantieren – die sind für jeden
*Datenträger* einzigartig.

Gruß

Gregor

[Marco Moock]

Deshalb ist es seit einiger Zeit sinnvoller, mit UUIDs zu hantieren –
die sind für jeden *Datenträger* einzigartig.

Es gibt da mehrere IDs.
Einmal die UUID des Dateisystems, dann die GUID der GPT und eine
Partitions-UUID.

Unter /dev/disk kann man anhand dieser die Geräte gescheit wählen.

[Gregor Szaktilla]

Post by Marco Moock

Deshalb ist es seit einiger Zeit sinnvoller, mit UUIDs zu hantieren –
die sind für jeden *Datenträger* einzigartig.

Es gibt da mehrere IDs.
Einmal die UUID des Dateisystems, dann die GUID der GPT und eine
Partitions-UUID.

Jau, shit, die Familien-Universabenutzer sind inzwischen ganz schön
kompliziert geworden :-)

Gruß

Gregor

[Erik Heinz]

Post by Marco Moock
Unter /dev/disk kann man anhand dieser die Geräte gescheit wählen.

Praktisch. Das kannte ich noch nicht.

Viele Grüße,
Erik

[Sieghard Schicktanz]

Hallo Gregor,

Post by Gregor Szaktilla
Wenn das System einen USB-Stick als /dev/sdd eingebunden hat, kann ein
danach eingestöpseltes Gerät /dev/sde bekommen. Deshalb ist es seit

Das kann sogar noch einige Zeit nach dem Entfernen des ersteren passieren,
undes kann dadurch auch Lücken in den Bezeichnungen geben.

Post by Gregor Szaktilla
einiger Zeit sinnvoller, mit UUIDs zu hantieren – die sind für jeden
*Datenträger* einzigartig.

Nein. "einzigartig" ist allenfalls die Naivität, mit der das immer
behauptet wird. Kopiere eine Platte, ein Dateisystem oder sonst einen
Verwaltungsbereich, der eine "UUID" enthält - schon ist die nicht mehr
"einzigartig". Und dann gibt's so nette Programme wie "uuidgen", die solche
Nummereien beliebig erzeugen können, oder ganz primitiv sowas wie "dd",
Binär-Editoren u.v.a., mit denen man solche Daten beliebig massakrieren
kann. Nein, "einzigartig" ist da garnichts dran.
(Und wer das nicht beachtet, wird irgendwann davon gebissen werden.)

[Gregor Szaktilla]

Post by Sieghard Schicktanz
Nein. "einzigartig" ist allenfalls die Naivität, mit der das immer

Zum Zeitpunkt des Anlegens IST sie einzigartig.

Du willst klugscheißen und Erbsen zählen.

Gruß

Gregor

[Sieghard Schicktanz]

Hallo Gregor,

Du schriebst am Fri, 19 Apr 2024 22:37:15 +0200:

["UUID"]

Post by Gregor Szaktilla
Zum Zeitpunkt des Anlegens IST sie einzigartig.

Allenfalls auf em System, das sie anlegt. Da sie lokal erzeugt wird, kann
das nicht anders sein.

Post by Gregor Szaktilla
Du willst klugscheißen und Erbsen zählen.

Universelle Ansprüche müssen sich an universellen Kriterien messen lassen.
UUIDs fallen da durch.

[Peter J. Holzer]

Post by Sieghard Schicktanz
["UUID"]

Post by Gregor Szaktilla
Zum Zeitpunkt des Anlegens IST sie einzigartig.

Allenfalls auf em System, das sie anlegt. Da sie lokal erzeugt wird, kann
das nicht anders sein.

UUIDs sind 128 Bit lang. Je nach Art der UUID ist ein guter Teil davon
entweder echt zufällig oder in Raum oder Zeit eindeutig. Nehmen wir
konservativ 100 Bit Entropie an, dann ist die Wahrscheinlichkeit, dass
eine frisch erzeugte UUID schon existiert, ca. 10^-100 * der Anzahl der
bereits erzeugten UUIDs. Also jedenfalls irgendwo unterhalb von 10^-80.
Klein genug, um zufällige Kollisionen vernachlässigen zu können, da das
Risiko von nicht-zufälligen Kollisionen (durch Klonen von Filesystemen,
deterministische Erzeugung von UUIDs, etc.) um viele viele
Größenordnungen höher ist.

hp

[Diedrich Ehlerding]

Post by Sieghard Schicktanz

Post by Gregor Szaktilla
einiger Zeit sinnvoller, mit UUIDs zu hantieren – die sind für jeden
*Datenträger* einzigartig.

Nein. "einzigartig" ist allenfalls die Naivität, mit der das immer
behauptet wird. Kopiere eine Platte, ein Dateisystem oder sonst einen
Verwaltungsbereich, der eine "UUID" enthält - schon ist die nicht mehr
"einzigartig". Und dann gibt's so nette Programme wie "uuidgen", die
solche Nummereien beliebig erzeugen können, oder ganz primitiv sowas
wie "dd", Binär-Editoren u.v.a., mit denen man solche Daten beliebig
massakrieren kann. Nein, "einzigartig" ist da garnichts dran.
(Und wer das nicht beachtet, wird irgendwann davon gebissen werden.)

Es kommt halt drauf an, was man eindeutig identifizieren will.

Den Inhalt einer Platte, zB das Filesystem? Dann nimmt man dessen Label
oder UUID. (/dev/disk/by-label oder /dev/disk/by-uuid). Ja, wenn man
davon dd-Kopien herstellt, ist das hinterher nicht mehr eindeutig.

Den Datenträger: Dann nimmt man dessen Seriennummer (/dev/disk/by-id)

Den physikalischen Anschluss: /dev/disk/by-path-

Wie auch immer: man muss wissen, was man tut (und wenn man, wie du oben,
über lowlevel-Kopien von Datemnträgern nachdenkt, sollte man sehr genau
wissen, was man tut). Aber was auch immer man erreichen will: die
Legacy-Namen (/dev/sd*) sind die schlechteste Wahl.

[Sieghard Schicktanz]

Hallo Diedrich,

Du schriebst am Sat, 20 Apr 2024 08:11:58 +0200:

["UUID"s]

Post by Diedrich Ehlerding

Post by Sieghard Schicktanz
massakrieren kann. Nein, "einzigartig" ist da garnichts dran.
(Und wer das nicht beachtet, wird irgendwann davon gebissen werden.)

Es kommt halt drauf an, was man eindeutig identifizieren will.

Undvor allem, in welchem Rahmen.

Post by Diedrich Ehlerding
Den Inhalt einer Platte, zB das Filesystem? Dann nimmt man dessen Label
oder UUID. (/dev/disk/by-label oder /dev/disk/by-uuid). Ja, wenn man
davon dd-Kopien herstellt, ist das hinterher nicht mehr eindeutig.

Labels kann man definiert eintragen und sich merken, UUIDs sind unmerkbar.

Post by Diedrich Ehlerding
Den Datenträger: Dann nimmt man dessen Seriennummer (/dev/disk/by-id)

0000-00-0000. Oder 0.0. Sowas ist da _auch_ recht beliebt...

Post by Diedrich Ehlerding
Den physikalischen Anschluss: /dev/disk/by-path-

Physischen. Der ist wenigstens maschinen-eindeutig.

Post by Diedrich Ehlerding
Wie auch immer: man muss wissen, was man tut

Eben, genau das. Und wenn man das ignoriert und die Bezeichnungen als
letzte Wahrheit ansoeht, dann _kann_ das durchaus mal recht, ähm,
"lehrreich" werden.

[Diedrich Ehlerding]

Post by Sieghard Schicktanz

Post by Diedrich Ehlerding
Den Datenträger: Dann nimmt man dessen Seriennummer (/dev/disk/by-id)

0000-00-0000. Oder 0.0. Sowas ist da _auch_ recht beliebt...

Das merkt man dann ja, wenn man diesen Datenträger erstmals verwendet.
Eigentlich ist sowas ein Grund, ihn nicht zu verwenden.

[Diedrich Ehlerding]

Post by Richard Fonfara
Mir fiel auf, dass ich einen Pfad ausgewählt
hatte, der *sdb* enthielt anstatt *sdd*. Wenn ich aber mit *lsblk* mir
die Laufwerke/Partitionen ansehe, ist da kein *sdb* enthalten. Es gibt
nur sda, sdc und die diversen NVMe-Partitionen.

Hattest du in dieser sessio90n mal externe Laufwerke an- und wieder
abgestöpselt?

[Richard Fonfara]

Post by Diedrich Ehlerding

Post by Richard Fonfara
Mir fiel auf, dass ich einen Pfad ausgewählt
hatte, der *sdb* enthielt anstatt *sdd*. Wenn ich aber mit *lsblk* mir
die Laufwerke/Partitionen ansehe, ist da kein *sdb* enthalten. Es gibt
nur sda, sdc und die diversen NVMe-Partitionen.

Hattest du in dieser sessio90n mal externe Laufwerke an- und wieder
abgestöpselt?

Nein, ich habe die externe Platte, die ich fürs Backup nehme, nicht
zwischendrin ab- und wieder angestöpselt.

[Richard Fonfara]

Post by Richard Fonfara
Debian Bookworm aktueller Stand.
Ich habe eben Backup gemacht und bekam zuerst gemeldet, ich hätte keine
Rechte auf das Verzeichnis. Mir fiel auf, dass ich einen Pfad ausgewählt
hatte, der *sdb* enthielt anstatt *sdd*. Wenn ich aber mit *lsblk* mir
die Laufwerke/Partitionen ansehe, ist da kein *sdb* enthalten. Es gibt
nur sda, sdc und die diversen NVMe-Partitionen.

Jetzt, wo das Backup-Laufwerk abgeklemmt ist, zeigt mir *lsblk* doch
*sdb* an. Und zwar handelt es sich hierbei um einen Stick. Das
Merkwürdige war ja, dass vorher, bei angestöpselter HD, in meinem
Backupprogramm nicht nur einen Pfad enthielt, der *sdb* enthielt,
sondern dass Caja mir dort frühere Backups anzeigte. Ich habe eben auf
dem Stick nachgesehen: Dort sind keine Backups drauf.

Rätsel über Rätsel.

[Hermann Riemann]

Post by Richard Fonfara

Post by Richard Fonfara
Debian Bookworm aktueller Stand.
Ich habe eben Backup gemacht und bekam zuerst gemeldet, ich hätte keine
Rechte auf das Verzeichnis. Mir fiel auf, dass ich einen Pfad ausgewählt
hatte, der *sdb* enthielt anstatt *sdd*. Wenn ich aber mit *lsblk* mir
die Laufwerke/Partitionen ansehe, ist da kein *sdb* enthalten. Es gibt
nur sda, sdc und die diversen NVMe-Partitionen.

Jetzt, wo das Backup-Laufwerk abgeklemmt ist, zeigt mir *lsblk* doch
*sdb* an. Und zwar handelt es sich hierbei um einen Stick. Das
Merkwürdige war ja, dass vorher, bei angestöpselter HD, in meinem
Backupprogramm nicht nur einen Pfad enthielt, der *sdb* enthielt,
sondern dass Caja mir dort frühere Backups anzeigte. Ich habe eben auf
dem Stick nachgesehen: Dort sind keine Backups drauf.
Rätsel über Rätsel.

wurden die Geräte für sdc und sdd
mit angeschlossenen USB-stick eingebaut und partioniert?

Wenn die Zuordnung von Verzeichnissen an sdx
hängt, was bei älteren Linux Versionen
vielleicht der Fall war..

Ob ein sdx auch noch vom SATA Steckplatz abhängt
mag ich nicht ausschließen.

[Richard Fonfara]

Post by Hermann Riemann

Post by Richard Fonfara

Post by Richard Fonfara
Debian Bookworm aktueller Stand.
Ich habe eben Backup gemacht und bekam zuerst gemeldet, ich hätte keine
Rechte auf das Verzeichnis. Mir fiel auf, dass ich einen Pfad ausgewählt
hatte, der *sdb* enthielt anstatt *sdd*. Wenn ich aber mit *lsblk* mir
die Laufwerke/Partitionen ansehe, ist da kein *sdb* enthalten. Es gibt
nur sda, sdc und die diversen NVMe-Partitionen.

Jetzt, wo das Backup-Laufwerk abgeklemmt ist, zeigt mir *lsblk* doch
*sdb* an. Und zwar handelt es sich hierbei um einen Stick. Das
Merkwürdige war ja, dass vorher, bei angestöpselter HD, in meinem
Backupprogramm nicht nur einen Pfad enthielt, der *sdb* enthielt,
sondern dass Caja mir dort frühere Backups anzeigte. Ich habe eben auf
dem Stick nachgesehen: Dort sind keine Backups drauf.
Rätsel über Rätsel.

wurden die Geräte für sdc und sdd
mit angeschlossenen USB-stick eingebaut und partioniert?

Der Stick war eingesteckt, als ich Debian installiert habe. sdc habe ich
hier nicht, nur noch sr0 für das DVD-Laufwerk.

[Gregor Szaktilla]

Post by Richard Fonfara
Rätsel über Rätsel.

Wenn ein Laufwerk (oder USB-Stick) nicht gemountet ist, werden in dessen
„Mount-Pfad“ trotzdem Dateien geschrieben. Sie landen dann halt nicht
auf dem Stick, sondern vermutlich auf der System-Partition. Wenn der
Stick dort gemountet ist, /überdeckt/ dessen Inhalt das, was sich sonst
dort befindet.

Vielleicht ist das des Rätsels Lösung.

Gruß

Gregor

[Richard Fonfara]

Post by Gregor Szaktilla

Post by Richard Fonfara
Rätsel über Rätsel.

Wenn ein Laufwerk (oder USB-Stick) nicht gemountet ist, werden in dessen
„Mount-Pfad“ trotzdem Dateien geschrieben. Sie landen dann halt nicht
auf dem Stick, sondern vermutlich auf der System-Partition. Wenn der
Stick dort gemountet ist, /überdeckt/ dessen Inhalt das, was sich sonst
dort befindet.
Vielleicht ist das des Rätsels Lösung.
Der Stick ist unter /media gemountet, die externe Platte wurde unter /run gemountet. Unter beiden finde ich keine Backupdaten.

[Sieghard Schicktanz]

Hallo Richard,

Post by Richard Fonfara
Jetzt, wo das Backup-Laufwerk abgeklemmt ist, zeigt mir *lsblk* doch
*sdb* an. Und zwar handelt es sich hierbei um einen Stick. Das
Merkwürdige war ja, dass vorher, bei angestöpselter HD, in meinem
Backupprogramm nicht nur einen Pfad enthielt, der *sdb* enthielt,
sondern dass Caja mir dort frühere Backups anzeigte. Ich habe eben auf
dem Stick nachgesehen: Dort sind keine Backups drauf.
Rätsel über Rätsel.

Nein, keine Rätsel. Dein Backup-Programm hat lediglich, nachdem es mit dem
USB-Stick auf "seiner" Geräte-Kennung nix anfangen konnte, den ge-umountet
und ein System-Service hat den "unbenutzten" Stick dann abgemeldet. Nachdem
Du die Backup-Platte abgesteckt hattest, hat derselbe System-Service die
angeschlossenen Geräte wieder durchsucht, den Stick als "noch unangemeldet"
erkannt und wieder zur Verfügung gestellt. Ganz normale Vorgänge aufgrund
der (überbordenden?) Automatisierung im Sinne der "Benutzerfreundlichkeit".

[Richard Fonfara]

Ich habe beide Backupplatten nochmal - nacheinander - angestöpselt. Bei
der einen war der Pfad /run/media/private/richard/sdc3, bei der anderen
/run/media/private/richard/sdd3.

Ich werde also zukünftig darauf achten müssen, welchen Pfad zuluCrypt
mountet.

[Sieghard Schicktanz]

Hallo Richard,

Post by Richard Fonfara
Ich habe beide Backupplatten nochmal - nacheinander - angestöpselt. Bei
der einen war der Pfad /run/media/private/richard/sdc3, bei der anderen
/run/media/private/richard/sdd3.

Durchaus normal.

Post by Richard Fonfara
Ich werde also zukünftig darauf achten müssen, welchen Pfad zuluCrypt
mountet.

Oder ihm ein geeigneteres Auswahlkriterium einstellen, vielleicht ein
"Label" für das Backup-Dateisystem, das immer gleich ist. Und wenn das
nicht gehen sollte, solltest Du Dich vielleicht nach einem Nachfolger für
das Programm umsehen, das da besser bestallt ist.

[Richard Fonfara]

Post by Sieghard Schicktanz

Post by Richard Fonfara
Ich habe beide Backupplatten nochmal - nacheinander - angestöpselt. Bei
der einen war der Pfad /run/media/private/richard/sdc3, bei der anderen
/run/media/private/richard/sdd3.

Durchaus normal.

Post by Richard Fonfara
Ich werde also zukünftig darauf achten müssen, welchen Pfad zuluCrypt
mountet.

Oder ihm ein geeigneteres Auswahlkriterium einstellen, vielleicht ein
"Label" für das Backup-Dateisystem, das immer gleich ist. Und wenn das
nicht gehen sollte, solltest Du Dich vielleicht nach einem Nachfolger für
das Programm umsehen, das da besser bestallt ist.

Mittlerweile habe ich das Rätsel gelöst: Wenn man zuluCrypt beendet,
wird die externe Platte nicht unmountet. Vorm Beenden muss ich in der
Menüleiste unter zC "Alle Volumes schließen" anklicken und erst dann
zuluCrypt beenden. Wenn ich dann meine zweite Platte anschließe, wird
sie unter demselben Pfad gemountet wie die erste.

Vielen Dank für eure Beiträge.