Re: URGENT : copie d un superbloc + lilo
Stephane Durieux a écrit, jeudi 25 janvier 2007, à 18:55 :
>
> Bonjour
Bonsoir.
> Je voudrait connaitre une commande ou plutot la procedure pour copier
> le super bloc d un pc a un autre.
Si le « super bloc » est le MBR (1er secteur) du disque dur, la commande
dd if=/dev/sda of=/root/MBR_sda bs=512 count=1
va le récupérer dans le fichier MBR_sda, de 512 octets ; la manoeuvre
inverse, en échangeant of et if, le restaurera (mais là un simple cat
fait aussi l'affaire).
Pour le premier bloc de sda6, même commande mutatis mutandis...
Depuis un CD boutable sur la cible, on pourrait faire (sans filet)
ssh root@source dd if=/dev/sda6 bs=512 count=1 >/dev/sda6
(la redirection de sortie a lieu dans le shell de la cible), mais il est
sans doute plus prudent de passer par un fichier intermédiaire.
> Mon probleme est le suivant : J ai essaye de cloner (via
> ghostcastserver :( ) un poste avec une partition windows et deux linux
> (mandrake et debian).
> Afin de demarrer la deuxieme distrib linux j ai donc du faire du
> "chainloading".
... donc en installant un second LILO au début de sda6 ?
> Le probleme est que notre cher ami ghost s est un peu perdu les
> pedales dans cette operation (pas que lui d ailleurs).
> La partition windows et la premiere linux aucun probleme
Bon, c'est déjà ça... la mdra^Hiva peut remplacer un CD boutable.
> La partition concernee par le chainloading : probleme
> Apres avoir refait un lilo (je sais grub c est mieux)
oui, il permettrait d'éviter ce chainloading.
> et redemarre, le systeme boote mais me signale un probleme de
> coherence sur le systeme de fichier, passe en mode restauration.
Heu, quelle est la séquence de boot exacte ?
> La je lance le fsck sur un poste mais toute la table des inodes y passe ou presque
>
>
> J ai l impression que le decalage (que je presume) introduit par lilo
> (512 octets) a comme qui dirait poser probleme.
LILO écrase le premier secteur, mais ne décale rien ! Il peut aussi y
avoir une confusion, la numérotation des secteurs part de zéro, en
général, et pas de un. Ou Ghost a foiré...
> Je pensais donc recuper lilo et tout le superbloc present sur la
> machine modele pour l injecter sur un autre poste.
>
> Pour copier lilo ok mais ou commence le superbloc?
Attention, LILO dépend de la place physique des fichiers sur le disque,
seule la copie brute par dd la respecte. Il faut donc que sda6 soit
copié exactement au même endroit...
> J ai effectue un dumpe2fs | less
>
> Filesystem state: clean
[...]
> First block: 0
> Block size: 4096
[...]
> d autre part une fsck me donne pour /dev/sda6 la partition en question :
> Disk /dev/sda: 160.0 GB, 160000000000 bytes
> 255 heads, 63 sectors/track, 19452 cylinders, total 312500000 sectors
> Units = sectors of 1 * 512 = 512 bytes
>
> Device Boot Start End Blocks Id System
> /dev/sda1 63 4192964 2096451 de Dell Utility
> /dev/sda2 * 4192965 176506154 86156595 7 HPFS/NTFS
> /dev/sda3 222307470 312496379 45094455 83 Linux
> /dev/sda4 176506155 222307469 22900657+ f W95 Ext'd (LBA)
> /dev/sda5 176506218 180586664 2040223+ 82 Linux swap / Solaris
> /dev/sda6 180586728 219656744 19535008+ 83 Linux
> /dev/sda7 219656808 222307469 1325331 82 Linux swap / Solaris
>
> Lilo est situe au bloc 180586728
Attention, il y a
- LILO (le bouteur, sur le premier secteur de sda, ou sda6) ;
- /sbin/lilo, l'installeur de LILO.
> mais le superbloc est il juste derriere ?
Non, LILO occupe les 446 premiers octets du premier bloc du disque ou de
la partition d'installation. Les 66 autres contiennent la table des
partitions principales et deux octets « magiques » de contrôle.
> La taille des blocs est bien de 4096 octets ?
Non, ça c'est la taille des blocs alloués dans le « file system » ext2.
Les blocks ci-dessus font 1024 octets (cf. la taille de sda1 en blocks,
correspondant au nombre double de secteurs de 512 octets)
> il me suffirait alors de copier 32768*4096 octets alors pour avoir tout le superbloc ?
Non, c'est beaucoup trop ;)
> Merci de votre aide !!!!
>
> Sinon une copie bloc par bloc via ghost de 65G linux m attend !
Si ces 65G ne sont pas bien remplis, c'est du gâchis de bande passante.
Il peut être plus rapide de copier le contenu (mais les fichiers ne
seront plus au même endroit sur le disque).
--
Jacques L'helgoualc'h
Reply to: