Si je comprends bien tu n’as pas fait du tout ce que j’avais suggéré (réinstallation sur NVMe+USB ou déplacement de /boot de NVMe sur USB), tu as juste essayé de bidouiller le grub.cfg du système Debian installé sur la clé ?
Il n’est pas impossible de mettre sur la clé USB à la fois un système entier minimal pour bricoler et le /boot du système du NVMe, mais il ne faut pas les mélanger. Par contre il n’y aura qu’un seul GRUB pour les deux, forcément.
Il n’y a pas d’UUID dans les commandes initrd de grub.cfg. Montre un exemple complet d’entrée de menu, par exemple la (3), et la sortie de blkid pour voir à quoi correspondent les UUID et le fichier /etc/fstab du NVMe.
J’avais dit avec /boot et GRUB sur la clé. Si tu l’avais fait ça aurait été suffisant, il n’y avait rien d’autre à faire.
Je n’ai jamais suggéré ça.
Comment exactement ?
Il y a deux types d’UUID dans grub.cfg :
ceux dans les commandes search qui servent à trouver l’emplacement des fichiers dont GRUB a besoin. Ils doivent être sur la clé USB puisque GRUB ne peut pas accéder au SSD NVMe ;
ceux du paramètre root= dans les commandes linux qui sert au noyau ou à l’initramfs à trouver la racine à monter. Ce doit être celui de la racine sur le SSD NVMe.
Super, cela fonctionne. Merci Pascal.
En résumé et dit avec mes termes. Ce que j’ai fait et qui m’a permis de booter sur un nvme non reconnu par mon bios (pas de EFI) :
install debian sur nvme.
install debian sur la clé (c’est llloonnngg )
copie de /boot du nvme sur la clé.
copie de /etc/fstab du nvme sur la clé
en chroot sur la clé → actualiser grub.
Là attention, dans la liste grub installée seul fonctionne le lancement avec linux et initrd pointant sur l’uuid du nvme … donc inutile de lancer les autres lignes, au mieux ça plante mais parfois ça se lance avec des comportement très bizarre !
Vous aurez noté que je n’ai pu faire ces manip que grâce à un linux installé sur un autre média reconnu …
Bon, plus qu’à finir l’install de la debian car gros pb de définition d’écran donc pour les mesure de perf du nvme/ssd sata prévoir un délai.
Bonne journée à tous et encore merci à Pascal pour ces orientations.
Il s’agit du retour d’expérience d’un béotien donc sans prétention de démarche quelconque. Si vous pouvez rendre ce retour plus pertinent n’hésitez pas.
Normal, le processus d’écriture dans une mémoire flash est intrinsèquement plus lent que la lecture. La technologie flash est dérivée des EPROM (mémoire morte programmable électriquement) dans lequelles on n’écrit pas mais qu’on « programme ». Les SSD intègrent des optimisations pour atténuer cette réalité technique (mémoire cache, « ramasse-miettes », blocs de réserve, effacement anticipé, parallélisme…) dont les clés USB sont souvent dépourvues.
update-grub peut créer des entrées de menu incohérentes quand os-prober détecte un système avec exactement le même noyau que celui du système depuis lequel il est lancé. En cas de chroot, le résultat est encore plus incertain.
Bref, je redis que le plus simple, le plus sûr et le plus rapide est de loin de faire l’installation directement avec /boot et GRUB sur la clé USB et le reste sur le SSD.
J’ai chargé les drivers et tout est rentré dans l’ordre … en écran logique 3 fois plus grand que le physique c’est parfois du sport
$ lspci -nnkd ::300
08:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Cedar [Radeon HD 5000/6000/7350/8350 Series] [1002:68f9]
Subsystem: ASUSTeK Computer Inc. Radeon HD 5450 [1043:0386]
Kernel driver in use: radeon
Kernel modules: radeon
À y être rapide retour sur les performance du nvme. En synthèse, très légèrement moins performant que le ssd mais beaucoup plus instable … il déteste les fichiers d’un Meg. avec lesquels ses perf. s’effondrent (mesuré par iozone). Et en conclusion ça valait pas le coup de s’emm… le ssd est meilleur.
/dev/nvme0n1:
Timing cached reads: 16570 MB in 1.99 seconds = 8310.27 MB/sec
Timing buffered disk reads: 2624 MB in 3.00 seconds = 874.66 MB/sec
Je ne suis pas sûr que les résultats hdparm soit totalement pertinent car iozone indique selon la taille des fichiers et des records des performances très différentes.
Toutefois si on se place dans le ressenti, la debian-xfce est beaucoup plus véloce que la ubuntu/xfce que j’utilise quotidiennement. A chiffrer le « beaucoup » j’irai presque jusqu’à x2 . Cela vient-il de la distrib ou du disque ???
Qu’appelles-tu « le dépôt free » ? Si tu parles de la section « main » des dépôts Debian, elle a forcément été ajoutée lors de l’installation, et le pilote radeon pour Xorg, xserver-xorg-video-radeon, qui en fait partie était déjà disponible et installé. Tu ne parlerais pas plutôt de la section « non-free » et du paquet firmware-amd-graphics qui contient les firmwares et non les pilotes ?
Un benckmark n’est pertinent que dans la mesure où il est représentatif du cas d’utilisation. Quelle est la part des opérations qui ont des mauvais scores dans l’utilisation totale du SSD ? (question rhétorique qui n’appelle pas de réponse, seulement destinée à relativiser les résultat du benchmark)
hdparm peut servir à détecter un goulet d’étranglement. 273 Mo/s, même pour un SSD SATA, ce n’est pas fameux. Mon vieux SSD SATA de 2012 fait deux fois mieux. Une explication possible est qu’il soit limité en SATA 3.0G, soit par conception, soit par le contrôleur SATA (ce qui n’est pas aberrant vu l’âge de la machine) ?
874 Mo/s pour un SSD NVMe, ce n’est pas foudroyant non plus. La encore, l’âge de la machine et la vitesse de ses autres composants (processeur, mémoire) joue peut-être aussi. Mais le protocole NVMe n’est pas censé améliorer seulement le débit séquentiel mais aussi la latence et le nombre d’opérations par seconde (IOPS), non mesurés par hdparm.
Le seul moyen fiable de le déterminer serait de faire fonctionner les deux systèmes sur le même SSD ou un même système sur les deux SSD (principe du test croisé : on ne modifie qu’un seul élément à la fois pour évaluer son impact).
)