# système cloné ne démarre pas: grub ou fstab ? **URL:** \ **Category:** Support Debian\ **Created:** [Février 21, 2016, 1:37 UTC](https://www.debian-fr.org/t/systeme-clone-ne-demarre-pas-grub-ou-fstab/55407 "2016-02-21T13:37:30Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![hybridemoineau](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/h/e9bcb4/32.png) [@hybridemoineau](https://www.debian-fr.org/u/hybridemoineau)\ **Post date:** [Février 21, 2016, 1:37 UTC](https://www.debian-fr.org/t/systeme-clone-ne-demarre-pas-grub-ou-fstab/55407/1 "2016-02-21T13:37:30Z")
Salut à tous, Bon, je m’arrache les cheveux pour démarrer sur un clone de mon système, situé sur un deuxième disque dur du même pc: le démarrage plante avec un “loading files system”, première ligne qui s’affiche après grub-pc, après laquelle rien ne se passe. Je soupçonne grub ou le fstab du système cloné. Voici le problème. Deux disques durs, 3 partitions chacun, sda correspond au disque système (sda1), au home (sda3) et à un swap (sda2), sdb à une partition de sauvegarde (sdb2), à une partition vierge (sdb1), et à un swap (sdb3). Voici les manips que j’ai faites: - Formater la partition de sauvegarde (sdb1) - copier la partition système (ici sda1 sur sdb1) dd if=/dev/sda1 of=/dev/sdb1 bs=4096 conv=notrunc,noerror - installer l’uuid - générer un uuid uuid -m - modifier l’uuid de la partition où se trouve la sauvegarde tune2fs -U b0830d24-237a-11e2-ae43-b7d3103e96ae /dev/sdb1 - monter la partition où se trouve la sauvegarde - modifier le fstab de la partition où se trouve la sauvegarde, pour qu’elle soit root, si elle est lancée - update-grub Jusque là, tout va bien: la sauvegarde du système est reconnue comme système à part entière, et un update-grub me renvoie: `# update-grub Generating grub.cfg ... Found linux image: /boot/vmlinuz-3.2.0-3-amd64 Found initrd image: /boot/initrd.img-3.2.0-3-amd64 Found Debian GNU/Linux (6.0.6) on /dev/sdb1` Problème: si je démarre sur la dernière entrée, ça plante; et surtout grub.cfg me balance 5 entrées (Deux pour le système, deux pour la sauvegarde, et une encore pour la sauvegarde) et non pas trois…Je ne comprends pas ce décalage, et la cinquième entrée qui délire sec. Premier suspect, grub. J’ai effacé tous les fichiers de config de grub en plus de le désinstaller, puis ai tout réinstallé. Pour rappel l’UUID du système d’origine est "cfe9d3a4-2362-11e2-a4c3-13e73b1b7ad5" l’UUID de la sauvegarde est "b0830d24-237a-11e2-ae43-b7d3103e96ae" Et voici grub.cfg (j’ai graissé les parties qui concernent le lancement du système clone, et graissé-souligné l’entrée délirante) [quote]# grub-mkconfig Generating grub.cfg … … insmod part\_msdos insmod ext2 set root=’(hd0,msdos1)‘ search --no-floppy --fs-uuid --set cfe9d3a4-2362-11e2-a4c3-13e73b1b7ad5 if loadfont /usr/share/grub/unicode.pf2 ; then set gfxmode=640x480 load\_video insmod gfxterm fi terminal\_output gfxterm insmod part\_msdos insmod ext2 set root=’(hd0,msdos1)' search --no-floppy --fs-uuid --set cfe9d3a4-2362-11e2-a4c3-13e73b1b7ad5 set locale\_dir=($root)/boot/grub/locale set lang=fr insmod gettext set timeout=5 ### END /etc/grub.d/00\_header … ### BEGIN /etc/grub.d/10\_linux Found linux image: /boot/vmlinuz-3.2.0-3-amd64 Found initrd image: /boot/initrd.img-3.2.0-3-amd64 menuentry ‘Debian GNU/Linux, avec Linux 3.2.0-3-amd64’ --class debian --class gnu-linux --class gnu --class os { insmod part\_msdos insmod ext2 set root=’(hd0,msdos1)' search --no-floppy --fs-uuid --set cfe9d3a4-2362-11e2-a4c3-13e73b1b7ad5 echo 'Chargement de Linux 3.2.0-3-amd64 …' linux /boot/vmlinuz-3.2.0-3-amd64 root=UUID=cfe9d3a4-2362-11e2-a4c3-13e73b1b7ad5 ro quiet echo 'Chargement du disque mémoire initial …‘ initrd /boot/initrd.img-3.2.0-3-amd64 } menuentry ‘Debian GNU/Linux, avec Linux 3.2.0-3-amd64 (mode de dépannage)’ --class debian --class gnu-linux --class gnu --class os { insmod part\_msdos insmod ext2 set root=’(hd0,msdos1)' search --no-floppy --fs-uuid --set cfe9d3a4-2362-11e2-a4c3-13e73b1b7ad5 echo 'Chargement de Linux 3.2.0-3-amd64 …' linux /boot/vmlinuz-3.2.0-3-amd64 root=UUID=cfe9d3a4-2362-11e2-a4c3-13e73b1b7ad5 ro single echo 'Chargement du disque mémoire initial …' initrd /boot/initrd.img-3.2.0-3-amd64 } ### END /etc/grub.d/10\_linux ### BEGIN /etc/grub.d/20\_linux\_xen ### END /etc/grub.d/20\_linux\_xen ### BEGIN /etc/grub.d/30\_os-prober ### Found Debian GNU/Linux (6.0.6) on /dev/sdb1 menuentry “Debian GNU/Linux, avec Linux 3.2.0-3-amd64 (on /dev/sdb1)” { insmod part\_msdos insmod ext2 set root=’(hd1,msdos1)‘ search --no-floppy --fs-uuid --set b0830d24-237a-11e2-ae43-b7d3103e96ae linux /boot/vmlinuz-3.2.0-3-amd64 root=UUID=b0830d24-237a-11e2-ae43-b7d3103e96ae ro quiet initrd /boot/initrd.img-3.2.0-3-amd64 } menuentry “Debian GNU/Linux, avec Linux 3.2.0-3-amd64 (mode de dépannage) (on /dev/sdb1)” { insmod part\_msdos insmod ext2 set root=’(hd1,msdos1)' search --no-floppy --fs-uuid --set b0830d24-237a-11e2-ae43-b7d3103e96ae linux /boot/vmlinuz-3.2.0-3-amd64 root=UUID=b0830d24-237a-11e2-ae43-b7d3103e96ae ro single initrd /boot/initrd.img-3.2.0-3-amd64 } menuentry “Debian GNU/Linux (6.0.6) (on /dev/sdb1)” { insmod part\_msdos insmod ext2 set root=’(hd1,msdos1)' search --no-floppy --fs-uuid --set b0830d24-237a-11e2-ae43-b7d3103e96ae linux /boot/vmlinuz-3.2.0-3-amd64 root=UUID=58bda17e-236d-11e2-b567-176659fd103d ro quiet initrd /boot/initrd.img-3.2.0-3-amd64 } … done [/quote] Une idée pour modifier ce truc, au moins la cinquième entrée ? Si vous me dites que ça ne vient pas de grub, je veux bien le croire. Deuxième suspect alors, le fstab du système cloné que voici: [code]# systeme cloné de secours dans UUID=b0830d24-237a-11e2-ae43-b7d3103e96ae / ext3 errors=remount-ro 0 1 # /home /dev/sda3 UUID=07711869-d45f-4d92-8f2b-61d1308271c8 /home ext3 defaults,user\_xattr 0 2 # swap /dev/sdb3 UUID=16f4ca5f-9b91-4168-81e9-ef8b7bc582d1 none swap sw 0 0 # swap /dev/sda2 UUID=9fc8d544-fda9-4a81-a0f9-f0f320c42d85 none swap sw 0 0 /dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0 #zik dev/sdb2 ou /mnt/ddkiz UUID=9aba2077-b7af-4178-9b16-e80c2008ba02 /mnt/ddkiz ext3 defaults 0 0 #systeme d’origine dans UUID=cfe9d3a4-2362-11e2-a4c3-13e73b1b7ad5 /mnt/syskc ext3 defaults 0 0 [/code] Merci pour votre aide, j’ai passé un temps fou là dessus, j’aurais eu le temps de faire 4 installations… ---
**Author:** ![anonyme2](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f08c70/32.png) [@anonyme2](https://www.debian-fr.org/u/anonyme2)\ **Post date:** [Février 21, 2016, 1:37 UTC](https://www.debian-fr.org/t/systeme-clone-ne-demarre-pas-grub-ou-fstab/55407/2 "2016-02-21T13:37:31Z")
si le but de ta manoeuvre est de faire une sauvegarde de tout ton système alors clone tout le disque sda sur une partition de sdb avec clonezilla,ça sera beaucoup plus simple. Il aurait été utile de donner la sortie de ```auto ``` pour plus de clarté. ---
**Author:** ![hybridemoineau](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/h/e9bcb4/32.png) [@hybridemoineau](https://www.debian-fr.org/u/hybridemoineau)\ **Post date:** [Février 21, 2016, 1:37 UTC](https://www.debian-fr.org/t/systeme-clone-ne-demarre-pas-grub-ou-fstab/55407/3 "2016-02-21T13:37:31Z")
Voici ce que donne fdisk -l [code]fdisk -l Disk /dev/sda: 160.0 GB, 160041885696 bytes 255 heads, 63 sectors/track, 19457 cylinders Units = cylinders of 16065 \* 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00006f8c Device Boot Start End Blocks Id System /dev/sda1 \* 1 1912 15358108+ 83 Linux /dev/sda2 1913 2103 1534207+ 82 Linux swap / Solaris /dev/sda3 2104 19457 139396005 83 Linux Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders Units = cylinders of 16065 \* 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000f0471 Device Boot Start End Blocks Id System /dev/sdb1 1 2550 20478976 83 Linux /dev/sdb2 2678 121602 955257856 83 Linux /dev/sdb3 2550 2678 1024000 82 Linux swap / Solaris Partition table entries are not in disk order [/code] La table des partitions et l’ordre des partitions sur le disque ne correspondent pas. Ca pourrait être dû à ça (?). Je précise que la copie avec dd s’était bien passée. Les partitions n’étaient pas de la même taille, et je viens de remettre la partition de sauvegarde à la bonne taille avec ```auto ``` (aucune erreur) et `resize2fs /dev/sdb1` Ca n’a rien changé. Qu’est ce qui ne marche pas ? Je fais déjà des sauvegardes de mes données avec rsync, mon but là est de garder un système de secours, sans y toucher, sauf MAJ intermédiaires (6.0.1,2,etc) (j’ai eu un plantage court, reparti comme il était venu la semaine dernière, mais à l’idée de me retaper tous les fichiers de config pour une réinstallation, j’ai verdi…). ---
**Author:** ![fran.b](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/f/d78d45/32.png) [@fran.b](https://www.debian-fr.org/u/fran.b)\ **Post date:** [Février 21, 2016, 1:37 UTC](https://www.debian-fr.org/t/systeme-clone-ne-demarre-pas-grub-ou-fstab/55407/4 "2016-02-21T13:37:34Z")
As tu fait un install grub pour qu’il sache où trouver ne serait ce que le grub.cfg? update-grub ne fait que modifier ce dernier, grub-install installe le nécessaire pour sa ecture, fais install-grub sur ton disque (/dev/sd?) ---
**Author:** ![etxeberrizahar](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/e/43a26b/32.png) [@etxeberrizahar](https://www.debian-fr.org/u/etxeberrizahar)\ **Post date:** [Février 21, 2016, 1:37 UTC](https://www.debian-fr.org/t/systeme-clone-ne-demarre-pas-grub-ou-fstab/55407/5 "2016-02-21T13:37:34Z")
```auto } menuentry "Debian GNU/Linux (6.0.6) (on /dev/sdb1)" { insmod part_msdos insmod ext2 set root='(hd1,msdos1)' search --no-floppy --fs-uuid --set b0830d24-237a-11e2-ae43-b7d3103e96ae linux /boot/vmlinuz-3.2.0-3-amd64 root=UUID=58bda17e-236d-11e2-b567-176659fd103d ro quiet initrd /boot/initrd.img-3.2.0-3-amd64 } ``` set root=’(hd1,msdos1)'deuxième disque, première partition=/dev/sdb1 L’UUID b0830d24-237a-11e2-ae43-b7d3103e96ae. Qu’en est-il de UUID=58bda17e-236d-11e2-b567-176659fd103d ? La partition UUID=58bda17e-236d-11e2-b567-176659fd103d existe-t-elle ? $ ls -l /dev/disk/by-uuid Ne serait-ce pas une clé usb branchée lors de la mise à jour de grub ? Quel est son contenu ? /boot ? root=UUID=58bda17e-236d-11e2-b567-176659fd103d Pour effacer cette entrée, tu désactives 30\_os\_prober, tu complémentes 40\_custom avec ces entrées des liens /vmlinuz et /initrd.img sans versions avec UUID=b0830d24-237a-11e2-ae43-b7d3103e96a ```auto menuentry "Debian GNU/Linux, /vmlinuz (on /dev/sdb1)" { insmod part_msdos insmod ext2 set root='(hd1,msdos1)' search --no-floppy --fs-uuid --set b0830d24-237a-11e2-ae43-b7d3103e96ae linux /vmlinuz root=UUID=b0830d24-237a-11e2-ae43-b7d3103e96ae ro quiet initrd /initrd.img } menuentry "Debian GNU/Linux, /vmlinuz (mode de dépannage) (on /dev/sdb1)" { insmod part_msdos insmod ext2 set root='(hd1,msdos1)' search --no-floppy --fs-uuid --set b0830d24-237a-11e2-ae43-b7d3103e96ae linux /vmlinuz root=UUID=b0830d24-237a-11e2-ae43-b7d3103e96ae ro single initrd /initrd.img } ``` Puis tu remets grub à jour. Tu t’appuyes sur le grub de /dev/sda pour démarrer /dev/sdb. Si /dev/sdb se trouvait sans /dev/sda, il ne pourrait se démarrer sans son propre grub. Installe-le aussi sur le MBR de /dev/sdb et revois ses réglages (chroot, dpkg-reconfigure grub-pc…). ---
**Author:** ![hybridemoineau](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/h/e9bcb4/32.png) [@hybridemoineau](https://www.debian-fr.org/u/hybridemoineau)\ **Post date:** [Février 21, 2016, 1:37 UTC](https://www.debian-fr.org/t/systeme-clone-ne-demarre-pas-grub-ou-fstab/55407/6 "2016-02-21T13:37:38Z")
Merci pour votre aide, le problème se précise, mais ne se résoud pas. Ca semble être une question de montage des disques durs dans le bios, ou de réglage du démarrage du noyau, mais ce n’est pas clair. Pour en avoir le coeur net, j’ai refait toutes les manips, désactivé os-prober et modifié le fichier custom dans grub.d. J’ai aussi refait une install de grub sur /dev/sdb, via un chroot… Et j’ai eu l’idée de démarrer en mode sans échec en changeant l’ordre du boot des disques durs dans le bios… Ce que ça donne: - il y a bien deux grubs distincts d’installés sur sda (système d’origine) et sdb (cloné), et celui installé sur le disque du système cloné pointe bien automatiquement vers ce système cloné - en mode sans échec, si j’essaie de démarrer le système cloné, à partir du grub de sda ou du grub de sdb, il ne trouve jamais le “root files system”. C’est là qu’il plante en réalité, il ne trouve pas l’UUID du système cloné, qu’il attend comme Godot - j’ai tenté sur les entrées des deux grub de modifier la ligne “set root=’(hd1,msdos1)”, à cause du résultat bizarre de fdisk -l, en essayant toutes les combinaisons (hd1, msdos2 ou 3 ou hd0,msdos 1 ou 2 ou 3). Que dalle. Et pour cause, mais je ne comprends pas. J’ai deux disques durs, un vieux IDE monté en master (sda, le système d’origine, 160GB), et un SATA (sdb, le clone, 1TO). Mais que je démarre sur l’un ou sur l’autre, les messages concernent toujours sda: il détecte sad1,2 et 3. Ce n’est pas un problème de rang, qui ferait que sda désignerait tantôt l’IDE, tantôt le SATA, car il m’affiche toujours une info sur la capacité du disque, “retaillée” de 150 à 160GB, soit toujours la taille de l’IDE. C’est normal qu’il ne trouve pas le système de fichier de root du système cloné qui se trouve sur le SATA s’il pense toujours démarrer sur l’IDE… D’où, est ce que c’est un problème de BIOS et de montage des disques ? peut être, car si je peux choisir sur lequel booter dans le BIOS, les activer l’un, l’autre ou les deux, je ne peux pas les mettre tous les deux dans l’ordre de boot: soit l’un, soit l’autre. Mais pourquoi est ce que quand je désactive l’IDE et met le SATA au démarrage, me sort t-il dans les messages de démarrage des infos sur l’IDE ?? Ca pourrait venir du lancement du noyeau ? Je peux modifier ça avec un chroot ? J’espère avoir été clair… Je peux cloner autant de systèmes que je veux, si ça boote pas… ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Février 21, 2016, 1:37 UTC](https://www.debian-fr.org/t/systeme-clone-ne-demarre-pas-grub-ou-fstab/55407/7 "2016-02-21T13:37:39Z")
> [@](#): > > en mode sans échec, si j’essaie de démarrer le système cloné, à partir du grub de sda ou du grub de sdb, il ne trouve jamais le “root files system” Ce n’est pas clair. Quel “root file system” ? L’initial (initrd, initramfs) ? Qui est “il” ? Grub, le script de démarrage de l’initramfs ? Le noyau démarre ou non ? Tu te retrouves dans le shell de secours de l’initramfs ou non ? Quel est le message d’erreur _exact et complet_ ? ---
**Author:** ![hybridemoineau](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/h/e9bcb4/32.png) [@hybridemoineau](https://www.debian-fr.org/u/hybridemoineau)\ **Post date:** [Février 21, 2016, 1:37 UTC](https://www.debian-fr.org/t/systeme-clone-ne-demarre-pas-grub-ou-fstab/55407/8 "2016-02-21T13:37:41Z")
Le message d’erreur était “waiting for root file system”, après grub dans le script de démarrage de l’initramfs sans doute, et j’avais bien accès au shell de l’initramfs à la fin. Etait, car: Le système d’origine (sans doute le disque dur) a définitivement lâché de toutes façons - le bug d’hier s’est répété, je vais ouvrir un autre post à ce sujet… Et j’ai effectivement pu lancer son clone (heureusement…)en enlevant avec un cd de secours les anciens noyaux, en les réinstallant à partir du système cloné, et en mettant grub à jour. Aux grands maux… Il semble bien que c’était dû au lancement des noyaux (init ?), qui se faisait toujours vers le système d’origine et non pas le système cloné. Je ne sais pas pourquoi - cette méthode de clonage n’est peut être pas bonne, je n’avais peut être pas installé les headers. Je ne mets pas en résolu, car je ne suis sûr de rien, mais de fait, après réinstallation des noyaux via le système cloné, ça marche. ---
**Author:** ![fran.b](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/f/d78d45/32.png) [@fran.b](https://www.debian-fr.org/u/fran.b)\ **Post date:** [Février 21, 2016, 1:37 UTC](https://www.debian-fr.org/t/systeme-clone-ne-demarre-pas-grub-ou-fstab/55407/9 "2016-02-21T13:37:41Z")
Ce qu’a dit etxeberrizahar aurait du marcher, quand tu lances grub, les lignes `search --no-floppy --fs-uuid --set xxxxxxxxxx linux /boot/vmlinuz-3.2.0-3-amd64 root=UUID=b0830d24-237a-11e2-ae43-b7d3103e96ae ro quiet ` disent de chercher sur la partition xxxxx le noyau et de la démarrer avec la racine dcorrespondant à la partition b0830d24-237a-11e2-ae43-b7d3103e96ae. Visiblement il y avait une incohérence que etxeberrizahar a remarqué. Le message que tu as obtenu dit que le noyau a été trouvé et est en attente de la racine, en clair il cherche la partition indiqué par root= et ne la trouve pas. Cela peut signifier que ton intramfs est bancal (je ne m’explique pas trop pourquoi) et ne voit pas la partition (sinon il t’aurait fait un panic plus rapide). J’ai du mal à comprendre pourquoi, peut être que l’UUID joue un rôle dans l’initrd dans le boute standrad mais j’ai du mal à y croire. En tout cas le message indique que c’est au niveau de l’initramfs que ça coince et parce qu’il n’arrive pas à voir la partition. Dans tes manoeuvres, as tu refait l’initramfs comme je le pense? ---
**Author:** ![hybridemoineau](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/h/e9bcb4/32.png) [@hybridemoineau](https://www.debian-fr.org/u/hybridemoineau)\ **Post date:** [Février 21, 2016, 1:37 UTC](https://www.debian-fr.org/t/systeme-clone-ne-demarre-pas-grub-ou-fstab/55407/10 "2016-02-21T13:37:42Z")
> [@](#): > > Dans tes manoeuvres, as tu refait l’initramfs comme je le pense? J’ai réinstallé le noyau 3.2 après l’avoir purgé, avec les headers et dkms, alors je crois que oui, l’initramfs a dû être refaite automatiquement. ---
**Author:** ![fran.b](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/f/d78d45/32.png) [@fran.b](https://www.debian-fr.org/u/fran.b)\ **Post date:** [Février 21, 2016, 1:37 UTC](https://www.debian-fr.org/t/systeme-clone-ne-demarre-pas-grub-ou-fstab/55407/11 "2016-02-21T13:37:42Z")
Hum, pas de trace d’uuid dans l’initrd, bizarre… ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Février 21, 2016, 1:37 UTC](https://www.debian-fr.org/t/systeme-clone-ne-demarre-pas-grub-ou-fstab/55407/12 "2016-02-21T13:37:43Z")
> [@](#): > > Hum, pas de trace d’uuid dans l’initrd En effet, à moins que ça ait changé l’initramfs sauce Debian utilise le paramètre root= de la ligne de commande du noyau pour définir la racine finale à monter. Peut-être le module pilote du contrôleur SATA qui manquait dans l’initramfs s’il a été construit avec l’option modules=dep… En tout cas grub est hors de cause, à ce stade il a fini son boulot. ---
**Author:** ![fran.b](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/f/d78d45/32.png) [@fran.b](https://www.debian-fr.org/u/fran.b)\ **Post date:** [Février 21, 2016, 1:37 UTC](https://www.debian-fr.org/t/systeme-clone-ne-demarre-pas-grub-ou-fstab/55407/13 "2016-02-21T13:37:44Z")
Tu as raison, je crois me souvenir d’un passage IDE -\> SATA, donc les modules nécessaires pour installer la racine n’ont pas du être mis dans l’initramfs (il me semblait pourtant qu’il mettait le paquet par défaut mais passons…). Ce serait une explication valable à ce problème. ---
**Author:** ![flash100](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/f/c37758/32.png) [@flash100](https://www.debian-fr.org/u/flash100)\ **Post date:** [Février 21, 2016, 1:37 UTC](https://www.debian-fr.org/t/systeme-clone-ne-demarre-pas-grub-ou-fstab/55407/14 "2016-02-21T13:37:44Z")
Vue le résultat “incohérent” de ton fdisk ne pourrait t-il pas s’agir d’un problème de configuration raid(1) … voire éventuellement ton bios … ---
**Author:** ![hybridemoineau](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/h/e9bcb4/32.png) [@hybridemoineau](https://www.debian-fr.org/u/hybridemoineau)\ **Post date:** [Février 21, 2016, 1:37 UTC](https://www.debian-fr.org/t/systeme-clone-ne-demarre-pas-grub-ou-fstab/55407/15 "2016-02-21T13:37:44Z")
Pour info, les deux systèmes fonctionnent maintenant (le système d’origine sur sda1 est reparti, je fais des tests pour comprendre le plantage), avec deux grubs distincts sur sda et sdb, d’où se lancent indifféremment les systèmes qui sont sur sda1 et sdb1. Je n’ai fait que partir de sdb1 à partir d’un cd de secours, retirer le noyau de sdb1 (le clone), le réinstaller, et laisser grub se configurer automatiquement. Rien n’a été modifié dans le noyau ou le grub de sda1 (l’origine). Si c’est un problème de module, je serai curieux de savoir lequel… ---
**Author:** ![fran.b](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/f/d78d45/32.png) [@fran.b](https://www.debian-fr.org/u/fran.b)\ **Post date:** [Février 21, 2016, 1:37 UTC](https://www.debian-fr.org/t/systeme-clone-ne-demarre-pas-grub-ou-fstab/55407/16 "2016-02-21T13:37:44Z")
Plus j’y pense et plus pour moi l’erreur vient du fait que le module nécessaire à la gestion du SATA ne devait pas être dans l’initrd parce qu’inutile à l’époque où tu avais fait ton installation. Du coup le noyau lancé, il attendait l’apparition d’une partition susceptible d’être la racine. La réinstallation du noyau a farcé la reconstruction de cet initrd et ça a débloqué les choses. Mais c’est juste un raisonnement. ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Février 21, 2016, 1:37 UTC](https://www.debian-fr.org/t/systeme-clone-ne-demarre-pas-grub-ou-fstab/55407/17 "2016-02-21T13:37:45Z")
Tu peux comparer les modules inclus dans les deux initramfs. ```auto ``` ---
**Author:** ![hybridemoineau](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/h/e9bcb4/32.png) [@hybridemoineau](https://www.debian-fr.org/u/hybridemoineau)\ **Post date:** [Février 21, 2016, 1:37 UTC](https://www.debian-fr.org/t/systeme-clone-ne-demarre-pas-grub-ou-fstab/55407/18 "2016-02-21T13:37:45Z")
[quote=“PascalHambourg”]Tu peux comparer les modules inclus dans les deux initramfs. Code: gunzip -c /boot/initrd.img-xxx | cpio -t | grep ko[/quote] Euh, je n’arrive pas à lancer la commande, par exemple ```auto ``` me renvoie une erreur, pas d’archive à ce nom `gzip: initrd.img-3.2.0-3.gz: No such file or directory cpio: fin prématurée de l'archive` ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Février 21, 2016, 1:37 UTC](https://www.debian-fr.org/t/systeme-clone-ne-demarre-pas-grub-ou-fstab/55407/19 "2016-02-21T13:37:45Z")
Tu es dans le répertoire qui contient le fichier (/boot) ? Sinon, il faut indiquer le chemin complet our relatif. ---
**Author:** ![hybridemoineau](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/h/e9bcb4/32.png) [@hybridemoineau](https://www.debian-fr.org/u/hybridemoineau)\ **Post date:** [Février 21, 2016, 1:37 UTC](https://www.debian-fr.org/t/systeme-clone-ne-demarre-pas-grub-ou-fstab/55407/20 "2016-02-21T13:37:46Z")
Voici les résultats, pour le système d’origine sur sda1 `# gunzip -c initrd.img-3.2.0-3-amd64 | cpio -t | grep ko 11323 blocs lib/modules/3.2.0-3-amd64/kernel/drivers/scsi/scsi_mod.ko lib/modules/3.2.0-3-amd64/kernel/drivers/scsi/sd_mod.ko lib/modules/3.2.0-3-amd64/kernel/drivers/ata/libata.ko lib/modules/3.2.0-3-amd64/kernel/drivers/ata/pata_amd.ko lib/modules/3.2.0-3-amd64/kernel/drivers/ata/ata_generic.ko lib/modules/3.2.0-3-amd64/kernel/drivers/thermal/thermal_sys.ko lib/modules/3.2.0-3-amd64/kernel/drivers/acpi/fan.ko lib/modules/3.2.0-3-amd64/kernel/drivers/acpi/thermal.ko lib/modules/3.2.0-3-amd64/kernel/drivers/md/dm-mod.ko lib/modules/3.2.0-3-amd64/kernel/fs/mbcache.ko lib/modules/3.2.0-3-amd64/kernel/fs/jbd/jbd.ko lib/modules/3.2.0-3-amd64/kernel/fs/ext3/ext3.ko lib/modules/3.2.0-3-amd64/kernel/fs/fuse/fuse.ko lib/modules/3.2.0-3-amd64/kernel/lib/crc-t10dif.ko ` et pour le système cloné sur sdb1 `# gunzip -c initrd.img-3.2.0-3-amd64 | cpio -t | grep ko 11356 blocs lib/modules/3.2.0-3-amd64/kernel/lib/crc-t10dif.ko lib/modules/3.2.0-3-amd64/kernel/drivers/scsi/sd_mod.ko lib/modules/3.2.0-3-amd64/kernel/drivers/scsi/scsi_mod.ko lib/modules/3.2.0-3-amd64/kernel/drivers/acpi/thermal.ko lib/modules/3.2.0-3-amd64/kernel/drivers/acpi/fan.ko lib/modules/3.2.0-3-amd64/kernel/drivers/thermal/thermal_sys.ko lib/modules/3.2.0-3-amd64/kernel/drivers/md/dm-mod.ko lib/modules/3.2.0-3-amd64/kernel/drivers/ata/libata.ko lib/modules/3.2.0-3-amd64/kernel/drivers/ata/ata_generic.ko lib/modules/3.2.0-3-amd64/kernel/drivers/ata/sata_nv.ko lib/modules/3.2.0-3-amd64/kernel/fs/mbcache.ko lib/modules/3.2.0-3-amd64/kernel/fs/jbd/jbd.ko lib/modules/3.2.0-3-amd64/kernel/fs/fuse/fuse.ko lib/modules/3.2.0-3-amd64/kernel/fs/ext3/ext3.ko ` Sauf erreur, si on retire les doublons, le système d’origine sda1 a pour lignes particulières ```auto ``` et le système cloné sdb1 `lib/modules/3.2.0-3-amd64/kernel/drivers/thermal/thermal_sys.ko lib/modules/3.2.0-3-amd64/kernel/drivers/ata/sata_nv.ko` Il y a bien une ligne sata supplémentaire pour le clone au noyau modifié…! Ca n’empêche que je ne comprend pas grand chose. Vous pouvez m’expliquer pourquoi deux noyaux de version identique ont des configurations différentes à la base ? Et pourquoi le passage d’un système à l’autre se fait non seulement en démarrant sur le clone pour lancer le système d’origine (il a la config SATA), mais aussi dans l’autre sens (alors qu’il n’a pas la config, mais j’utilise les lignes du fichier custom Etxeberrizahar) ? [Page suivante](https://www.debian-fr.org/t/systeme-clone-ne-demarre-pas-grub-ou-fstab/55407.md?page=2)