Forum Linux.débutant Cloner un disque Linux Debian

Posté par  . Licence CC By‑SA.
Étiquettes :
1
2
nov.
2013

Bonjour à tous,
Je suis nouveau et débutant Linux.

On m'a demandé de cloner un disque (DiskOnModule: mémoire flash sur un port spécifique de la carte mère. Différent de l'IDE classique)
contenant DEBIAN et de le recopier sur des disques classiques (type SSD 2,5", brancher à l'issu sur un slot IDE classique).

J'ai utilisé les commandes suivantes pour duppliquer le DiskOnModule vers mon SSD:
DD IF=/DEV/HDC OF /DEV/HDB
DD IF=/DEV/HDC OF/DEV/HDB BS=512 COUNT=1
Mon disque a cloner est donc nommé HDC (HDC1 et HDC2 pour le swap)
Mon disque destination est donc nommé HDB (HDB1 et HDB2 pour le swap)

Le souci, c'est qu'en tentant de faire booter le nouveau disque sur HDB (pas de souci), jusqu'au moment ou il cherche HDC2 (hors le nouveau swap se nomme HDB2).
A partir de là, je lui indique le nouveau chemin /DEV/HDC2
mais il m'affiche une erreur un peu plus bas: "/BIN/SH : CAN'T ACCESS TTY; JOB CONTROL TURNED OFF"

Je suis une buse en LINUX, malgré tout j'ai tenté de modifier depuis un livecd Kaella "/ETC/FSTAB" (par miracle j'ai réussi), mais impossible de modifier "/BOOT/GRUB/MENU.LST" (problème de droit). Alors que je suis ROOT sur le livecd.

Auriez-vous la solution ? sachant que j'ignore si je me dirige dans la bonne direction !!!
Alexandre

  • # l'idée est bonne

    Posté par  . Évalué à 3.

    mais tu va devoir faire à la main ce que certains outils semblent en mesure de faire eux meme.
    j'ai deja passé un disque entier vers un autre avec clonezilla,
    toutes les partitions ont bougés puisqu'en lors du clonage c'etait sda -> sdb
    mais qu'apres le reboot sdb etait devenu sda

    et ca s'est bien passé pour toutes les partitions presentes (windows, linux).

    si tu peux, eviter les references en dur /dev/hdXY
    prefere les UUID ou les LABEL
    l'UUID d'un disque s'obtient avec la commande blkid

    et dans fstab suffit de remplacer le /dev/hdXY par UUID=xyztutodp
    (xyztutodp etant l'UUID trouvé avec blkid)

    mais en admettant qu'il faille quand meme le faire à la main, depuis un livecd/liveusb/bootpxe, voici comment je procede
    il faut etre sur qu'il n'y ait que / et swap comme partition sur le disque
    sinon il faut mounter d'abord / de destination
    mount /dev/hdb1 /mnt

    puis si elles existent les autres partitions dans leur dossier respectif ( sdXY -> /boot)
    par ex mount /dev/hdb3 /mnt/boot

    mais d'apres ce que tu dis, il n'y a que 2 partitions sur le disk, le / hdb1 et le swap hdb2

    enfin, idealement, il faut mounter /dev en bind dans la partition de destination
    mount --bind /dev /mnt/dev

    peut-etre /proc aussi
    mount -t proc /proc /mnt/proc

    et finalement entrer dans le systeme de destination pour faire les dernieres commandes :
    chroot /mnt

    qui devrait te placer sur le nouveau disque, comme si tu etais sur le system final
    te permettant de lancer les commandes shell classiques comme grub-install, update-grub

    une fois toutes les mises à jour necessaires faites :
    * se deconnecter du chroot (exit ou Ctrl+D)
    * demonter proc, dev, boot et finalement /mnt
    * redemarrer la machine

  • # bienvenue

    Posté par  . Évalué à 3.

    Bonjour,

    Alors comme c'est pas caps lock day je précise que bien des commandes (sinon toutes…) dans le monde gnu / linux prennent compte de la casse.

    Ta deuxième commande ne sert à rien car la première a déjà copié l'intégralité de hdc sur hdb (et ça comprend les segments de départ - table de partoches et mbr). La première suffit donc à faire ce que tu souhaites. Je te recommande d'être prudent dans le maniement de ce genre de commandes car on a vite fait de s'emmêler les pinceaux en inversant les disques … écrasant de facto les précieuses données.

    Ce genre de transplantation peut effectivement nécessiter des petites retouches sur grub et fstab, mais j'ai du mal à cerner le contexte dans lequel tu te trouves lorsque tu tapes tes commandes.
    Avec le live-cd, tu es sur un linux "virtuel", dont les fichiers et toute l'arborescence se trouve en ram -donc volatile.

    on va lui créer un répertoire :
    mkdir /mnt/arbo

    on va le monter :
    mount /dev/hdb1 /mnt/arbo

    (je précise que c'est à adapter à ton système, cela implique que le disque visé est toujours hdb (ça peut changer suivant les live-cd) et que tu utilises un plan de partitionnement simple (genre mettre la swap en premier puis le root puis le boot N'EST PAS ce qu'on fait d'habitude, mais cela dépend de la fantaisie de l'utilisateur)

    et voila pour la 'prep'. Le système de ton disque dur est dispo via /mnt/arbo. Si tu veux donc éditer un fichier par exemple fstab tu fais : nano /mnt/arbo/etc/fstab

    En principe, il faut modifier grub.conf, fstab et éventuellement réinstaller le mbr.
    Ces étapes peuvent nécessiter pas mal de temps. Je te recommanderais plutôt de récupérer tes données et de repartir de zero avec un live-cd.

  • # .

    Posté par  . Évalué à 1.

    Merci pour tout vos bons conseils. Je vais tenter vos manipulations dès lundi.

    Pour la petite histoire, il s'agit de matériels spécifiques (transmission radio géré par un système Debian). L'entreprise qui a développé cette unité a fait le choix de placer des DiskOnModule (à la place des disques classique). Malheureusement des problèmes de fiabilité apparaissent de temps à autre au niveau du stockage. D’où l'idée de cloner "brute de décoffrage" ces disques.
    L'idée de partir de zéro, en installant un OS et replaquant les programmes m'a traversé l'esprit. Mais ne connaissant pas le fonctionnement du système et plus précisément du programme, cela ne m'a pas paru judicieux.
    Sachant également qu'il s'agit pour le moment de test afin d'intervenir le jour venu en urgence afin de remettre en état de marche le système (en un minimum de temps).
    Vu les circonstances, j'ai une crainte à l'idée de commencer a modifier les données du disque d'origine, au risque de remettre en cause le fonctionnement complet de la machine.

    Malgré tout, je vais tenter ce que vous m'expliquer. En espérant que cela fonctionne.
    Je vous tient au courant.

    Merci.

    • [^] # Re: .

      Posté par  . Évalué à 3.

      Vu les circonstances, j'ai une crainte à l'idée de commencer a modifier les données du disque d'origine, au risque de remettre en cause le fonctionnement complet de la machine.

      ATTENTION !!! Personne ne t'a suggéré de modifier les données d'origine. Toutes les manips suggérées sont à faire sur la copie de destination.

  • # Autre solution...

    Posté par  . Évalué à -3.

    Salut,

    Une autre solution consisterait à créer une image ISO de ton disque, puis de monter la partition qui t'intéresse, et de modifier les fichiers adéquats.

    • [^] # Re: Autre solution...

      Posté par  . Évalué à -1.

      Pourrai-je savoir ce qui me vaut ses moinsoiements ?
      J'ai dit une c*nnerie ?

      Peut-être est-ce le terme ISO ? Il est vrai que j'aurai du parler d'image et non d'image ISO ;-\

      Merci d'éclairer ma lanterne.

      • [^] # Re: Autre solution...

        Posté par  . Évalué à 2.

        parce que c'est deja ce qu'il fait donc ton commentaire n'apporte strictement rien

        il fait un dd du diskonmodule vers un vrai disque dur
        et il travaille sur le disque dur

        • [^] # Re: Autre solution...

          Posté par  . Évalué à 0.

          Merci pour cette réponse.

          Par contre, si on s'en réfère au message initial que je cite :

          On m'a demandé de cloner un disque (DiskOnModule: mémoire flash sur un port spécifique de la carte mère. Différent de l'IDE classique)
          contenant DEBIAN et de le recopier sur des disques classiques (type SSD 2,5", brancher à l'issu sur un slot IDE classique).

          N'est-il pas plus aisé de faire une image, de modifier ladite image et ensuite de recopier cette image sur les disques, plutôt que de modifier chaque disque un par un ?

          • [^] # Re: Autre solution...

            Posté par  . Évalué à 2.

            si tu le fais une fois, ensuite tu clones le premier clone plutot que l'original

            ca revient au meme

            toutefois l'avantage de l'image disque sous forme d'un fichier monté en loop,
            c'est que tu peux l'utiliser dans une machine virtuelle.

  • # .

    Posté par  . Évalué à 0.

    Bonjour,
    j'ai tapé les commandes suivantes depuis un livecd:
    mount /dev/hdb1 /mnt
    mount --bind /dev /mnt/dev
    chroot /mnt

    A partir de là, j'ai pu, sans difficulté modifier /boot/grub/menu.lst et /etc/fstab
    J'ai modifié chaque ligne en remplaçant hbc1 par hdb1.

    update-grub
    update-initramfs -u
    vim /etc/initramfs-tools/conf.d/resume
    j'ai modifié hdc2 en hdb2

    Désormais au redémarrage du système, j'ai une nouvelle erreur (j'ai régressé):
    kernel panic-not syncing : VFS :unable to mount root fs on unknown-block

    Je suis perdu!

    • [^] # Re: .

      Posté par  . Évalué à 2.

      tu fais les commandes dans le desordre,
      ton update-grub va mettre ton /boot/grub/menu.lst à jour tout seul

      ton update-initramfs met à jour le initramfs
      mais tu modifies les options APRES

      et du coup

      kernel panic-not syncing : VFS :unable to mount root fs on unknown-block

      dit que visiblement il ne connait pas hdb

      comme dit precedement essaye de ne pas utiliser les peripheriques blocks
      prefere les UUID que tu obtiens avec la commande blkid dans ton chroot.

      et ton fstab doit ressembler à :

      UUID="adebdfzedfhjgsfkjh"  /  ext4 defaults 0 0

      • [^] # Re: .

        Posté par  . Évalué à 0.

        J'ai suivi les instructions.
        A savoir :
        J'ai recommencé de zéro:
        dd if=/dev/hdc of/dev/hdb
        J'ai débranché mon disque d'origine par mesure de précaution.
        mount /dev/hdb1 /mnt
        mount --bind /dev /mnt/dev
        chroot /mnt
        /sbin/blkid

        J'ai modifié le fstab:
        /dev/hdc1 par UUID=id de la partition
        /dev/hdc2 par UUID=id du swap

        J'ai modifié /boot/grub/menu.lst:
        # kopt=root=UUID=id de la partition ro

        update-grub

        J'ai remplacé RESUME=/dev/hdc2 par UUID=id du swap :
        nano /etc/initramfs-tools/conf.d/resume

        J'ai remplacé RESUME DEVICE=/dev/hdc2 par UUID=id du swap :
        nano /etc/uswsusp.conf

        update-initramfs -u car update-initramfs -u -k $(uname -r) me renvoie une erreur …init non trouvé.

        Je dois louper une commande: car toujours l'erreur
        Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(22,1).

        • [^] # Re: .

          Posté par  . Évalué à 2.

          presque bien.

          sur debian lenny (oui c'est pas tout jeune)
          c'est grub 0.97

          tu as l'option kroot, mais aussi l'option groot
          chez moi groot=(hd0,0)

          puis plus bas, placée par update-grub, et reprenant certaines options

          title           Debian GNU/Linux, kernel 2.6.26-2-686
root            (hd0,0)
kernel          /boot/vmlinuz-2.6.26-2-686 root=UUID=eaabc1c7-c9e0-4b97-bf5d-14f8dbf64230 ro
initrd          /boot/initrd.img-2.6.26-2-686

          on voit ici qu'il utilise le kroot
          mais il installe aussi une ligne initrd.

          pour cela il faut surement que l'initrd/initramfs existe

          dans ton cas le update-initramfs -u -k $(uname -r) se vautre car tu lui demande un upgrade d'un initrd qui n'existe pas

          pour cela il faut le creer avec
          update-initramfs -c -k $(uname -r)

          et tu dois le voir dans /boot

          ensuite seulement tu peux lancer le update-grub

          • [^] # Re: .

            Posté par  . Évalué à -1.

            Bonjour,
            Après plusieurs tentatives, quelques prises de tête, rien n'y fait.
            Je me suis aperçu, lors de la commande update-initramfs -c -k $(uname -r) qu'il me renvoit une erreur update-initramfs: failed for /boot/initrd.img-2…

            Je vais finir par croire que c'est impossible de cloner 1 disque!!

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.