Lacie Familiebox schijf mounten Linux

[ronny]

Mijn schoonvader heeft een een Lacie Family (aka Cloudbox) box 1202 140 rev c.
Deze werkt niet meer. Ik heb aangegeven dat ik mogelijk wel de data van de schijf kon halen.

Ik heb de schijf uit de box gehaald en op de SATA aangesloten.
Ik draai op de computer Ubutu 15.10.



Op de schijf zijn 8 partitie's aanwezig.
7 om Linux te huisvesten en 1 data.

Dit is wat ik vond:

code:

# npart name        size(MiB) type  fstype     fsoption
  1     grub_core   1         ef02 
  2     boot_rescue 192       8300  ext2
  3     nv_data     1         8300  ext2
  4     root_1      1536      fd00  ext2
  5     root_2      1536      fd00  ext2
  6     var         1024      fd00  ext3
  7     swap        256       fd00  linux-swap

Groote: 2,0 TB (1995631042048 bytes)
Apparaat: /dev/sdf8
Partitietype: Linux RAID
Inhoud: Linux RAID Member (versie 1.0)

Dat bevreemd mij omdat er maar 1 schijf inzit. Dus waarom en hoe LinuxRAID.

Bovenal kan ik deze niet mounten.
Kan ik vanuit Linux wel bij deze inhoud komen?

[Hero of Time]

Veel van die huis NAS dingen maken een RAID volume aan, ongeacht de hoeveelheid schijven. Je kan via mount -t <filesystem> de partitie alsnog mounten.

Maar bovenal, welke meldingen kreeg je bij je pogingen en wat heb je zelf gezocht en nog meer ondernomen?

[ronny]

Ik heb gezocht met google, maar kom er nog niet uit.
Eerst heb ik een pool gemaakt:

code:

sudo mdadm --assemble --run /dev/md1 /dev/sdb8
mdadm: /dev/md1 has been started with 1 drive.

Vervolgens probeer ik die te mounten:

code:

user:~$ sudo mount /dev/md1 /mnt/test
mount: unknown filesystem type 'LVM2_member'

Ik kan er nog niet achter komen wat voor file systeem het is.

code:

 sudo lvdisplay
  /run/lvm/lvmetad.socket: connect failed: Bestand of map bestaat niet
  WARNING: Failed to connect to lvmetad. Falling back to internal scanning.
  /dev/sdb6: read failed after 0 of 4096 at 1073733632: Invoer-/uitvoerfout
  --- Logical volume ---
  LV Path                /dev/vg/lv
  LV Name                lv
  VG Name                vg
  LV UUID                g9Ss5K-J1SM-Fsf7-K19l-4tJz-XQ3s-bS5a3P
  LV Write Access        read/write
  LV Creation host, time , 
  LV Status              NOT available
  LV Size                1,82 TiB
  Current LE             475795
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto

Komt ik ook niet verder mee.
Toch nog eens geprobeerd zonder aanmaken van pool:

code:

sudo mdadm --stop /dev/md1
mdadm: stopped /dev/md1
user:~$ sudo xfs_check /dev/sdb8
sudo: xfs_check: opdracht niet gevonden
user:~$ sudo mount -t ext2 /dev/sdb8 /mnt/test
mount: wrong fs type, bad option, bad superblock on /dev/sdb8,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

dmesg | tail
[ 5766.488654] sd 1:0:0:0: [sdb] tag#6 Sense Key : Medium Error [current] [descriptor] 
[ 5766.488663] sd 1:0:0:0: [sdb] tag#6 Add. Sense: Unrecovered read error - auto reallocate failed
[ 5766.488672] sd 1:0:0:0: [sdb] tag#6 CDB: Read(10) 28 00 00 86 17 f0 00 00 08 00
[ 5766.488678] blk_update_request: I/O error, dev sdb, sector 8787952
[ 5766.488718] ata2: EH complete
[ 8316.540386] md1: detected capacity change from 1995630899200 to 0
[ 8316.540397] md: md1 stopped.
[ 8316.540405] md: unbind<sdb8>
[ 8316.564052] md: export_rdev(sdb8)
[ 8560.165709] EXT4-fs (sdb8): VFS: Can't find ext4 filesystem

Op het Ubuntu forum kwam ik de foutmelding tegen door een fouttief superblok:

code:

sudo e2fsck -f /dev/sdb8

e2fsck 1.42.12 (29-Aug-2014)
ext2fs_open2(): Ongeldig magisch getal in superblok
e2fsck: Superblok is ongeldig -- reservekopieblokken worden bekeken...
e2fsck: Ongeldig magisch getal in superblok tijdens openen van /dev/sdb8

Het superblok is onleesbaar of omschrijft geen geldig ext2/3/4-bestandssysteem.
Als het apparaat juist is en werkelijk een ext2-, ext3- of ext4-bestandssysteem
bevat (en niet swap of UFS of iets anders), dan is het superblok beschadigd.
U kunt dan proberen een ander superblok te gebruiken, bijvoorbeeld:
    e2fsck -b 8193 <apparaat>
of:
    e2fsck -b 32768 <apparaat>

user:~$ sudo dumpe2fs -f /dev/sdb8 | grep -i superblock
dumpe2fs 1.42.12 (29-Aug-2014)
dumpe2fs: Ongeldig magisch getal in superblok tijdens openen van /dev/sdb8

Kan ik zonder gevaar voor gegevens het superblok aanpassen of klopt het superblok niet omdat het een soort raid was?

[ Voor 113% gewijzigd door ronny op 29-01-2016 11:41 . Reden: aanvullingen ]

[Hero of Time]

Je leest zo over de meldingen heen die precies opgeven wat je moet doen. Je moet het logische volume eerst zichtbaar maken. Doe dat via vgchange -ay. Dan heb je 'opeens' de LVM volumes beschikbaar en prompt, daar heb je je werkelijke data in staan. Er is geen geldig file system op sdb8, omdat het een LVM volume is.

[ronny]

Dank voor de hulp!

code:

sudo mdadm --assemble --run /dev/md1 /dev/sdb8
mdadm: /dev/md1 has been started with 1 drive.

user:~$ sudo vgchange -a y 
  1 logical volume(s) in volume group "vg" now active

Kijk nu komen we ergens!

code:

user:~$ sudo lvdisplay /dev/vg
  --- Logical volume ---
  LV Path                /dev/vg/lv
  LV Name                lv
  VG Name                vg
  LV UUID                g9Ss5K-J1SM-Fsf7-K19l-4tJz-XQ3s-bS5a3P
  LV Write Access        read/write
  LV Creation host, time , 
  LV Status              available
  # open                 0
  LV Size                1,82 TiB
  Current LE             475795
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:0

user:~$ sudo mount /dev/vg/lv /mnt/test
mount: wrong fs type, bad option, bad superblock on /dev/mapper/vg-lv,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

user:~$ dmesg | tail
[29181.998788] ata2.00: configured for UDMA/133
[29181.998846] sd 1:0:0:0: [sdb] tag#7 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[29181.998857] sd 1:0:0:0: [sdb] tag#7 Sense Key : Medium Error [current] [descriptor] 
[29181.998865] sd 1:0:0:0: [sdb] tag#7 Add. Sense: Unrecovered read error - auto reallocate failed
[29181.998874] sd 1:0:0:0: [sdb] tag#7 CDB: Read(10) 28 00 74 92 36 98 00 00 08 00
[29181.998880] blk_update_request: I/O error, dev sdb, sector 1955739288
[29181.998941] JBD2: Failed to read block at offset 723
[29181.998944] ata2: EH complete
[29182.076168] JBD2: recovery failed
[29182.076181] EXT4-fs (dm-0): error loading journal

[Hero of Time]

Volgens http://serverfault.com/qu...s-for-lvm-logical-volumes kan je met het volgende meer informatie krijgen over het volume:

lvs --all --noheadings | while read lv vg rest; do file --dereference --special-files "/dev/mapper/$vg-$lv"; done

Je zou daarmee moeten achterhalen welk filesystem er in gebruik is. Je hebt al gezien dat het geen ext4 oid is, dus moet het wat anders zijn. Eenmaal achterhaald, kan je er mee doen wat je wilt.

[johnkeates]

Sense Key : Medium Error [current] [descriptor]

HDD stuk? Doe eerst maar een dd_rescue (of ddrescue/dd-rescue afhankelijk van je distro) en ga vanaf een image werken?

Je kan met blkid ook wel vinden welke ID's er zijn, even je MD array starten, vg actief maken en dan sudo blkid.

Grote kans dat je met XFS te maken hebt, misschien handig om dat te installeren? Of anders gewoon een greep uit de meest voorkomende filesystems, en gewoon support voor ze allemaal installeren?

[ronny]

user:~$ sudo lvs --all --noheadings | while read lv vg rest; do file --dereference --special-files "/dev/mapper/$vg-$lv"; done
[sudo] wachtwoord voor user:

/dev/mapper/vg-lv: Linux rev 1.0 ext4 filesystem data, UUID=2e6c973d-c1bd-4033-9385-757535a80b66 (needs journal recovery) (extents) (large files) (huge files)

Dus misschien toch failure!?

code:

(parted) toon
Model: ATA ST2000DM001-9YN1 (scsi)
Schijf /dev/sdb: 2000GB
Sectorgrootte (logisch/fysiek): 512B/4096B
Partitietabel: gpt
Schijfvlaggen: 

Nummer  Begin   Einde   Grootte  Bestandssysteem  Naam         Vlaggen
 1      1049kB  2097kB  1049kB                    grub_core    bios_grub
 2      2097kB  203MB   201MB    ext2             boot_rescue
 3      203MB   204MB   1049kB   ext2             nv_data
 4      204MB   1815MB  1611MB   ext2             root_1       raid
 5      1815MB  3426MB  1611MB   ext2             root_2       raid
 6      3426MB  4499MB  1074MB   ext3             var          raid
 7      4499MB  4768MB  268MB    linux-swap(v1)   swap         raid
 8      4768MB  2000GB  1996GB                    user_data    raid

(parted) red                                                              
Begin? 4768MB                                                             
Einde? 2000GB                                                             
(parted) toon                                                             
Model: ATA ST2000DM001-9YN1 (scsi)
Schijf /dev/sdb: 2000GB
Sectorgrootte (logisch/fysiek): 512B/4096B
Partitietabel: gpt
Schijfvlaggen: 

Nummer  Begin   Einde   Grootte  Bestandssysteem  Naam         Vlaggen
 1      1049kB  2097kB  1049kB                    grub_core    bios_grub
 2      2097kB  203MB   201MB    ext2             boot_rescue
 3      203MB   204MB   1049kB   ext2             nv_data
 4      204MB   1815MB  1611MB   ext2             root_1       raid
 5      1815MB  3426MB  1611MB   ext2             root_2       raid
 6      3426MB  4499MB  1074MB   ext3             var          raid
 7      4499MB  4768MB  268MB    linux-swap(v1)   swap         raid
 8      4768MB  2000GB  1996GB                    user_data    raid

Het is dus wel EXT4 nu nog uitvinden hoe ik die terug krijg.

code:

sudo fsck.ext4 -vy /dev/sdb8
e2fsck 1.42.12 (29-Aug-2014)
ext2fs_open2(): Ongeldig magisch getal in superblok
fsck.ext4: Superblok is ongeldig -- reservekopieblokken worden bekeken...
fsck.ext4: Ongeldig magisch getal in superblok tijdens openen van /dev/sdb8

Het superblok is onleesbaar of omschrijft geen geldig ext2/3/4-bestandssysteem.
Als het apparaat juist is en werkelijk een ext2-, ext3- of ext4-bestandssysteem
bevat (en niet swap of UFS of iets anders), dan is het superblok beschadigd.
U kunt dan proberen een ander superblok te gebruiken, bijvoorbeeld:
    e2fsck -b 8193 <apparaat>
of:
    e2fsck -b 32768 <apparaat>

Dan het superblok proberen te fixxen:

code:

sudo e2fsck -b 32768 /dev/sdb8
e2fsck 1.42.12 (29-Aug-2014)
e2fsck: Ongeldig magisch getal in superblok tijdens openen van /dev/sdb8

Het superblok is onleesbaar of omschrijft geen geldig ext2/3/4-bestandssysteem.
Als het apparaat juist is en werkelijk een ext2-, ext3- of ext4-bestandssysteem
bevat (en niet swap of UFS of iets anders), dan is het superblok beschadigd.
U kunt dan proberen een ander superblok te gebruiken, bijvoorbeeld:
    e2fsck -b 8193 <apparaat>
of:
    e2fsck -b 32768 <apparaat>

Ik heb beide geprobeerd, maar het mag niet baten.

[ Voor 21% gewijzigd door ronny op 29-01-2016 11:37 ]

[Hero of Time]

Waarom zit je toch telkens op sdb8 te rommelen, terwijl het juist een LVM volume is? Straks heb je die hele partitie gesloopt en ben je verder van huis.

Ga iig eerst even zorgen voor een volledige image van de schijf. Dan kan je helemaal los gaan op de schijf, of op het image.

Als je een mount -t ext4 /dev/mapper/vg/lv doet, werkt dat wel, of blijft 't klagen?

[ronny]

code:

sudo mount -t ext4 /dev/mapper/vg/lv
mount: can't find /dev/mapper/vg/lv in /etc/fstab

sdb8 is toch de partitie die fout is?
maar om te voorkomen (niet dat het een wereldramp zou zijn) probeer ik zoveel mogelijk te doen zonder te schrijven.
het probleem met een image is dat het 2 TB is en ik niet meer zoveel ruimte vrij heb....

Ik kan hem wel actief maken maar niet mounten

[ Voor 10% gewijzigd door ronny op 29-01-2016 11:37 ]

[Ultraman]

Waarschijnlijk doelt Hero o.a. op dit soort acties:

sudo e2fsck -b 32768 /dev/sdb8

Je bent hier een ext file checker een partitie aan het geven waar geen ext bestandssysteem op staat, maar wat een LVM PV zou zijn. Ipv. /dev/sdb8 zou je /dev/mapper/vg/lv (vervangen voor juiste naam) moeten ingeven.
Ben je bekend met hoe LVM werkt?
In zo'n LVM Physical Volume zit weer een Volume Group, met daarin weer een Logical Volume.
Op zo'n Logical Volume bevind zich het ext4 bestandssysteem waar jij naar op zoek bent.

Dat

mount -t ext4 /dev/mapper/vg/lv

niet werkt komt omdat je geen doel op geeft waar die partitie gemount moet worden. Je mist daar dus een argument.
Ook heb ik het idee dat het ding misschien /dev/mapper/vg-lv heet. Dus een - ipv een /. En ook heb ik /dev/vg/lv voorbij zien komen in je lvdisplay.

Even voor de goede orde, de syntax voor mount in het kort:

mount [-t mogelijk fs, -o opties] <block device (=bron)> <mount pad (=doel)>

Hoe verder?
1. Maak een plek beschikbaar waar je de data wilt mounten. Bijvoorbeeld onder /mnt/lacie (die zal vast nog niet bestaan). Aanmaken met:

sudo mkdir /mnt/lacie

2. Kijken of je de LaCie gemount kunt krijgen op die plek met één van deze commando's of variaties daar op.

mount /dev/mapper/vg/lv /mnt/lacie

of

mount /dev/mapper/vg-lv /mnt/lacie

of

mount /dev/vg/lv /mnt/lacie

ronny schreef op vrijdag 29 januari 2016 @ 11:20:
het probleem met een image is dat het 2 TB is en ik niet meer zoveel ruimte vrij heb....

Dan hoop ik dat de data op die disk minder van belang is. Want wat je nu aan het doen bent is gevaarlijk.
Als dit belangrijke data is zou ik acuut stoppen. En dan of de ruimte om er een image van te maken regelen. Of deze klus uitbesteden aan iemand die hier meer ervaring mee heeft.

Er van leren is een goed uitgangspunt natuurlijk. Zo heb ik veel van mijn kennis ook vergaard. Maar pas goed op wanneer je met andermans data werkt en probeer het risico gewoon te beperken of liever nog geheel weg te nemen. Dat kan door toch met een image te werken.

[ Voor 8% gewijzigd door Ultraman op 29-01-2016 11:44 ]

[ronny]

Ultraman schreef op vrijdag 29 januari 2016 @ 11:38:
Waarschijnlijk doelt Hero o.a. op dit soort acties:

sudo e2fsck -b 32768 /dev/sdb8

Dat had ik al geprobeerd en staat 2 reactie's hoger

Je bent hier een ext file checker een partitie aan het geven waar geen ext bestandssysteem op staat, maar wat een LVM PV zou zijn. Ipv. /dev/sdb8 zou je /dev/mapper/vg/lv (vervangen voor juiste naam) moeten ingeven.
Ben je bekend met hoe LVM werkt?
In zo'n LVM Physical Volume zit weer een Volume Group, met daarin weer een Logical Volume.
Op zo'n Logical Volume bevind zich het ext4 bestandssysteem waar jij naar op zoek bent.

Nee ik ben slecht bekend met LVM, ik ken het betaan en bij de installatie kan ik het aangeven, maar verder niet.

Dat

mount -t ext4 /dev/mapper/vg/lv

niet werkt komt omdat je geen doel op geeft waar die partitie gemount moet worden. Je mist daar dus een argument.

Foutje, zover ben ik wel dat ik normale dingen mounten kan. Hierboven staat ook dat ik het wel goed geprobeerd heb.

Ook heb ik het idee dat het ding misschien /dev/mapper/vg-lv heet. Dus een - ipv een /. En ook heb ik /dev/vg/lv voorbij zien komen in je lvdisplay.

Hierboven heb ik het ook al eens geprobeerd met /dev/vg/lv maar dan komt hij dat het fs niet goed is.
Daaruit maak ik op dat de verwijzing wel goed is.

Even voor de goede orde, de syntax voor mount in het kort:

mount [-t mogelijk fs, -o opties] <block device (=bron)> <mount pad (=doel)>

Hoe verder?
1. Maak een plek beschikbaar waar je de data wilt mounten. Bijvoorbeeld onder /mnt/lacie (die zal vast nog niet bestaan). Aanmaken met:

sudo mkdir /mnt/lacie

2. Kijken of je de LaCie gemount kunt krijgen op die plek met één van deze commando's of variaties daar op.

mount /dev/mapper/vg/lv /mnt/lacie

of

mount /dev/mapper/vg-lv /mnt/lacie

of

mount /dev/vg/lv /mnt/lacie

De map had ik al aangemaakt en de standaard commando's voor mounten zijn bij mij ook wel bekend. De basis dingen heb ik al een paar jaar onder de knie, maar als het niet lukt wordt het lastig. In de basis pruts ik al hele wat jaren met linux, maar echt verder kom ik er niet mee. Dus zie ik hier een mooie uitdaging.

[...]

Dan hoop ik dat de data op die disk minder van belang is. Want wat je nu aan het doen bent is gevaarlijk.
Als dit belangrijke data is zou ik acuut stoppen. En dan of de ruimte om er een image van te maken regelen. Of deze klus uitbesteden aan iemand die hier meer ervaring mee heeft.

Er van leren is een goed uitgangspunt natuurlijk. Zo heb ik veel van mijn kennis ook vergaard. Maar pas goed op wanneer je met andermans data werkt en probeer het risico gewoon te beperken of liever nog geheel weg te nemen. Dat kan door toch met een image te werken.

Het is hier geen belangrijke data:
1. Het is voor de schoonfamilie en dus altijd leuk als ik het voor elkaar krijg.
2. Ik wil graag meer inzicht hebben hoe het werkt en wat de mogelijkheden zijn.
3. Eerst heb ik vooral geprobeerd met niet destructieve aktie's te boel te mounten, maar ik geloof nu toch dat ik met data moet schuiven om een kopie te maken.

code:

(parted) toon
Model: ATA ST2000DM001-9YN1 (scsi)
Schijf /dev/sdb: 2000GB
Sectorgrootte (logisch/fysiek): 512B/4096B
Partitietabel: gpt
Schijfvlaggen: 

Nummer  Begin   Einde   Grootte  Bestandssysteem  Naam         Vlaggen
 1      1049kB  2097kB  1049kB                    grub_core    bios_grub
 2      2097kB  203MB   201MB    ext2             boot_rescue
 3      203MB   204MB   1049kB   ext2             nv_data
 4      204MB   1815MB  1611MB   ext2             root_1       raid
 5      1815MB  3426MB  1611MB   ext2             root_2       raid
 6      3426MB  4499MB  1074MB   ext3             var          raid
 7      4499MB  4768MB  268MB    linux-swap(v1)   swap         raid
 8      4768MB  2000GB  1996GB                    user_data    raid

Alleen bij partitie 8 staat geen bestandsysteem. Dus daar lijkt wel het probleem te zitten.

[ninjazx9r98]

Als je al aan de slag wilt/moet met het filesystem dan moet je sowieso de fsck uitvoeren op het logical volume en niet op de partitie.

code:

fsck.ext4 /dev/vg/lv

Dat er geen bestandssysteem staat bij partitie 8 klopt, dat is er niet en hoort er ook niet te zijn op partitie niveau.
Het kan in ieder geval geen kwaad om je eens in te lezen in LVM om beter te begrijpen waar je nu eigenlijk naar aan het kijken bent.
Beetje vloeken in de kerk misschien maar mocht je beter bekend zijn met Windows dan kun je het (kort door de bocht) een beetje vergelijken met een dynamisch volume.
In een volume group heb je één of meerdere disken (of partities in het geval van Linux maar het gaat even om het principe) wat je kunt vergelijken met een dynamisch volume met daarin één of meerdere disken.
In die volume group maak je vervolgens logical volumes wat je weer kunt vergelijken met partities op een dynamisch volume.
Op zo'n logical volume zet je vervolgens een filesystem zoals je dat ook doet op een partitie binnen een dynamisch volume.
De fsck doe je op het fileystem en dat bevindt zich in dit geval dus op het logical volume en niet op de partie (lees voor het gemak anders even disk) sdb8.

[Hero of Time]

Nee, partitie 8 is zoals er staat onderdeel van een RAID set met daarbij LVM erop. Die heeft geen file system, dat zit IN het LVM volume. Net zoals je een encrypted container een file system kan maken.

Wat ^^ zegt.

[ Voor 3% gewijzigd door Hero of Time op 29-01-2016 14:30 ]