Tu arrives à voir ton ssd et à booter dessus via Super Grub 2 ??
Je viens de lire un article sur la carte ASRock X670 Xpansion Kit Card qui m’a fait repenser à toi et ton problème…
Si GRUB et le BIOS ne voient pas le SSD NVMe, SuperGrubDisk ne le verra pas non plus.
Il me semble que ces cartes adaptatrices font un pont direct entre le bus PCI-E et le SSD, ce pourquoi je m’étonne que cela ne fonctionne pas… La mienne est dépourvue de chipset, y a juste 3 composants de surface pour réguler la puissance électrique.
Peut-être faudrait-il tester cela avec un autre SSD M.2 qui en soit pas Nvme mais SATA…
« Super GRUB2 Disk prend en charge le démarrage d’OSX, le démarrage en boucle à partir de fichiers iso, le démarrage d’un système d’exploitation à partir d’USB sans prise en charge USB dans le BIOS et d’autres fonctionnalités qui ne sont pas possibles avec l’héritage GRUB. »
Au contraire, cela n’a rien d’étonnant si le BIOS de la carte mère ne gère pas le NVMe et la carte adaptatrice est dépourvue de puc d’extension de BIOS (ROM) pour apporter cette prise en charge, comme certaines cartes contrôleurs RAID ou SCSI/SAS. Le noyau Linux a son propre pilote NVMe mais GRUB dépend du BIOS pour la prise en charge des supports de stockage.
Mettre un SSD SATA en direct sur un bus PCIe ne marchera pas.
Grâce aux pilotes USB natifs de GRUB. Mais GRUB n’a pas de pilote NVMe.
Hello, je me suis fait discret car les régles du forum blacklist les nouveaux inscrits pendant 19h00 « pour raison de sécurité » (dixit)
Dans l’intervalle j’ai
- flinguer grub
- flinguer le mbr
et donc plus d’accès à ma machine. Cela m’a donner l’occasion de pratiquer supergrub2 qui m’a permis de me sortir de ce mauvais pas car :
- via live cd les update-grub plantaient en « …, cow » (oublié le msg précis mais ce problème est très connu et bien foireux).
- via live cd un boot-repair malgré des message de réussite n’installait rien.
- via live cd le chroot planté pour diverses raisons
Supergrub2 m’a permis de démarrer sur mon ssd d’origine , j’ai donc restoré le grub avec boot-repair (plus brillant que dans la situation précédente).
Toutefois supergrub2 n’a pas été capable de démarrer sur le nvme toutes les tentatives ont abouti sur une busybox (pas sur du nom) et une fois sur un « >ramdisk ». Petite réserve l’ergonomie de supergrub2 est assez obscure peut-être ai-je loupé quelque chose …
De retour à ma situation précédente. J’ai essayé la proposition de Pascal sans résultat d’ou
Pascal, qu’entends tu par mettre à jour etc/fstab ? quel UUID doit elle contenir ? celle du nvme ou celle de la cle usb ? Après la modification doit-on régénérer le ramfs ?
Merci
update-grub doit être exécuté dans un chroot du système cible. Dans un système live ça n’a aucun intérêt et il ne peut pas localiser la racine qui est une union entre une image squashfs montée en loop et un tmpfs.
Quelle proposition ? Réinstallation ou déplacement de /boot de l’installation existante ? Qu’as-tu fait exactement ?
Je suppose que tu veux parler du déplacement de /boot. J’avais pourtant recommandé la réinstallation, plus simple quand on ne maîtrise pas le sujet. Il faut ajouter une ligne pour monter une partition de la clé USB sur /boot, avec l’UUID de cette partition. Pas besoin de regénérer l’initramfs qui sert à monter la racine donc pas concerné par /boot.
A te lire le bios de ta carte mère tout comme Super Grub 2 n’offrent malheureusement pas le support Nvne ;-( Fallait tenter le coup pour en être sûr…
La seule solution me semble-t-il qu’il reste serait de refaire une install avec un SSD M.2 SATA et non pas Nvme.
Bonne chance à toi…
Tu ne m’ a pas bien lu, ou et alors tu ne sais pas qu’il existe des SSD au format M.2 utilisant le protocole SATA…
Il fallait tenter le coup pour s’assurer du fait que Super Grub 2 gère le Nvme ou pas. La doc parle « d’autres fonctionnalités qui ne sont pas possibles avec l’héritage GRUB » sans plus de détails.
Mais non, il suffit de mettre GRUB et /boot sur un support que le BIOS est capable de gérer : clé USB, disque ou SSD SATA… Tout le reste (racine, /home…) peut aller sur le NVMe.
Ceci dit, sur une machine de cet âge, je ne suis pas convaincu que le NVMe apporte un gain significatif par rapport au SATA 6G, mais je ne demande qu’à l’être.
Je sais très bien qu’il existe des SSD au format M.2 utilisant le protocole SATA. Mais ils ne fonctionnent qu’avec un slot M.2 qui utilise aussi le protocole SATA, ce qui n’est pas le cas d’une carte adaptatrice PCIe-M.2 sans chipset. Le SSD doit donc avoir une interface PCIe, ce qui n’est le cas que des SSD utilisant les protocoles NVMe et AHCI.
Bon, après des péripéties que je vous épargne, j’ai une situation propre. Mon besoin est donc de démarrer une debian sur un nvme à partir d’une clé usb également debian. Précisions :
- Un lancement à partir de la clé avec choix debian nvme (détectée lors de l’install) bloque sur partition inconnue ; il convient de charger un noyau !
- Un lancement à partir de la clé avec choix debian de la clé fonctionne.
- J’ai eu du mal mais le chroot sur la clé fonctionne.
Pouvez-vous m’indiquer les modifications à apporter pour que le choix de la debian nvme dans le grub de la cle usb lance la debian du nvme ?
Merci.
Il ne faut pas installer Debian sur la clé USB mais installer Debian sur le SSD avec /boot et GRUB sur la clé USB.
Ok, c’est fait et ne fonctionne pas.
Lors de l’install sur le nvme, le grub correspondant a été placé sur la clé et cela a abouti au même problèmes. Le grub de la clé se lançait bien mais la partition nvme n’était pas reconnue. Exactement comme la situation actuelle.
Mais maintenant je peux intervenir en chroot sur la clé pour lui faire installer la partition nvme via sa debian avant de lancer le système de la debian du nvme.
Et /boot ?
Non pas le /boot.
C’est pour ça que ça n’a pas marché.
Le /boot en question (sur la clé usb donc) doit-il inclure les initrd et vmlinuz du nvme ?
Oui, et le répertoire grub/. Tout ce qu’il y a habituellement dans /boot.
Ok, c’est fait ya t’il une autre modification à apporter avant de booter ?
Qu’est-ce qui a été fait exactement ?
Tout d’abord j’ai du modifier dans le grub.cfg (du nvme copié sur la cle) l’uuid car figurait celui de la clé avant réinstall de cette dernière.
Dans le grub de la clé modifié je n’ai pas touché le :
(1) menuentry 'Debian GNU/Linux' ...
j’ai utiliser les menu suivant (submenu 'Advanced options ) en :
- (2) linux et intird avec uuid de la clé (en apparence comme le précédent voir ensuite)
- (3) linux (uuid:clé) initrd (uuid:nvme)
- (4) linux (uuid:nvme) initrd(uuid:nvme)
Lors du lancement sur le grub de la cle ainsi modifié :
- 1er menu : kernel panique (y avait longtemps que j’en avais vu un
- 2ème menu : va un peu plus loin mais à mi chemin me demande de me signer en root pour réaliser une maintenance après quoi le clavier réagit bizarrement le je dois appuyer plusieurs fois sur les touches pour faire prendre en compte la saisie. La commande reboot n’est pas reconnue. Nota: lors du boot un message indique un problème de mount et il choisirait le montage standard …
- 3ème menu : là je vais jusqu’à me signer. le / est sur la clé et unr rebbot est accepté.
- 4ème menu : le grub affiche partition non trouvé pour linux et initrd et se fige.
Pas brillant
Dans un message précédent tu parlais d’une mise à jour de la fstab d’où ma dernière question y a t’il autre chose à faire ?