Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Affichage des résultats 1 à 21 sur 21
  1. #1
    Bonjour à vous !

    J'avais un serveur maison, sous Linux Mint, dont j'ai upgrade le combo CM+CPU (passage d'une P43DE + E7500 à H170-D3HP avec un i5-6500).
    Fatalement j'ai réinstallé l'OS, mais ça c'est pas un soucis, c'est sur un ssd qui fait sa vie et n'a rien à voir dans l'histoire

    Mon serveur avait un raid1 software (de 2 disques pour le moment) fait avec amour à coup de mdadm.
    Le montage initial était peut être pas fait dans les règles de l'art mais aucun problèmes avec le raid. Pour info au départ j'ai dû créer un raid "mono disque" pour conserver les données dessus et formater ensuite le disque qui devait servir à grow le raid (j'avais que 2 DD 4To dont un contenait mes données, les tours de hanoi revisitées)

    Bref, là je tente de remonter mon raid et c'est le drame :

    Code:
    ~$ sudo mdadm -A --verbose /dev/md0 /dev/sdb /dev/sdc
    mdadm: Cannot assemble mbr metadata on /dev/sdb
    mdadm: /dev/sdb has no superblock - assembly aborted


    Je me dis what the fucking fuck et tente de vérifier les disques (les 2 disques renvoient les même résultats) :

    Code:
    ~$ sudo fdisk -l /dev/sd*
    
    
    
    
    
    Disque /dev/sdb : 3,7 TiB, 4000787030016 octets, 7814037168 secteurs
    Unités : secteur de 1 × 512 = 512 octets
    Taille de secteur (logique / physique) : 512 octets / 4096 octets
    taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
    Type d'étiquette de disque : gpt
    Identifiant de disque : 08653A5D-9FAD-411E-A4CA-4C0456195F97
    
    
    Périphérique Début        Fin   Secteurs Taille Type
    /dev/sdb1     2048 7814037134 7814035087   3,7T RAID Linux
    
    
    
    
    Disque /dev/sdb1 : 3,7 TiB, 4000785964544 octets, 7814035087 secteurs
    Unités : secteur de 1 × 512 = 512 octets
    Taille de secteur (logique / physique) : 512 octets / 4096 octets
    taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
    Code:
    ~$ sudo gdisk -l /dev/sdb
    GPT fdisk (gdisk) version 1.0.3
    
    
    Partition table scan:
      MBR: protective
      BSD: not present
      APM: not present
      GPT: present
    
    
    Found valid GPT with protective MBR; using GPT.
    Disk /dev/sdb: 7814037168 sectors, 3.6 TiB
    Model: ST4000DM004-2CV1
    Sector size (logical/physical): 512/4096 bytes
    Disk identifier (GUID): 08653A5D-9FAD-411E-A4CA-4C0456195F97
    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 7814037134
    Partitions will be aligned on 2048-sector boundaries
    Total free space is 2014 sectors (1007.0 KiB)
    
    
    Number  Start (sector)    End (sector)  Size       Code  Name
       1            2048      7814037134   3.6 TiB     FD00
    Bon je me dis ok je vois pas de problème à priori mais je suis un noob de toute façon.
    Le "protective MBR" je sais pas si je dois être fan ceci dit.


    J'essaie d'aller plus loin avec mdadm :

    Code:
    ~$ sudo mdadm -E /dev/sdb
    /dev/sdb:
       MBR Magic : aa55
    Partition[0] :   4294967295 sectors at            1 (type ee)

    Je sais pas trop pourquoi mais j'aime pas, ça me semblait beaucoup plus verbeux avant...

    J'ai innocemment tenté de monter direct le HDD en read-only sans trop croire que ça puisse servir à quelque chose :
    Code:
    ~$  sudo mount -r /dev/sdb1 /mnt/test
    mount: /mnt/test : wrong fs type, bad option, bad superblock on /dev/sdb1, missing codepage or helper program, or other error.
    Au moins ça reconnait un FS j'imagine, mais bon "bad superblock"..



    Du coup je tente le coup de poker avec mdadm :

    Code:
    ~$ sudo mdadm --zero-superblock /dev/sdb
    mdadm: Unrecognised md component device - /dev/sdb
    ETONNANT CA !

    Et j'atteins le seuil de mes connaissances.
    J'ai besoin de vous maintenant et du savoir d'experts CPC

    à ce stade j'ai débranché un des 2 disques, ils sont à priori dans un état identique et je préfère éviter de bousiller les 2 en même temps en allant trop loin.

  2. #2
    Salut, je ne suis pas trop linuxien, mais j'ai une petite question standard.

    Tu indiques que le SSD c'est pour le système. Du coup, que viens faire la MBR sur les HDD ?

    Ton système était initialement installé dessus ? Si oui, je te dirais de commencer par virer les partitions cachées sur l'un de tes HDD (vu qu'ils sont identiques, RAID 1). Tu peux tenter en le branchant en USB (boitier externe). Sinon, passe par un logiciel spécialisé dans les partitions...

    Une fois que tes HDD seront des disques de données "froides" sans OS dessus, le raid 1 ne devrait pas poser problème, à confirmer.

  3. #3
    Je savais pas trop si c'était un problème ou pas d'avoir une MBR dessus, .. mais c'est pas juste une feature de GPT pour du legacy ?

    Je sais pas trop comment c'est arrivé là non plus ça n'a jamais été des disques de boot.
    Du coup je suppose que c'est un gestionnaire de partition qui m'a foutu ça là mais alors j'ai pas souvenir d'avoir initialisé de table de partition et de MBR avant de monter le raid.. à part un coup de fdisk pour définir les 2 supports en type "linux raid auto".

    Je vais regarder un peu cette histoire de passer par un gestionnaire de partition au moins pour voir ce qui peut être fait.
    Sachant que je vais être très très frileux côté manip vu que je suis très loin d'être un expert des disques, partitions et FS, et que ces disques sont des conteneurs critiques.

  4. #4
    Heuuuuu

    Pour moi ton mdadm il était fait sur les PARTITIONS (/dev/sdb1) et pas sur le DISQUE (/dev/sdb)....

    Essaye de refaire ton assemble avec /dev/sdb1 et pas /dev/sdb.

  5. #5
    J'ai tenté un truc dans ce sens là avec l'autre disques pour voir (vu qu'un assemble risquait rien) après avoir rebranché le disque et reboot :

    Code:
    ~$ sudo mdadm --assemble --verbose /dev/md0 /dev/sdc1
    mdadm: looking for devices for /dev/md0
    mdadm: /dev/sdc1 is busy - skipping
    Du coup je check si y'a pas un truc qui tourne :

    Code:
    ~$ cat /proc/mdstat
    Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
    md127 : active (auto-read-only) raid1 sdc1[0]
          3906885440 blocks super 1.2 [1/1] [U]
          bitmap: 0/30 pages [0KB], 65536KB chunk
    OK donc ça m'a sorti tout seul un md127, why not

    Je tente le mount eeeeet...

    Code:
    sudo mount /dev/md127 /mnt/test/
    mount: /mnt/test: wrong fs type, bad option, bad superblock on /dev/md127, missing codepage or helper program, or other error.


    Et un petit "examine" avec mdadm au cas où..

    Code:
    ~$ sudo mdadm -E /dev/md127
    mdadm: No md superblock detected on /dev/md127.
    Je sais pas ce que j'espérais..

  6. #6
    Si tu fais un lsblk ou blkid, il te sort quelque chose avec /dev/md127 ?

  7. #7
    J'obtiens ceci

    Code:
    ~$ lsblk /dev/md127
    NAME  MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
    md127   9:127  0  3,7T  0 raid1
    et sur sdc

    Code:
    ~$ lsblk /dev/sdc
    NAME      MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
    sdc         8:32   0  3,7T  0 disk
    └─sdc1      8:33   0  3,7T  0 part
      └─md127   9:127  0  3,7T  0 raid1
    Donc ça n'a pas l'air totalement con encore


    blkid ne renvoie rien pour md127

  8. #8
    Hmmmm donc là il détecte bien que sdc1 fait partie d'un RAID1 et md127 c'est le device qu'il a créé en auto quand il a détecté un superblock dessus.

    Par contre ce qui est plus inquiétant c'est qu'il ne voit aucun filesystem dessus. Tu avais partitionné ton raid1 ou mis des réglages particuliers au niveau mdadm ?

  9. #9
    Pas d'exotisme autant que je sache, un simple raid1 de 2 disques avec un une unique partition ext4.

    EDIT:
    Par contre faut que je vérifie un truc, quand un des lecteurs était débranché, j'ai tenté une manip à base de "create" sur le sdb sachant qu'il est pas sensé être destructif pour faire un array d'un disque (genre voir si ça refait un superblock en gardant ma structure). Bon j'ai quand même du faire un "force" pour passer outre le check du nombre de disques pour un raid...
    Ce qui aurait marché du coup, j'ai un raid montable, mais pas ce que je veux, et ça nous induirait en erreur...
    Et depuis que j'ai rebranché le 2e disques je me demande si linux n'a pas changé l'assignement des noms sdb et sdc. Donc le md127 vient peut être de cette manip, ça me parait plus logique d'ailleurs qu'il monte auto un raid après que j'ai bidouillé un create et qu'on ait un résultat louche "t'as un raid mais pas de FS dedans".

    Faut peut être que je me concentre sur celui qui est maintenant le sdb ?

    Mais du coup sur sdb j'en suis là :

    Code:
    ~$ lsblk /dev/sdb
    NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
    sdb      8:16   0  3,7T  0 disk
    └─sdb1   8:17   0  3,7T  0 part
    
    ~$ sudo mdadm --examine /dev/sdb
    /dev/sdb:
       MBR Magic : aa55
    Partition[0] :   4294967295 sectors at            1 (type ee)

    Code:
    ~$ sudo fdisk -l /dev/sdb
    Disque /dev/sdb : 3,7 TiB, 4000787030016 octets, 7814037168 secteurs
    Unités : secteur de 1 × 512 = 512 octets
    Taille de secteur (logique / physique) : 512 octets / 512 octets
    taille d'E/S (minimale / optimale) : 512 octets / 512 octets
    Type d'étiquette de disque : gpt
    Identifiant de disque : 3978C15B-C336-4245-94E4-A6F2A5DDE961
    
    Périphérique Début        Fin   Secteurs Taille Type
    /dev/sdb1     2048 7814037134 7814035087   3,7T RAID Linux
    
    
    ~$ sudo fdisk -l /dev/sdb1
    Disque /dev/sdb1 : 3,7 TiB, 4000785964544 octets, 7814035087 secteurs
    Unités : secteur de 1 × 512 = 512 octets
    Taille de secteur (logique / physique) : 512 octets / 512 octets
    taille d'E/S (minimale / optimale) : 512 octets / 512 octets
    et pour comparaison sdc :

    Code:
    ~$ sudo fdisk -l /dev/sdc
    Disque /dev/sdc : 3,7 TiB, 4000787030016 octets, 7814037168 secteurs
    Unités : secteur de 1 × 512 = 512 octets
    Taille de secteur (logique / physique) : 512 octets / 4096 octets
    taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
    Type d'étiquette de disque : gpt
    Identifiant de disque : 08653A5D-9FAD-411E-A4CA-4C0456195F97
    
    Périphérique Début        Fin   Secteurs Taille Type
    /dev/sdc1     2048 7814037134 7814035087   3,7T RAID Linux
    
    
    ~$ sudo fdisk -l /dev/sdc1
    Disque /dev/sdc1 : 3,7 TiB, 4000785964544 octets, 7814035087 secteurs
    Unités : secteur de 1 × 512 = 512 octets
    Taille de secteur (logique / physique) : 512 octets / 4096 octets
    taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
    à part la taille des secteurs physique je vois pas grande différence là dessus et les 2 sont bien captés comme RAID linux en plus.

    Je retente le assemble sur sdb1 pour voir et ...
    Code:
    ~$ sudo mdadm --assemble --verbose /dev/md1 /dev/sdb1
    mdadm: looking for devices for /dev/md1
    mdadm: no recogniseable superblock on /dev/sdb1
    mdadm: /dev/sdb1 has no superblock - assembly aborted
    Lui je pense que c'est bien celui qui était débranché et qui est toujours dans son état non assemblable du début du topic.
    Dernière modification par Say hello ; 02/06/2020 à 09h46.

  10. #10
    Tu peux tenter les mdadm --examine sur les partitions au lieu des disques ?

    Ensuite pour savoir lequel est lequel : hdparm -I /dev/sdX|grep Serial

  11. #11
    Ok donc j'ai fais le hdparm, et pour info j'ai un Toshiba et un Seagate.
    Hier le sdb branché seul, c'était le Seagate, aujourd'hui, avec les 2 disques branché, il est le sdc.
    Donc hier j'ai fais un "create crado" sur le Seagate, donc le sdc actuel qui s'est monté en md127.

    Du coup le disque qu'on va dire "untouched" par ma manip, c'est le Toshiba qui est actuellement le sdb et qui est toujours dans l'état à l'origine du post.

    L'examine sur les partitions :

    Le toshiba "sdb" donc
    Code:
    ~$ sudo mdadm --examine /dev/sdb1
    mdadm: No md superblock detected on /dev/sdb1.

    le seagate "sdc"
    qui s'est pris un "zeroing" de superblock en plus d'un create douteux
    Code:
    ~$ sudo mdadm --examine /dev/sdc1
    /dev/sdc1:
              Magic : a92b4efc
            Version : 1.2
        Feature Map : 0x1
         Array UUID : dd36ab75:ed687279:80a4f024:85c655d0
               Name : MIDGARD:0  (local to host MIDGARD)
      Creation Time : Sun May 31 23:26:02 2020
         Raid Level : raid1
       Raid Devices : 1
    
     Avail Dev Size : 7813770895 (3725.90 GiB 4000.65 GB)
         Array Size : 3906885440 (3725.90 GiB 4000.65 GB)
      Used Dev Size : 7813770880 (3725.90 GiB 4000.65 GB)
        Data Offset : 264192 sectors
       Super Offset : 8 sectors
       Unused Space : before=264112 sectors, after=15 sectors
              State : active
        Device UUID : 0ae1e089:6f00e537:150ec874:1f5a8bef
    
    Internal Bitmap : 8 sectors from superblock
        Update Time : Sun May 31 23:26:02 2020
      Bad Block Log : 512 entries available at offset 24 sectors
           Checksum : 965de6cf - correct
             Events : 0
    
    
       Device Role : Active device 0
       Array State : A ('A' == active, '.' == missing, 'R' == replacing)

    Est ce que je devrais envisager une manip de clonage type "dd if=/dev/sdb of=/dev/sdc" pour réparer ma folie d'hier avant d'aller trop loin ? ou rien de tel pour l'instant ?
    Dernière modification par Say hello ; 02/06/2020 à 13h43.

  12. #12
    Ok donc vire celui qui a eu un create douteux + erase superblock et ne mets que l'autre dans le système.

    Regarde alors si mdadm arrive à assembler quelque chose, et sinon, regarde un lsblk / blkid, voir si quelque chose apparaît sur ton disque.

    Question : tu as migré l'OS, tu as mis à jour ou tu es resté sur la même version ? Parce que si t'as mis à jour, t'as peut être une vieille version de mdadm dont la metadata était stockée différemment.

    Si tu fais un mdadm --detail --scan, ou mdadm --examine --scan, tu as des outputs ?

    (je t'ai rajouté sur Steam, si tu veux qu'on tshoot en live)

  13. #13
    ok donc seul le toshiba est branché maintenant, mais rien de nouveau, le assemble répond :

    Code:
    ~$ sudo mdadm --assemble --verbose /dev/md1 /dev/sdb1
    mdadm: looking for devices for /dev/md1
    mdadm: no recogniseable superblock on /dev/sdb1
    mdadm: /dev/sdb1 has no superblock - assembly aborted
    J'ai check le /proc/mdstat dans le doute mais y'a rien qui tourne ou est actif.

    "mdadm --detail --scan" et "mdadm --examine --scan" n'affichent rien.

    et le lsblk ne donne rien de nouveau

    Code:
    ~$ sudo lsblk /dev/sdb
    NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
    sdb      8:16   0  3,7T  0 disk
    └─sdb1   8:17   0  3,7T  0 part

    Pour l'install de l'OS j'étais reparti from scratch vu que je changeais de Mobo.
    Mais comme le précédent montage était assez récent, la version majeure de la distrib est certainement la même dans les 2 install : Linux Mint 19
    Après est ce que c'était bien la 19.3 ou la 19.2 je ne sais pas mais je pense pas que ça change grand chose à ce niveau là.


    Cool merci pour steam, en ce moment je suis pas assez constamment dispo pour passer en live manip mais si à un moment je peux j'hésiterai pas

  14. #14
    Hmmmm on dirait vraiment que y'a pas de data sur ta partoche qui concerne un md device...

    Si tu fais un :
    Code:
    file -Ls /dev/sdb1

    Ça devrait t'afficher ce qu'il y a sur le disque.

  15. #15
    Il me répond "/dev/sdb1: data" donc je suppose qu'il voit que c'est pas totalement vide mais après sans FS identifié, je sais pas si ça affecte la table de partition ou l'intégrité...

    J'ai fais un "parted -l" par curiosité voir si ça donnait une info en plus ou quoi

    Code:
    Modèle : ATA TOSHIBA HDWQ140 (scsi)
    Disque /dev/sdb : 4001GB
    Taille des secteurs (logiques/physiques) : 512B/512B
    Table de partitions : gpt
    Drapeaux de disque :
    
    Numéro  Début    Fin         Taille         Système de fichiers  Nom  Drapeaux
     1          1049kB  4001GB  4001GB                                            raid



    Je sens que bientôt je vais devoir passer par un testdisk
    Dernière modification par Say hello ; 02/06/2020 à 17h12.

  16. #16
    Ouh... Le data en général c'est que y'a pas de flag ou superblock spécifique, donc ça pue un peu...

    J'ai un peu peur que ton disque il ait perdu (je sais pas pourquoi / comment hein) son superblock...
    Dernière modification par Wobak ; 02/06/2020 à 18h54.

  17. #17
    Et c'est pas comme une partoch ext3 ou ext4 avec des backup du superblock planqués quelque part ?

    J'ai tenté un coup d'oeil dans testdisk mais j'ai pas trop d'idée de ce que je peux faire avec exactement.
    Après une analyse il trouve 2 traces de partitions




    L'une des 2 contient des refs de la précédente vie du disque (dans un NAS Qnap).



    Et l'autre qui est soit ce qui m'intéresse, soit une ancienne partition "data" de la période qnap...:





    partitions qui sont flagguées "deleted" apparemment, pas primary.
    Mais en info de la 2e on voit des flags "ext4" et "Backup_SB", et une action de "load backup" mais je sais pas à quoi m'attendre.

    Je vais peut être rebrancher l'autre disque aussi pour voir si j'ai accès à quelque chose via un testdisk malgré mes manips.

    Je me demande si c'est pas une histoire de changement de CM en passant de techno legacy à de l'uefi sur un chipset qui supporte du raid qui pourrait avoir fumé les débuts de disques..

  18. #18
    Alors résultat intéressant, en lançant un scan approfondi du seagate avec testdisk par contre je tombe sur une trace de partition où je retrouve mon listing de fichiers :



    Et l'arbo est pas mal navigable, j'ai l'impression que tout la liste de fichiers et répertoire est bien là.
    J'ai plus qu'à trouver quoi faire avec ça...

  19. #19
    Une trace de partition ? C'est à dire ?

  20. #20
    Testdisk permettant de scanner le disques pour trouver des partitions endommager, retrouver des fragments de partitions et en récupérer des données, eux même parle de "traces de partition" dans une doc, je restais sur leur terme.

    Y'a moyen de sélectionner un reliquat de partition inactive et de copier des fichiers de l'arbo lu dans la partition vers un autre support.
    Comme le disque a pas eu d'autres I/O depuis le massacre de son superblock, y'a peut être moyen que je parvienne à récup mes données comme ça. ou au moins inventorier son contenu avant perte, pour voir si j'ai définitivement perdu quelque chose de critique.
    Par contre le scan par block sur un disque de 4To c'est.. lent... sans surprise, mais c'est impressionnant ce soft, je me sens comme une merde à être devops java/gcp

  21. #21
    En tout cas avec ça j'arrive à récupérer mes fichiers en les copiant sur un support externe !
    Je suis en train de backuper, ensuite je testerais si testdisk arrive à restaurer la partition mais seulement par curiosité parce qu'une fois les données backup je purge les disques et remonte proprement un raid1 tout neuf.

    Grand merci Wobak pour ton temps et tes idées

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •