• Herzlich willkommen im "neuen" DSLR-Forum!

    Wir hoffen, dass Euch das neue Design und die neuen Features gefallen und Ihr Euch schnell zurechtfindet.
    Wir werden wohl alle etwas Zeit brauchen, um uns in die neue Umgebung einzuleben. Auch für uns ist das alles neu.

    Euer DSLR-Forum-Team

  • In eigener Sache!

    Liebe Mitglieder, liebe Besucher und Gäste
    ich weiß, es ist ein leidiges Thema, aber ich muss es ansprechen: Werbung, Werbeblocker und Finanzierung des Forums.
    Bitte hier weiterlesen ...

  • DSLR-Forum Fotowettbewerb neu erfunden!
    Nach wochenlanger intensiver Arbeit an der Erneuerung des Formates unseres internen Fotowettbewerbes ist es Frosty als Moderator
    und au lait als Programmierer gelungen, unseren Wettbewerb auf ein völlig neues Level zu heben!
    Lest hier alle Infos zum DSLR-Forum Fotowettbewerb 2.0
    Einen voll funktionsfähigen Demowettbewerb kannst du dir hier ansehen.
  • Neuer Partner: AkkuShop.de
    Akkus, Ladegeräte und mehr (nicht nur) für Digitalkameras und Drohnen
  • Neuer Gutscheincode unseres Partners Schutzfolien24:
    DSLR-Forum2024
    Dauerhaft 10% Rabatt auf alle Displayschutzfolien der Eigenmarken "Upscreen", "Brotec", "Savvies".
    Der Code ist für alle Geräteklassen gültig.
  • Stimmt ab über die Sieger des DSLR-Forum Fotowettbewerbs April 2024.
    Thema: "Sprichwörtlich"

    Nur noch bis zum 30.04.2024 23:59!
    Jeder darf abstimmen!
    Zur Abstimmung und Bewertung hier lang
WERBUNG

Unmount - was kann man falsch machen / Karte ist nicht formatiert

Ich habe eben versucht das Problem zu verifizieren. Verschiedenes auf die Karte kopiert, wieder gelöscht (komplett, nicht nur in den Papierkorb) und rebootet. Wärend des Neustarts den Kartenleser entfernt. Die ersten zwei mal wollte die Kamera die Karte neu formatieren, bei den nächsten Versuchen nicht mehr. Konnte dann auch nicht mehr Testen, ob der Rechner denn die von der Kamera zurückgewiesene Karte noch liest.
Interessanterweise benutze ich den gleichen Kartenleser, vielleicht liegt es an dem. Wenn du mit f3 Lesefehler hast, spricht das dafür (verifiziert, dass es nicht an der Karte lag?).
Teste jetzt auch mal mit F3.
Grüße
Frank
 
An genau dieser Karte liegt es bei mir sicher nicht, eventuell am Modell, aber wenn, dann sind es zufällig mehrere, die ich verwende.

Um ganz sicher zu sein, dass die Karte kein Problem hat, verwende ich zuerst "badblocks -svw" und danach f3. Wenn beides fehlerfrei ist, dann gehe ich davon aus, dass die Karte ok ist. Obwohl ich mir da auch nicht mehr sicher bin. Eine µSDHC von Patriot, die im Handy verwendet wurde, hatte schon 1x "bad superblock", bestand danach aber alle Tests und nach ca. 1 Jahr mit kaum Verwendung, das gleiche Problem wieder.

Vielleicht sollte ich den Anker als Standard-Cardreader verwenden. Ich mag den Transcend lieber, weil ich bei dem die Karte nach vorne gerichtet einstecke, beim Anker zeigt die Karte nach hinten. Das Handling mit dem Transcend ist mir lieber. Mein PC steht abgekoppelt von Stößen auf dem "Monitor-Tisch" dahinter auf einem weiteren kleinen Tisch.
 
Ich verwende übrigens einen Transcend TS-RDF5K zum Lesen, ...

Hast du die Gelegenheit, vielleicht mal (leihweise) einen anderen Cardreader zu testen?

Ich hatte schon mal das Problem, dass so ein Lesegerät einfach nicht mehr richtig wollte...

//EDIT

Hat sich überschnitten mit deinem letzten Beitrag ;)
Macht der ANKER Reader denn dieselben Probleme?
 
Zuletzt bearbeitet:
Also meine Transcend SD XC 64GB SD-Karte, die zweimal neu formatiert werden musste, zeigte mit F3 im Transcend-Leser zweimal keine Fehler.
Ich tippe wirklich auf einen Bug im exFat-Treiber...

Grüße
Frank
 
Hier mal die Mountoptionen bei einer 16GB-Karte

Code:
/dev/sdf1 on /media/xx/KP type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)

Größere Karte folgt, wenn ich wieder eine verwende.
 
Formate sind Standards. Der Rest ist Esoterik. Jedes BS schreibt versteckte Dateien auf die Karten beim Zugriff, Dinge wie Papierkorb werden angelegt.

Das ist Unsinn. Mein Mount-Util (OpenSuse) greift auf die Karte in ca. 20% aller Fälle nur readonly zu, weil es Inkonsistenzen im Dateisystem erkennt. Dann wird mit Sicherheit nichts geschrieben. Ist für mich der Grund, nur noch unter Linux auf Karten zuzugreifen- Win schert sich nicht um solche Feinheiten. Dateisystemtreiber von Kameras und Betriebssystemen sind m.E. nur begrenzt kompatibel.
 
Ich verwende übrigens einen Transcend TS-RDF5K zum Lesen ...
Ich verwende einen Transcend TS-RDF8K. K-3II hat letztens die 64GB Karte wieder nicht erkannt. Formatiert in der Kamera. 2-3 Bilder gemacht. Zuerst alles OK, dann waren die Bilder plötzlich weg. Vielleicht ist der Kartenleser nicht ganz unschuld :confused:.
 
Ich hatte mal die Situation mit der KP, dass die KP verschiedene Karten nicht mehr formatieren wollte und auch der Cardreader hat die Karte nicht mehr gelesen. Mittlerweile mag sowohl die KP als auch der Cardreader die Karte wieder.

Aber es ist schon ein guter Hinweis, dass es Sinn macht einen anderen Cardreader zu probieren.

Mit einer 128GB-Karte direkt aus der K-1. Karte formatiert und ein paar Fotos gemacht:

Code:
/dev/sdf1 on /media/XX/K-1 type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)

# gdisk -l /dev/sdf
GPT fdisk (gdisk) version 1.0.3

Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: not present


***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory.
***************************************************************


Warning! Secondary partition table overlaps the last partition by
33 blocks!
You will need to delete this partition or resize it in another utility.
Disk /dev/sdf: 247068672 sectors, 117.8 GiB
Model: SD Transcend
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): F044B3F6-8EA1-41D4-8DBE-6D1B6F18B59B
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 247068638
Partitions will be aligned on 2048-sector boundaries
Total free space is 32734 sectors (16.0 MiB)

Number Start (sector) End (sector) Size Code Name
1 32768 247068671 117.8 GiB 0700 Microsoft basic data

gdisk meldet also:

Found invalid GPT and valid MBR; converting MBR to GPT format
in memory.

Warning! Secondary partition table overlaps the last partition by
33 blocks!
You will need to delete this partition or resize it in another utility.


Jetzt kann man sich also fragen, ob die Pentax-FW nicht sauber formatiert oder der exFAT-Treiber buggy ist.
 
Zuletzt bearbeitet:
Ich denke Pentax ist vorerst aus dem Rennen. Ich habe eine neue Karte probiert, die noch nie in einer Pentax war und da gibt es dieses Problem auch.

DIe Fehlermeldung habe ich auch, wenn ich exFAT formatiere. Vgl. https://wiki.ubuntuusers.de/exFAT/

Die Suche nach "Secondary partition table overlaps the last partition" bringt eine Menge an Ergebnissen. Viel schlauer bin ich noch nicht, aber es könnte mit gdisk zusammenhängen.
 
Welche Überraschung. Ausgerechnet Pentax gehört zu den Kameraherstellern, die es scheinbar genau wie viele andere schaffen, seit über 15 Jahren eine SD-Karte zu beschreiben.

Aber ich bin schon gespannt, wie das Jugend-Forscht hier weitergeht, ob JensPeter doch noch Gründe für das Versagen von Pentax findet, ob die SD-Karte vielleicht doch ein völlig bug-behaftetes Medium ist und ob ggf. doch noch die Borg alles assimilieren. Vielleicht trifft ja auch das Rotkäppchen auf die böse Stiefmutter...
 
Also Pentax ist nicht aus dem Rennen und ich vermute das Problem gefunden zu haben. Das Problem dürfte die Partitionstabelle sein, die nicht GPT-kompatibel angelegt wird, weder bei den Herstellern noch von Pentax, sondern wie früher MSDOS konform ist. Nach dem Kauf kann ich das ja noch verstehen. Aber Pentax legt auch MS-DOS kompatibel an, wenn man mit gparted die Partitonstabelle entfernt. Ich habe das mit einer K5-II probiert

Code:
/dev/sdf1 on /media/XX/K-5 II type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)

Code:
fdisk -l /dev/sdf
Festplatte /dev/sdf: 60,4 GiB, 64826114048 Bytes, 126613504 Sektoren
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
Festplattenbezeichnungstyp: dos
Festplattenbezeichner: 0x00000000

Gerät      Boot Anfang      Ende  Sektoren Größe Kn Typ
/dev/sdf1        32768 126613503 126580736 60,4G  7 HPFS/NTFS/exFAT


Festplattenbezeichnungstyp: dos

Das stammt also alles aus der K5-II. Die Karte wurde nicht am PC partitioniert und formatiert.
 
Was ich jetzt auf die Schnelle gefunden habe ist daran nichts böses. Wirst ja mit der Speicherkarte nicht über 2 TB kommen.
 
Genau, msdos=MBR ist der Standard bei Wechseldatenträgern.
GPT ist Teil der UEFI-Definition und wird bei Platten >2TB verwendet und eben bei Boot-Platten mit UEFI.
Dass gdisk (GPT-disk) irgendwelche Fehler meldet ist Mumpiz, das sagt er bei jedem MBR-Laufwerk.
fdisk ist für MBR das tool der Wahl, oder parted/gparted...
Das einzig Auffällige ist, dass Pentax einen kleinen Leerplatz am Anfang der Karte lässt, nach dem erst die Datenpartition folgt.
Die Kamera meckert allerdings nicht über eine Karte die "ordnungsgemäß" voll mit einer Partition belegt ist.

Bin nach wie vor der Meinung, dass es ein Bug im aktuellen exFat-Treiber oder im fuse-System ist.
 
Zuletzt bearbeitet:
Genau, msdos=MBR ist der Standard bei Wechseldatenträgern.

Aus diesem Grund wäre ich nie auf die Idee gekommmen, das exFAT bei "normalen" Speicherkarten bei Kameras verwendet wird.

Wenn man unter Linux alles richtig macht, dann passt es auch. Man muss also als Dateisystem gpt mit zB parted definieren und danach mit mkfs.exfat formatieren. Damit mecker gdisk nicht!

Die Frage ist also, ob exFAT zwingend gpt verlangt. um korrekt zu funktionieren und nicht irgendwie. Dann weis man auch, wo das Problem liegt.

Verwende ich eine SD-Karte, die gpt als Dateisystem hat und formatiere ich diese mit mkfs.exfat so meint die K5-II beim Einlegen "formatieren". So weit klar, und ich komme dem nach.

Danach schalte ich die K5 aus, gebe die Karte heraus und stecke sie in den Transcend-Reader:

Code:
# gdisk -l /dev/sdf
GPT fdisk (gdisk) version 1.0.3

Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: present

Found valid MBR and GPT. Which do you want to use?
 1 - MBR
 2 - GPT
 3 - Create blank GPT

Your answer: 2
Using GPT and creating fresh protective MBR.
Disk /dev/sdf: 126613504 sectors, 60.4 GiB
Model: SD  Transcend   
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 4DF6F5CD-3697-4B3C-B9B1-359D211101E8
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 126613470
Partitions will be aligned on 2048-sector boundaries
Total free space is 4029 sectors (2.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048       126611455   60.4 GiB    8300  primary

Die Pentax-Formatierung dürfte somit nicht ganz korrekt sein. Ich lasse mich aber gerne vom Gegenteil überzeugen. Mir ist das egal, wo nun der Fehler liegt, Hauptsache es gibt keine Probleme.

Found valid MBR and GPT. Which do you want to use?

Ich rate mal, dass das zum Problem beim Einlegen wird, auch wenn die Karte korrekt ausgehängt wurde. Ich hatte gerade mit dieser Karte in der K5-II keine Probleme, als ich sie sofort nach dem Unmount herausgenommen habe.
 
Zuletzt bearbeitet:
Die Art der Partionstabelle, MBR oder GPT, hat NICHTS mit den Filesystemen, mit denen die Partitionen formatiert sind zu tun!
Man kann FAT32, exFAT, EXT3, NTFS, etc. sowohl mit MBR als auch GPT benutzen.
 
So, eben getestet: egal ob ich einen USB-Stick oder SD-Karte mit exFAT formatiere, wirft journalctl bzw dmesg beim unmounten einen I/O-Error und Buffer-I/O Error aus. Mit FAT32 ist alles ok.

Welche Auswirkung das hat, keine Ahnung, wäre aber eine Erklärung für die "defekten" Karten. Allerdings werden die SD-Karten ohne write-cache gemountet, insofern sollte also nichts mehr geschrieben werden beim unmounten...
-> Bug. Bestätigt meine Erinnerung, das das erst ab Ubuntu 18.04 auftritt...
 
Die Art der Partionstabelle, MBR oder GPT, hat NICHTS mit den Filesystemen, mit denen die Partitionen formatiert sind zu tun!
Man kann FAT32, exFAT, EXT3, NTFS, etc. sowohl mit MBR als auch GPT benutzen.

Ich fand eigentlich nur, dass es sinngemäß "eine gute Idee" ist mit exFAT GPT zu verwenden, aber nicht, dass es zwingend ist.

Also ich hatte meine Probleme ganz sicher auch schon mit 16.04. Vielleicht sind das aber auch 2 verschiedene Probleme.

Ich habe jetzt mal die Partitionstabelle ausgenullt. Die Kamera legt msdos an:

Code:
# parted /dev/sdf 'unit s print'
Modell: TS-RDF5 SD Transcend (scsi)
Festplatte  /dev/sdf:  126613504s
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: msdos
Disk-Flags: 

Nummer  Anfang  Ende        Größe       Typ      Dateisystem  Flags
 1      32768s  126613503s  126580736s  primary

Also offensichtlich hält die Kamera am Anfang einen Platz beim Formatieren frei.
 
Zuletzt bearbeitet:
Schafft es irgendwer am Linux-PC die Karte so "anzulegen", dass sie die Kamera nicht formatieren will?

Nachdem Pentax bei einer Karte ohne Dateisystem msdos verwendet, habe ich mal wieder msdos statt gpt probiert. Die Kamera will trotzdem formatieren.

Nach der Formatierung in der Kamera:

Code:
# parted /dev/sdf print
Modell: TS-RDF5 SD Transcend (scsi)
Festplatte  /dev/sdf:  64,8GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: msdos
Disk-Flags: 

Nummer  Anfang  Ende    Größe   Typ      Dateisystem  Flags
 1      16,8MB  64,8GB  64,8GB  primary

Code:
# parted /dev/sdf 'unit s print'
Modell: TS-RDF5 SD Transcend (scsi)
Festplatte  /dev/sdf:  126613504s
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: msdos
Disk-Flags: 

Nummer  Anfang  Ende        Größe       Typ      Dateisystem  Flags
 1      32768s  126613503s  126580736s  primary
 
Zuletzt bearbeitet:
WERBUNG
Zurück
Oben Unten