système cloné ne démarre pas: grub ou fstab ?

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…

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

pour plus de clarté.

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

(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…).

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?)

}
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

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…).

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…

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 ?

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.

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?

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.

Hum, pas de trace d’uuid dans l’initrd, bizarre…

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.

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.

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 …

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…

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.

Tu peux comparer les modules inclus dans les deux initramfs.

[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

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

Tu es dans le répertoire qui contient le fichier (/boot) ? Sinon, il faut indiquer le chemin complet our relatif.

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

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) ?