Journal Rescue réussi

Posté par (page perso) .
Tags : aucun
11
13
nov.
2010
Hier, je me suis fait une belle frayeur après avoir fait un dd de l'image de DoudouLinux (que j'ai découvert via une récente dépêche de LinuxFR) sur ma clé USB :

sudo dd if=doudoulinux-2010-08-fr.img of=/dev/sdb

... sauf que l'image a atterri sur ma SSD, ce que je n'arrive pas à expliquer puisque ma SSD s'appelle normalement /dev/sda ! Résultat des courses : sans aucune clé USB branchée, mon laptop démarre sur DoudouLinux, sans me laisser aucun choix :-(

Par contre, comme l'image de DoudouLinux fait 800 Mo, j'ai repris espoir en me disant que j'avais flingué les 800 premiers Mo de ma SSD, ce qui correspond au début de ma partition Windows, mais qu'avec un peu de chance ma partition Linux devrait être intacte. Par malheur, je n'ai pas fait de sauvegarde de ma table de partition, me voilà donc parti à la recherche d'un outil pour la reconstruire... ça tombe bien, le week-end s'annonçait pluvieux !

Voilà la procédure que j'ai suivi, et c'était beaucoup plus simple que ce que j'avais imaginé, ça ne m'a pris que quelques heures de mon Vendredi soir !

  1. Sur un autre PC Ubuntu de la maison, téléchargement d'Ubuntu Rescue Remix version 10.10, et installation sur une clé USB grâce à l'outil Créateur de disque de démarrage d'Ubuntu.

  2. Boot de mon portable sur la clé USB Ubuntu Rescue Remix.

  3. Malheureusement, le système ne propose pas de passer le clavier en AZERTY (c'est la seule chose que je reproche à Ubuntu Rescue Remix, le reste est parfait !). Mais on peut le faire en ligne de commande : on s'en sort avec : sudo apt-get install console-data éventuellement suivi d'un : sudo dpkg-reconfigure console-dataNote : malgré ça, certaines touches ne sont toujours pas au bon endroit, mais on s'en sort quand même.

  4. Je jette un oeil à ma table de partition avec cfdisk : effectivement, je ne vois qu'une partition de 800 Mo correspondant à DoudouLinux.

  5. Je lance un des outils de reconstruction de table de partition : sudo testdisk
    Ensuite, il suffit de se laisser guider par les menus. Il retrouve comme par miracle ma partition de Swap et ma partition Ext4 et m'affiche à l'écran une proposition de table de partitions. Comme la proposition à l'air bonne, je lui demande de l'écrire sur ma SSD.

  6. sudo reboot
    pour prendre en compte la nouvelle table de partition.
    Je redémarre sur ma clé USB Ubuntu Rescue Remix.

  7. Je monte ma partition Ext4 dans /mnt/tmp... VICTOIRE, mes données sont là !

  8. Je réinstalle Grub2 sur le MBR :
    sudo grub-install --root-directory=/mnt/tmp /dev/sda

  9. sudo reboot
    Et voilà, tout est rentré dans l'ordre. Je retouve ma chère Ubuntu Maverick.

Bilan :
  • ça ne m'a pris que la première partie de mon Vendredi soir, lecture de doc incluse !
  • mon Ubuntu est ressuscitée !
  • mon Windows 7 est mort, écrasé par DoudouLinux :-)

Autres trucs que j'ai appris :
  • dd_rescue (paquet ddrescue) est un remplacant moderne de dd
  • sur certains BIOS, il faut activer l'option USB legacy support pour pouvoir booter sur une clé USB ou un lecteur CD USB.

Les leçons que j'en tire :
  • sauvegarder son /home avec Back In Time c'est bien, mais dans ce cas il faut éviter de coder dans /usr/local/src... ou bien mettre à jour la liste des répertoires sauvegardés par Back In Time !
  • par défaut, Back In Time exclue les fichiers et répertoires cachés... or les bookmarks Firefox sont stockés dans un répertoire caché. Une petite mise-à-jour de l'onglet "Exclude" des Préférences de Back In Time suffit.
  • faire une sauvegarde de son MBR avec la commande : sudo dd if=/dev/sda of=mbr.img bs=512 count=1 et de la sortie de la commande "p" de fdisk (qui affiche la table des partitions dans un format lisible), ça ne coûte pas cher. Et quand on se se retrouve dans ma situation, ça rassure.
  • toujours vérifier que le device de sortie de dd est bien celui qu'on croit, en lançant par exemple gparted sur le device au préalable.

J'ai voulu poster un message de remerciement dans le forum d'Ubuntu Rescue Remix, et, après avoir validé mon message, une gentille page Web m'informe que mon message est considéré comme du spam... sympa !

J'ai finalement installé les logiciels fournis par DoudouLinux sur ma Ubuntu, et ils ont l'air d'être tous packagés (paquets gamine, childsplay, pysycache, etc...). Et si j'ai peur que mon fils supprime des données à force de taper sur n'importe quelle touche du clavier et de cliquer n'importe où, je peux toujours lui créer un compte à lui sur mon portable !
  • # System Rescue CD

    Posté par (page perso) . Évalué à 10.

    Malheureusement, le système ne propose pas de passer le clavier en AZERTY (c'est la seule chose que je reproche à Ubuntu Rescue Remix, le reste est parfait !).

    Alors qu'il suffisait d'utiliser System Rescue CD ( http://www.sysresccd.org/Page_Principale ) qui te propose de choisir la disposition de ton clavier au démarrage.

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: System Rescue CD

      Posté par . Évalué à 3.

      Pareil. Il y a quelques semaines j'ai eu besoin d'une distribution sur clef usb pour récupérer les données d'un netbook en rade.
      J'essaie Ubuntu Rescue Remix, et c'est le FAIL, le système de démarrage essaie de détecter les disques, d'activer le DMA. Problème, le disque était physiquement demi-mort, les scripts balançaient des erreurs et ne démarraient jamais (j'ai pourtant bataillé).
      Je passe à System Rescue CD (pour info basé sur gentoo) : les scripts ne cherchent pas à jouer au plus malin avec les accélérations matérielles sur une machine cassée. Ça démarre rapidement, y'a les outils qu'il faut (sauf smartctl), on fait le boulot, c'est plié.
      • [^] # Re: System Rescue CD

        Posté par . Évalué à 1.

        Le seul problème pour moi c'est que l'installation sur clef m'a toujours découragée :
        http://www.sysresccd.org/Sysresccd-manual-en_How_to_install_(...)

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: System Rescue CD

          Posté par (page perso) . Évalué à 3.

          Il y a 5 étapes très simple avec un script qui fait tout pour toi. C'est difficile de faire plus simple.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: System Rescue CD

          Posté par . Évalué à 1.

          UNetbootin fait ça très bien tout seul comme un grand:
          http://unetbootin.sourceforge.net/

          Tu lui files une image ISO, il te fait une clé bootable.

          Pof, pof, Igor...
          • [^] # Re: System Rescue CD

            Posté par . Évalué à 3.

            unetbootin n'a jamais voulu fonctionner chez moi, je me retrouve toujours avec des distributions sans noyau.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: System Rescue CD

              Posté par (page perso) . Évalué à 2.

              " unetbootin n'a jamais voulu fonctionner chez moi, je me retrouve toujours avec des distributions sans noyau."

              Une distribution avec pépins quoi ...

              Oui, je sais.
          • [^] # Re: System Rescue CD

            Posté par . Évalué à 2.

            J'ai aussi eu des problèmes avec unetbootin, alors j'ai utilisé Universal USB installer http://www.pendrivelinux.com/universal-usb-installer-easy-as(...) . C'est pour OS proprio (j'étais pas chez moi, je précise) mais il propose un choix de différentes distro linux et les installe sur usb. Sinon sur le site www.pendrivelinux.com/ ils ont des tutos pour des utilitaires sous différents OS.
  • # uuid

    Posté par (page perso) . Évalué à 5.

    Les leçons que j'en tire :
    [...]
    * toujours vérifier que le device de sortie de dd est bien celui qu'on croit, en lançant par exemple gparted sur le device au préalable.


    Et préférer utiliser les uuid pour différencier tes "disques durs/partitions" dans ton système de fichiers plutôt que leur nom "sd*/*" car eux ne pointent pas aléatoirement un(e) disque/partition où un(e) autre...
    ls -l /dev/disk/by-uuid/
    (dans le fstab notamment)
    • [^] # Re: uuid

      Posté par . Évalué à 3.

      Effectivement, il est vraiment pas du tout, mais alors pas du tout conseillé d'utiliser les liens /dev/sd* sans avoir vérifié au préalable qu'il s'agit bien du bon disque que l'on souhaite manipuler.

      Utiliser les uuid est plus sûr car il oblige à faire cette vérification.
      • [^] # Re: uuid

        Posté par . Évalué à 6.

        Encore une des aberrations de Linux ..... Pour moi c'est LE problème de Linux, ce changement de nom de deviced'un reboot à l'autre.
        • [^] # Re: uuid

          Posté par (page perso) . Évalué à 2.

          C'est pour ça qu'on utilise les uuids qui ne change pas. Ça ne me parait pas possible de le fixer.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: uuid

            Posté par . Évalué à 5.

            les UUID: LE truc débile .... à l'heure ou on utilise un DNS pour ne pas avoir à retenir une suite de chiffres et de lettres débiles, Linux a inventé un truc vachement plus simple que /dev/sdx pour nommer les périphériques.
            • [^] # Re: uuid

              Posté par . Évalué à 3.

              man e2label
              • [^] # Re: uuid

                Posté par . Évalué à 2.

                J'ai besoin d'accéder au device pas à la partition ...

                Ce ne serait pas plus simple si un periphérique donné ne changeaipt pas simplement de nom au reboot, plutot que d'ajouter des couches compliquées nécessitant de faire le travail à la main ?

                Sur d'autres OS, les hardware path ne chanent pas tous les 4 matins : il y a une logique d'attribution de noms.
                • [^] # Re: uuid

                  Posté par (page perso) . Évalué à 3.

                  Je me demande comment ils font vu que ça doit pas être facile de savoir si le disque qu'on avait branché la dernière fois va apparaître ou pas.

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                  • [^] # Re: uuid

                    Posté par . Évalué à 2.

                    Ils se basent sur la position du device sur le bus : par exemple sur matériel Sun, chaque device correspond à un chemin particulier emplacement sur la carte, No de bridge PCI, emplacement sur le bus, etc ...). Sur matériel HP tu as le hardware path qui vu de l'OS a un chemin du style /0/1/0/....../

                    Pour les disques SAN ça dépend de la baie qui est derrière, mais sur certaines baies, on peut déterminer à peu de choses près le chemin dans /dev/dsk en fonction de la façon dont le disque a été attribué sur la baie.
                    • [^] # Re: uuid

                      Posté par . Évalué à 2.

                      Un peu comme /dev/disk/by-path, tu veux dire ?
                      • [^] # Re: uuid

                        Posté par . Évalué à 2.

                        Peut-être, je ne connais pas cette méthode d'accès aux disques. Faut que j'y jette un oeil cet apres-midi ou demain si j'ai un peu de temps.
                    • [^] # Re: uuid

                      Posté par . Évalué à 1.

                      Un peu comme /dev/disk/by-path ?
                • [^] # Re: uuid

                  Posté par . Évalué à 2.

                  ls /dev/disk/by-id/ Y a les devices et les numéros (pas uuid) des partitions.

                  Quand à savoir si ça serait plus simple, non ça n'est pas plus simple. Plus facile peut être, mais pas plus simple ;) Surtout comparé à un OS qui à besoin de maintenir une liste de matériel pour fonctionner correctement, et qui ne résiste absolument pas à un changement de matériel.
                  • [^] # Re: uuid

                    Posté par . Évalué à 1.

                    Tiens c'est amusant, j'ai des systèmes qui ont besoin de maintenir une liste de matériel mais qui cependant résistent bien à tout changement. Et ils n'ont pas les noms de devices qui changent tous les 4 matins ouentre chaque reboot. Curieux non ? Mais bon, certains ne voient pas que cette façon de faire est gênante pour des serveurs ayant beaucoup de disques à gérer. Mais bon ce n'est pas grave, ces serveurs continueront de fonctionner sur des OS proprios ou avec des bouts de softs proprio pour pallier ce dysfonctionnement ... Cela dit, il faut aussi relativiser, ce n'est pas parce que je ne suis pas content de ce mode de fonctionnement que je n'aime pas Linux pour ses autres qualités.
              • [^] # Re: uuid

                Posté par . Évalué à 2.

                Je ne connaissais pas cette commande, je me coucherai moins con ce soir.
                Ca serait pas mal si cette fonctionnalité était intégrée aux gestionnaires de fichiers comme sous windows.
                • [^] # Re: uuid

                  Posté par (page perso) . Évalué à 2.

                  Ça n'a pas de sens de l'intégrer au gestionnaire de fichier sous Linux. Par contre, il est intégré à gparted par exemple

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                  • [^] # Re: uuid

                    Posté par . Évalué à 2.

                    Et à Palimpset (l'outil de gnome-disk-utility).

                    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

              • [^] # Re: uuid

                Posté par . Évalué à 2.

                Quid des accès à une partition non-ext2 ? ou à un raw device pour une BDD ?
                • [^] # Re: uuid

                  Posté par . Évalué à 2.

                  > Quid des accès à une partition non-ext2 ?
                  Tu peux mettre un label sur des partitions non ext2. dosfslabel, par exemple.

                  > ou à un raw device pour une BDD ?
                  Tu utilises des règles udev pour lui donner un petit nom. Certes, c’est un peu plus compliqué que de mettre un label à une partition, mais quelqu’un qui administre une BDD qui demande à accéder direct au hardware devrait être capable de faire ça, quand même.
                  • [^] # Re: uuid

                    Posté par . Évalué à 1.

                    Certes, c’est un peu plus compliqué que de mettre un label à une partition, mais quelqu’un qui administre une BDD qui demande à accéder direct au hardware devrait être capable de faire ça, quand même.
                    Non. Soit il n'en a pas les droits, ou il ne sait pas faire ... son métier c'est DBA, pas admin système, et il n'a pas à connaitre la totalité des subtilités de chaque OS sur lesquels sa BDD tourne.
                    • [^] # Re: uuid

                      Posté par . Évalué à 5.

                      Tu chipotes : dans ce cas, il demande au sysadmin de le faire.
                      Ce que je voulais dire, c’est qu’une boîte qui fait tourner de telles bases de données doit avoir des sysadmins assez compétents pour faire man udev. Ou j’ose l’espérer, du moins.
        • [^] # Re: uuid

          Posté par (page perso) . Évalué à 4.

          Si c'est que ça _Le_ problème de Linux... on est pénard alors :D

          je ferais un patch demain et on pourra arrêter de faire des releases tous les 3mois pour corriger ou ajouter des trucs nuls de toute façon ;-)

          (ironie +++ pour ceux qui seraient un peu lent au décodage)
          • [^] # Re: uuid

            Posté par . Évalué à 1.

            Disons que quand tu as un système avec 30 disques à gérer, tu aimes bien avoir un certain ordre dedans ... J'en suis arrivé à devoir installer powerpath (outil proprio EMC) sur l'ensembe de mes serveurs Linux reliés à une baie SAN pour pouvoir m'affranchir de ce problème,
            • [^] # Re: uuid

              Posté par . Évalué à 4.

              Pourtant udev c'est gratuit, simple et ça mange pas de pain. Tu nomme tes disques comme tu veux ou tu veux et avec qui tu veux...
              • [^] # Re: uuid

                Posté par . Évalué à 4.

                Annéfé, c'est la solution !

                Pour ceux qui ne connaissent pas (dont totof apparemment), on peut avec udev créer des règles pour associer à un périphérique (détecté par son uniqueID, son chemin physique, son nom commercial, ...) un nom système (ou un lien symbolique dans /dev) permanent.

                Ceci est notamment la solution aux eth0/eth1 qui permutent au boot selon l'ordre de réponse sur le bus PCI. Il suffit de déterminer que la e1000 s'appelle toujours eth0 (ou même intel0 si tu préfères) et la 3Com eth1, et c'est réglé !

                Pour tes disques, tu peux ainsi créer une nouvelle convention de nommage parallèle à celle par défaut du noyau, qui conviendrait à d'autres besoins que /dev/disk/by-path/ et /dev/disk/by-id/ déjà mentionnés dans ce thread.
                • [^] # Re: uuid

                  Posté par . Évalué à 2.

                  Ceci est notamment la solution aux eth0/eth1 qui permutent au boot selon l'ordre de réponse sur le bus PCI. Il suffit de déterminer que la e1000 s'appelle toujours eth0 (ou même intel0 si tu préfères) et la 3Com eth1, et c'est réglé !

                  Cool, et sous Redhat par exemple, sur quoi se basent les scripts de démarrage réseau pour attribuer le nom de device ? Ca met bien en l'air l'argument selon lequel ce système résiste au changement hardware.

                  Sur d'autres OS, c'est la position du matériel sur le bus, ou la façon dont les disques ont été attribués sur la baie qui détermine le nom du device physique.
                  • [^] # Re: uuid

                    Posté par (page perso) . Évalué à 2.

                    Sur d'autres OS, c'est la position du matériel sur le bus, ou la façon dont les disques ont été attribués sur la baie qui détermine le nom du device physique.
                    En quoi c'est mieux? C'est juste différent non? Pas forcément mieux... Si tu échanges des positions tu te retrouves avec des identifiants inversés... merci le bordel dans ce cas aussi.
                    • [^] # Re: uuid

                      Posté par . Évalué à 2.

                      Sur un serveur c'est sur que l'on change les disques de place tous les jours. En tout cas je change moins souvent mes disques de place que je ne les reboot.
                • [^] # Re: uuid

                  Posté par . Évalué à 2.

                  Pour ceux qui ne connaissent pas (dont totof apparemment), on peut avec udev créer des règles pour associer à un périphérique (détecté par son uniqueID, son chemin physique, son nom commercial, ...) un nom système (ou un lien symbolique dans /dev) permanent.

                  Cool, alors si je veux devoir gérer 300 disques avec ma babasse Linux, je dois créer 300 regles UDEV pour être sur que mes disques ne seront pas renommé entre 2 redémarrages ? ya pas un raccourci possible avec UDEV ? CCe serait déjà mieux que rien.
                  • [^] # Re: uuid

                    Posté par . Évalué à 2.

                    Ça fait moult temps que j’y ai plus touché, donc je pourrais pas te donner d’exemple précis, mais dans l’idée, ta règle peut contenir des variables d’environnement définies par le noyau définissant par exemple le bus utilisé, le constructeur du matos, son identifiant, etc… Et tu peux même utiliser un script pour nommer un matériel pluggé — donc retenir et récupérer le mappage matos/nom dans une BDD, ou utiliser les infos de lspci ou de /sys, ou ce qui te chante.
                    • [^] # Re: uuid

                      Posté par . Évalué à 2.

                      donc retenir et récupérer le mappage matos/nom dans une BDD
                      GNI ?????
                      Dans le genre simple ....
                      • [^] # Re: uuid

                        Posté par . Évalué à 2.

                        1. C’est un exemple de ce que tu peux faire, pas ce que tu dois faire :)
                        2. Par BDD, j’entends "stockage persistent", donc soit un fichier texte, soit au pire une base SQLite, pas une base oracle en load balancing sur 5 serveurs juste pour ça (remarque que techniquement, même ça c’est possible…)
                  • [^] # Re: uuid

                    Posté par . Évalué à 2.

                    Bien sur que tu peux, suffit de faire la même chose que fait Debian avec les cartes réseau : quand ça en détecte une nouvelle, ça ajoute une ligne dans /etc/udev/rules.d/70-persistent-net.rules avec une règle udev qui renomme avec un numéro unique.

                    après ton numéro unique dépend de ce que tu veux.
                    • [^] # Re: uuid

                      Posté par . Évalué à 2.

                      Effectivement, ça pourrait être inéressant, sauf que ce serait mieux si c'était natif ....
                      • [^] # Re: uuid

                        Posté par . Évalué à 2.

                        Mettre quoi en natif ? c'est toi qui définit ta numérotation. C'est toi qui considère qu'il faut numéroter en fonction de la position dans la baie. udev est natif, le reste c'est de la configuration.

                        Par défaut, c'est l'UUID, c'est pouvoir retrouver les partitions en ayant changés les contrôleurs, les disques, et en ayant déplacé les partitions aux hasard sur ces disques. Ça me parait raisonnable comme configuration par défaut, sachant qu'à coté il y a by-id by-path, et que les deux approches sont forcement pas mangeables.
                        • [^] # Re: uuid

                          Posté par . Évalué à 1.

                          je suis la discussion avec intérêt mais j'achoppe sur "mangeables"... Tu veux dire mélangeables ?
                          • [^] # Re: uuid

                            Posté par . Évalué à 2.

                            Oups oui, "mélangeables". Ça m'apprendra à cliquer bêtement sur le correcteur orthographique.
                        • [^] # Re: uuid

                          Posté par . Évalué à 2.

                          Ça me parait raisonnable comme configuration par défaut,

                          Pas quand tu as 300 disques à gérer. S'il faut faire la conf de 300 disques à la main, ça devient vite pénible. L'UUID nest pas un problème en soi, ça peut servir, par contre une config par défaut avec une norme quelque part (qui serait à mon avis plus du ressort de la distrib que du kernel) pourrait être intéressant, mais là je parle un peu dans le vide car je n'ai pas eu le temps de regarder comment ça marche exactement sur Linux. Tout ce que je peux te dire, c'est que sur d'autres systèmes, l'approche par chemin hardware persistent marche plutot bien, et sur des serveurs ayant à gérer plus de 100 To, je n'ai jamais rencontré de gros inconvénients à cette approche, et j'ai vraiment du mal à voir les avantage de la méthode Linux.
                          • [^] # Re: uuid

                            Posté par (page perso) . Évalué à 2.

                            Les autres OS gèrent tellement bien les gros systèmes qu'il font à peine de la figuration dans le top 500 des super-machines...

                            Finalement, y'a pas que les inconvénients que tu y vois... Mais comme je le dis plus haut, c'est une question de point du vue. Les deux approches sont surtout 'différentes'. De là à dire que l'une est mieux que l'autre, ça dépend juste de ce que tu veux en faire et de la flexibilité que ça apporte à TA configuration.
                            • [^] # Re: uuid

                              Posté par . Évalué à 1.

                              Les autres OS gèrent tellement bien les gros systèmes qu'il font à peine de la figuration dans le top 500 des super-machines...

                              Aucun rapport : le top500 ne parle que des perfs de calcul, La geston du stockage n'a rien a voir et les OS qui gèrent le mieux leur volumétrie sont loin d'être des bêtes de courses (mainframes IBM par exemple).
                          • [^] # Re: uuid

                            Posté par . Évalué à 2.

                            Sauf que les utilisateurs avec 300 disques sont loin d'être majoritaires, et que on à déjà fait trop souvent le reproche de linux qui ne supporte pas d'être changé de place à l'époque ou c'était déjà en partie basé sur le chemin hardware.

                            L'admin ou l'utilisateur ne comprenait pas que linux ne marche plus dès que l'on changeait le disque de place, que l'on réorganise les partitions alors que windows s'en sortait bien. Surtout avec grub1 ou liloo ou en gros le système devenait complètement imbootable dans ces cas la.

                            L'approche par chemin hardware à manifestement échouée pour la plupart des utilisateurs, y compris des admins, donc c'est parfaitement normal et raisonnable de mettre les UUID par défaut, sachant que ça reste qu'une configuration par défaut, et que comme toute configuration par défaut, c'est fait pour les neuneus qui aiment bien les configurations par défaut qui marchent.
                            Devoir gérer 300 disques ça n'est pas un besoin courant, et il y a quand même by-id et by-path présent par défaut pour ceux qui sont dans ce cas.

                            Et même dans ton cas, rien que pour trouver la partition racine, je garderait quand même la méthode des UUID, parce que c'est fait pour.
                            • [^] # Re: uuid

                              Posté par . Évalué à 2.

                              L'admin ou l'utilisateur ne comprenait pas que linux ne marche plus dès que l'on changeait le disque de place, que l'on réorganise les partitions alors que windows s'en sortait bien. Surtout avec grub1 ou liloo ou en gros le système devenait complètement imbootable dans ces cas la.
                              C'est sur que sur un serveur avec 300 disques, on change de place les disques tous les jours :).

                              Plus sérieusement, je n'ai rien contre cette façon de faire pour les postes de travail bureautique. Pour le reste, c'est pas forcément la bonne façon de faire et je pense que les distribs orientées "entreprises" devraient favoriser une autre approche.

                              Devoir gérer 300 disques ça n'est pas un besoin courant, et il y a quand même by-id et by-path présent par défaut pour ceux qui sont dans ce cas.

                              300 disques, sur des serveurs d'entreprise, ce n'est pas si banal que ça .... Si tu prends des métas de 33 Gb, ça ne fait que 9 To de données,

                              Et même dans ton cas, rien que pour trouver la partition racine, je garderait quand même la méthode des UUID, parce que c'est fait pour. Bien sur, je n'ai rien contre, ce qui me gène c'est la non persistence des chemins dans /dev et le fait que l'on doit configurer UDEV pour avoir un truc persistant.
                              • [^] # Re: uuid

                                Posté par . Évalué à 2.

                                C'est comme d'habitude avec Linux : tu as le choix.

                                Quand on voit la gamme de matériel qui est prévue pour ce noyau (téléphone portable, tablettes, PC, serveur ou super ordinateur, sans compter les architectures), il y a forcément un usage pour lequel les choix ne vont plus. Mais on n'est pas bloqué pour autant, puisque Linux et Udev sont suffisamment souple pour être reconfigurés.

                                Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # forum

    Posté par . Évalué à 10.

    Bien, mais la prochaine fois que tu veux supprimer windows de ta machine demande nous avant...

    Vous voulez pas la jouer soft ? Je suis pas contraignant... vous voulez la jouer hard ? On va la jouer hard

  • # La leçon à en tirer

    Posté par . Évalué à 4.

    Les leçons que j'en tire

    Je te résume les 3 premières leçons en une seule : quand on met un système de sauvegarde en place, il faut tester au moins une fois la récupération : décider un beau matin que le disque dur est mort, et tout remettre depuis ses sauvegardes. Là on peut en tirer les leçons, réparer et ne pas être surpris le jour où, en effet, le disque sera mort...

    Et avant que qui que ce soit me le demande, je répond fièrement : non, je ne l'ai pas fait et je m'en suis mordu les doigts (vous avez vu ? j'ai pas dit "couilles") (trop tard...) et j'ai donc également appris comme ça les points faibles de mes sauvegardes.
    • [^] # Re: Laleçon àen tirer

      Posté par . Évalué à -1.

      En général, quand t'as tout qui marche, t'as pas envie de t'emmerder à perdre
      une journée pour ça.

      Y a des gens qui aiment bien passer leur temps à configurer leur machine, et y a
      ceux qui aiment bien l'utiliser.
      • [^] # Re: Laleçon àen tirer

        Posté par . Évalué à 6.

        Ben le jour ou tu perds plusieurs semaines de boulot parce que tes sauvegardes sont pourries, plus la journee (ou plus) a tout reinstaller, tu te dis que t'as bien fait de perdre ta journee a tester.
        • [^] # Re: Laleçon àen tirer

          Posté par (page perso) . Évalué à 2.

          > Ben le jour ou tu perds plusieurs semaines de boulot parce que tes sauvegardes sont pourries, plus la journee (ou plus) a tout reinstaller, tu te dis que t'as bien fait de perdre ta journee a tester.

          Ou plutôt, le jour où tu évites de perdre x semaines/journées, tu te dis que tu as bien fait de tester.

          Prochainement, je vous proposerai peut-être un commentaire constructif.

  • # On n'est pas sous Windows !

    Posté par (page perso) . Évalué à 4.

    sudo reboot
    pour prendre en compte la nouvelle table de partition.
    Je redémarre sur ma clé USB Ubuntu Rescue Remix.


    sudo sfdisk -R /dev/sda
    L'ioctl BLKRRPART n'est pas fait pour les chiens !
  • # Rien à voir ...

    Posté par . Évalué à 4.

    Juste pour remercier Alexis au passage pour l'excellente doc Debian qu'il avait initiée vers 2003 et qui m'avait permis de passer à Linux "pour de vrai" (je n'en suis toujours pas revenu :))
    • [^] # Re: Rien à voir ...

      Posté par (page perso) . Évalué à 3.

      Merci ! Content d'avoir fait un "converti" :-)
      Actuellement, c'est Tanguy Ortolo qui fait tout le travail de mise-à-jour de la doc, merci à lui également !
      • [^] # Re: Rien à voir ...

        Posté par . Évalué à 10.

        Je vois déjà le style de modification :
        $ sed -i "s/internet/web/g" *

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # sfdisk

    Posté par (page perso) . Évalué à 2.

    Pour sauvegarder une table des partition, il est plus simple d'utiliser la commande sfdisk avec l'option -d :

    # sauvegarder
    sfdisk -d /dev/hda > hda.out

    # restaurer
    sfdisk /dev/hda < hda.out
  • # pour ma part récemment j'ai utilisé ....

    Posté par . Évalué à 2.

    ultimate boot CD qui intègre la plupart des outils de diagnostic disque constructeurs, ainsi qu'une distro Linux permttant de tester/Mrécupérer les données sur un disque dur HS.

    Je ne sais pas si cette distro permet de configurer le clavier en azerty, je n'ai pas cherché. Mais ça ne me gène pas, je praiquais à une époque indiféremment le azerty et le qwerty.

    http://www.ultimatebootcd.com/
  • # Moralité

    Posté par . Évalué à 6.

    Il faut toujours avoir une Windows en début de partition quand on bidouille avec dd :)
    • [^] # Re: Moralité

      Posté par . Évalué à 1.

      Bah, windows ou linux c'est pareil, le principal est d'avoir le systeme au début du disque et les données à la fin. Tiens d'ailleurs, ca serait bien ça : un FS qui alloue les blocs en fin de disqe et qui remonte au fur et a mesure vers le début .... :)
      • [^] # Re: Moralité

        Posté par . Évalué à 3.

        Sauf que, sur les disques magnétiques, la partie la plus rapide se trouve en début de disque.
        • [^] # Re: Moralité

          Posté par . Évalué à 2.

          Pourquoi ?
          • [^] # Re: Moralité

            Posté par . Évalué à 2.

            Je suppose que la densité d'information (au sens de la quantité d'information par unité de surface) est à peu près constante sur toute la surface du disque, à l'ère moderne (pour pas gâcher). Je suppose également que la vitesse de rotation des plateaux est une constante en fonctionnement (hors ralentissement pour l'économie d'énergie sur les disques modernes). Ainsi, la quantité d'information lisible par unité de temps est plus grande sur les cylindres de diamètre supérieur (angle balayé identique quelque soit le diamètre, mais distance parcouru par la tête de lecture supérieure à diamètre supérieur). Je suppose que, comme pour un CD/DVD, le début de l'espace de stockage est à la périphérie.

            Si je suppose bien, mettre le système au début du disque garantit un débit maximal.
            • [^] # Re: Moralité

              Posté par . Évalué à 2.

              Je suppose que la densité d'information (au sens de la quantité d'information par unité de surface) est à peu près constante sur toute la surface du disque, à l'ère moderne (pour pas gâcher).
              C'est ce que je me souviens avoir lu.
              Je suppose également que la vitesse de rotation des plateaux est une constante en fonctionnement (hors ralentissement pour l'économie d'énergie sur les disques modernes).
              Oui.
              Je suppose que, comme pour un CD/DVD, le début de l'espace de stockage est à la périphérie.

              Ca par contre je n'en sais rien : avec les disques modernes, je me demande si la "vue" que l'on a de l'attribution de la volumétrie sur le disque est bien réelle. Mais si ma mémoire est bonne, il y a un temps, l'attribution des cylindres se faisait du centre vers la périphérie (a moins que je ne me trompe). Et j'ai toujours cru que le début de l'espace de stockage d'un CD/DVD se faisait au centre, et non à la périphérie.
              • [^] # Re: Moralité

                Posté par . Évalué à -2.

                Et j'ai toujours cru que le début de l'espace de stockage d'un CD/DVD se faisait au centre, et non à la périphérie.
                Tu as mal cru... T'es cuit. Grave un CD avec 1 Mo de données, regarde-le bien, tu verras : c'est à la périphérie.
                • [^] # Re: Moralité

                  Posté par . Évalué à 7.

                  Non. Tous les média optiques commencent à l'intérieur, qu'il s'agisse de CD, DVD, ou BD. C'est notamment une des raisons pour lesquelles certains Blu-ray de jeux pour PlayStation 3 contiennent nombre de données en double.
                  Par contre, les DVD spécifiques à la Wii sont gravés depuis l'extérieur, si je ne m'abuse.
                  • [^] # Re: Moralité

                    Posté par . Évalué à 0.

                    Avec un tel score pour ton commentaire, ça m'a collé un doute :-)
                    Bon, après moultes observations sur des CD-R et CD-R/W, j'observe que c'est en périphérie sur les seconds, et au centre sur les premiers. C'est comme ça chez moi...
                    • [^] # Re: Moralité

                      Posté par . Évalué à 1.

                      Ça fait un bout de temps que je n'ai pas utilisé de média réinscriptibles, mais je suis quasiment certain que la gravure se fait aussi du centre vers la périphérie...
                      • [^] # Re: Moralité

                        Posté par . Évalué à 0.

                        Que d'autres témoins témoignent...
                        Pour ma part, ta quasi certitude ne vaut rien au regard des mes observations réitérées tout exprès pour participer intelligemment à cet échange.
                        A propos d'intelligence, je serais curieux de connaitre le login des puissants moinseurs qui jouent à "inutiler" mes commentaires injurieux, certes, mais quand même... Merde...
                        • [^] # Re: Moralité

                          Posté par . Évalué à 2.

                          J'ai jamais vu de disques grave de l’extérieur vers le centre. J'ai fait quelques recherche sur le ouaib et il semble que tout se fait du centre vers l’extérieur

                          http://www.lagravuredecd.com/cdrfaq2.php#[2-1]
                          http://www.osta.org/technology/cdqa2.htm

                          si j'avais accès au Orange Book je pourrais te donner une réponse définitive mais comme c'est des rats chez Philips..
                          • [^] # Re: Moralité

                            Posté par . Évalué à 2.

                            Snif, je serais seul dans mon coin (pan!) à vivre ça ?
                            De l'extérieur vers l'intérieur... Et je ne parle pas d'autre chose...

                            Grumpf, je dois me résoudre à douter de ce que j'ai observé. La force de l'internet...
                            Je n'ai pas de CR-R/W vierge sous la main pour tester, je fais mienne ta conclusion (ainsi que celle qui suit).

                            Pardon aux moules blessées de mon témoignage semble-t-il erroné.
                        • [^] # Re: Moralité

                          Posté par . Évalué à 2.

                          Je témoigne que j'ai toujours vu mes cds gravés à partir du centre. Constatation visuelle. 2 contre 1 au moins :)
                  • [^] # Re: Moralité

                    Posté par . Évalué à -1.

                    pour la PS3, quel rapport entre le début des données au centre des Blu-ray de jeux et de nombreuses données présentes en double, comme tu le déclares ? Je vois pas.
                    • [^] # Re: Moralité

                      Posté par . Évalué à 1.

                      La copie des données sera plus proche de la périphérie du disque, permettant de réduire le temps d'accès et d'avoir un meilleur débit.
                      • [^] # Re: Moralité

                        Posté par . Évalué à 1.

                        Ne suffit-il pas, pour garantir un bon débit aux données qui le nécessitent, de les disposer à la périphérie du disque, tout simplement ?
                        Ou bien est-ce parce que, même lors de la lecture de quelques séquences vers le centre, il faut encore disposer sans délai de données spécifiques à accès impérativement rapide (ces données déjà disposées en périphérie, ainsi redondantes) ?
                        Mais quid de l'utilité du cache en mémoire vive ou d'une programmation efficace qui laisse en mémoire vive le code ou les données qui nécessitent une exécution rapide ?

                        Bref, j'ai toujours pas saisi.
                        Au fait, merci de répondre :-) Tant qu'on peut encore échanger, même si je suis moinsé, c'est déjà bien.

Suivre le flux des commentaires

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