Vous n'êtes pas identifié(e).
Hors ligne
affiche que le système de fichiers est inconnu ?
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par Beta-Pictoris (16-08-2018 23:34:54)
Hors ligne
Hors ligne
tout marche avec Super Grub Disk
Tu veux dire que le GRUB de SuperGRUBDisk réussit à amorcer les noyaux des deux systèmes Debian installés sur cette machine ?
Dans le shell de ce GRUB, avec ls tu peux voir le contenu des partitions et du répertoire /boot/grub/i386-pc ?
Dernière modification par raleur (17-08-2018 16:35:31)
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Hors ligne
Je n'ai pu booter que sur ma Debian initialement installée avec Super Grub Disk. Je n'ai pas trouvé comment booter sur l'autre. (la netinstall installée pour l'essai).
C'est-à-dire, "tu n'as pas trouvé comment booter" ? Je ne connais pas le fonctionnement de SuperGrubDisk (jamais utilisé car jamais eu besoin).
J'ai mis le SSD en question dans un autre portable. (ThinkPad X220i avec BIOS UEFI aussi)
Le Dell Latitude 5410 a un firmware UEFI ? Ça devrait être un des tout premiers alors car j'ai vu celui du 6410 et il n'avait pas l'air très abouti.
Il boot sur les deux Debian présentes sans problèmes en Legacy
Je soupçonne de plus en plus un bug dans les fonctions d'accès disque du BIOS (ou plutôt du firmware UEFI en mode legacy) du Latitude.
Est-ce la dernière version de BIOS disponible ?
Mon hypothèse est que le BIOS n'accède pas correctement au disque à partir d'une certaine adresse LBA. Initialement le répertoire /boot/grub devait être localisé dans la partie accessible et tout allait bien. Puis suite à une modification quelconque, le contenu a été déplacé dans la partie inaccessible.
J'avais posé une question dans un message précédent :
Dans le shell GRUB de SuperGrubDisk, tu peux voir le contenu des partitions du SSD et de leur répertoire /boot/grub/i386-pc avec ls ?
Je complète : en amorçant en mode legacy.
Si la réponse est oui, alors cela contredit mon hypothèse.
Si j'ai vu juste, un contournement serait de créer une partition /boot de quelques centaines de Mo au début du disque pour être sûr que les fichiers dont GRUB a besoin sont dans la partie accessible par le BIOS. Cela nécessite malheureusement de déplacer et réduire la partition racine avec Gparted si tu ne veux pas réinstaller le système actuel.
Sinon, tu pourrais éventuellement essayer de mettre en place un amorçage en mode EFI avec une partition EFI et grub-efi-amd64-bin en espérant que le bug n'affecte pas le mode EFI, mais je ne garantis pas le résultat avec un aussi vieux firmware. J'ai eu pas mal de soucis d'amorçage divers avec de vieux firmwares UEFI. Tu peux tester avec SuperGrubDisk s'il est amorçable en mode EFI.
Dernière modification par raleur (20-08-2018 10:43:41)
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par Beta-Pictoris (20-08-2018 16:04:25)
Hors ligne
Hors ligne
Dernière modification par raleur (20-08-2018 16:46:40)
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par Caribou22 (20-08-2018 16:54:27)
Hors ligne
Dernière modification par raleur (20-08-2018 16:59:22)
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Dernière modification par raleur (20-08-2018 17:03:50)
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
et ensuite , modifier le fstab en mettant à jour le UUID du swap d'après le blkid .
(attention , sans les guillemets ! )
à confirmer par la communauté .
Dernière modification par Debian Alain (20-08-2018 18:02:12)
Hors ligne
Hors ligne
Hors ligne
Dernière modification par Beta-Pictoris (20-08-2018 18:26:20)
Hors ligne
C'est quand même curieux, autant j'ai rencontré des plantages au démarrage de Windows en changeant de mode SATA, autant je n'en ai jamais rencontré avec Linux. J'ai un PC fixe Dell à peu près de la même génération, je vais vérifier ce soir.
Test effectué comme promis : aucune différence entre les modes ATA et AHCI, ça boote correctement dans les deux modes. Mon Optiplex doit être un peu plus ancien que ton Latitude car son BIOS n'est pas UEFI.
modifier le fstab en mettant à jour le UUID du swap d'après le blkid
Faire plutôt l'inverse : mettre l'UUID du swap en conformité avec la valeur dans fstab et l'initramfs avec swaplabel -U. Une seule modification à faire.
J'ai aussi eu ça à régler (incohérence entre l'UUID du swap et celui enregistré dans l'initramfs pour le retour de l'hibernation
Quelle surprise...
Tu n'as pas aussi dû réinstaller GRUB ? Le GRUB installé dans le MBR par la seconde installation allait chercher ses fichiers dans la partition sda2 reformatée en swap et devait donc s'arrêter en mode rescue.
Retirer la batterie, débrancher l'adaptateur secteur, attendre une nuit, rebrancher l'adaptateur secteur et rentrer, immédiatement, dans le bios pour vérifier si l'heure est à jour.
Quelle est l'utilité de ce test ? Si le but est de vérifier si la pile est encore capable de maintenir l'horloge matérielle sans batterie ni alimentation, pas besoin d'attendre une nuit entière, ce qui va l'user à coup sûr.
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par Caribou22 (21-08-2018 11:06:19)
Hors ligne