Re: update-grub2 et /dev/sda : résolus
Le 20/01/2018 à 18:54, andre_deb...@numericable.fr a écrit : As tu vraiment lu mon mail avant ta réponse ? Il n'y a vraiment rien eu "d'insupportable" de ma part, Bonjour, chacun son niveau de tolerance. Tu ne vois pas le probleme dans le fait de nous traiter comme des agents de support tout le temps disponible pour lire entre les lignes de ce que tu daignes devoiler et pour t'aider alors que tu ne reponds qu'a les questions que tu souhaites, mets plus de volonte a faire tes bidouilles car comprendre et appliquer ce qu'on t'explique et n'indiques pas exactement toutes les manipulations que tu fais en parallele. Moi si, ce n'est pas la conception que j'ai de cette liste d'entraide. /dev/sda était bien remis avant de lancer update-grub2, ça ne vient pas de là. Je ne dis pas le contraire. L'essentiel est que l'action réussisse : Tu compares des choses que ne le sont pas vraiment : Quelle est cette facheuse erreur de comparaison ? Ben te sortir d'une tempete sans respecter les regles theoriques n'aura d'impact que sur toi et sur le moment. Si tu casses ton spi, tu devras te debrouiller pour le remplacer... Mettre des rustines sur un systeme informatique va peut-etre te sembler resoudre le probleme en apparence, mais va peut-etre creer un mic-mac en dessous qui lancera une bombe a retardement. /dev/sda est brusquement devenu /dev/sdc : c'est anormal. Si c'est normal car ce disque a toujours ete "/dev/sdc", un co-listier avait retrouve un message de l'ete dernier dans lequel tu disais deja que ca t'embetait et que tu avais trouve une rustine pour le faire devenir "/dev/sda". Et oh surprise, un trimestre plus tard, la rustine(dont tu ne te souviens plus en quoi elle consistais) n'agit plus... J'aurais préféré réussir par la méthode de la conformité, mais elle n'a jamais voulu fonctionner. J'ai deja assez exprime mon desaccord la-dessus, mais on ne changera pas ta facon de fonctionner et de communiquer. Tant mieux si tu trouves encore de bonnes ames pour t'aider, c'est juste que je n'en ferai pas partie. -- Cordialement, Stephane Ascoet
Re: update-grub2 et /dev/sda : résolus
On Wednesday 17 January 2018 09:53:33 S. Ascoet wrote: > Bonjour, non, je n'ai rien contre toi. C'est juste que tu ne respectes > pas les bonnes regles pour poser des questions ce qui cree de la > confusion et fait perdre bien du temps a tourner en rond pour qu'au > final tu n'en fasses qu'a ta tete et surtout en ne l'assumant pas, c'est > ca le plus insupportable : As tu vraiment lu mon mail avant ta réponse ? Il n'y a vraiment rien eu "d'insupportable" de ma part, surtout si tu daignes maintenant lire mon mail ci-dessous : > Bien sur, Grub intervient alors que /dev n'existe meme pas encore : /dev/sda était bien remis avant de lancer update-grub2, ça ne vient pas de là. > > Les membres de l'association retrouvent un serveur bien fonctionnel : > Qui ne serait peut-etre jamais tombe en panne si tu n'avais pas > l'habitude de toucher a des trucs qui ne doivent pas l'etre, mais comme > tu ne nous donnes jamais aucune information sur le pourquoi de ces > manipulations... : Je n'ai rien touché avant la panne, elle s'est manifestée après un reboot. > > L'essentiel est que l'action réussisse : > Tu compares des choses que ne le sont pas vraiment : Quelle est cette facheuse erreur de comparaison ? Plus sérieux, DEVICE DU DISQUE DUR : /dev/sda est brusquement devenu /dev/sdc : c'est anormal. Ma méthode était peut-être pas trop orthodoxe : # mv /dev/sdc /dev/sda après reboot, a remis toutes les 8 partitions du disque dur sur leur device /dev/sda1 à /dev/sda8. GRUB : #update-grub2 ne me créait pas un fichier "grub.cfg" bootable, car UUID pas respectés. Je l'ai modifié à la main, en remettant le bon UUID pour chaque partition. C'est vrai, la méthode est non conforme, puisque au début du fichier grub.cfg, il est indiqué qu'il ne faut pas le modifier à la mano. Au reboot, tout refonctionne, grub boote sur sur toutes les partitions Linux, et #df -h indique bien /dev/sda1. J'aurais préféré réussir par la méthode de la conformité, mais elle n'a jamais voulu fonctionner. André
Re: update-grub2 : résolu mais...
(...) Ok Le 19/01/2018 à 22:21, Pascal Hambourg a écrit : > Dans mon idée, la configuration du GRUB principal indépendant serait > gérée manuellement et n'aurait besoin d'être modifiée que lorsqu'on > ajoute ou supprime une distribution. Les noyaux des distributions > seraient gérés par leurs GRUB respectifs. > > Menu de GRUB0 : > "Linux1" -> GRUB1 > "Linux2" -> GRUB2 > etc. Bon, il faudrait que je vois ca de mes yeux vus. Donc le GRUB0 n'aurait que des liens vers les autres Grub... ok, je comprend mieux. Je croyais que les lignes de commandes de boot étaient en lui, tu comprends donc maintenant ma logique qui me disait que ce n'était pas ultra simple de mettre à jour à chaque fois ce GRUB0 (à la manière de notre bon vieux Grub en solo habituel). signature.asc Description: OpenPGP digital signature
Re: update-grub2 : résolu mais...
Le 19/01/2018 à 09:51, Pierre L. a écrit : Le 18/01/2018 à 23:43, Pascal Hambourg a écrit : Le 18/01/2018 à 23:14, Pierre L. a écrit : Ca ne vaudrait pas le coup d'avoir qu'1 seul Grub sur une clé USB par exemple, et n'utiliser que cette clé comme périph' de boot ? (...) Mais pourquoi sur une clé USB plutôt que sur un disque interne ? Pourquoi pas ? ;) Eh, c'est toi qui a demandé si ça ne valait pas le coup. Tu sous-entends donc que ça aurait un intérêt. Je n'ai pas dit que ça avait un inconvénient. Je dis juste que je ne vois pas l'intérêt. On donne l'ordre aux distribs d'installer Grub dans /dev/sda qui est mon seul HDD. Donc systématiquement ces distribs écraseront Grub présent au boot de /dev/sda, non ? Sinon oui, l'intérêt d'avoir une clé, serait d'éviter les conflits de Grub (généré par les distribs) sur ce même disque dur, et ainsi extérioriser Grub dans un /dev/sdb Il suffit de leur donner l'ordre d'installer GRUB ailleurs pour éviter les conflits, et pas besoin de clé USB. Pour ma part, je serais plutôt partisan d'un GRUB principal indépendant qui chaînerait les GRUB des différentes distributions. (...) Dans mon exemple, appelons Grub0 celui qui est principal, le fameux indépendant. Mes distribs seront Linux1, Linux2, etc. qui auront chacune leur Grub1, Grub2, etc. Linux1 obtient un nouveau kernel via ses mises à jour, donc son Grub1 "personnel" sera mis à jour comme d'hab. Jusqu'ici, ça va. De plus, Linux1 mettra à jour AUSSI le principal Grub0 dans la foulée (c'est une supposition, jamais testé), Et comment diable ferait-il cela ? car si Grub0 n'est plus à jour, sa référence vers Linux1 sera erronée. Le chaînage éviterait de devoir modifier le GRUB principal. Idem avec un Linux2 qui obtiendrait un nouveau kernel une semaine plus tard... qui mettrait à jour son Grub2 + Grub0 Etc. Linux3 -> Grub3 + Grub0 Bref, tout le monde pourrait effectivement générer ce Grub0 principal. (principe erroné ?) Dans le principe, pourquoi pas. Mais concrètement, comment fais-tu ça ? J'ai souvenir d'avoir utilisé des outils comme SuperGrub il y a un certain temps, tu penserais alors à ce genre de truc ? (qui si je me souviens bien, permettait de booter les distribs présentes sur les disques d'une machine, dans laquelle le programme de boot avait été corrompu ou effacé, une roue de secours pour booter tes systèmes Linux et autres windows...) Je n'ai jamais utilisé ce genre d'outil que je ne connais que de nom. Dans mon idée, la configuration du GRUB principal indépendant serait gérée manuellement et n'aurait besoin d'être modifiée que lorsqu'on ajoute ou supprime une distribution. Les noyaux des distributions seraient gérés par leurs GRUB respectifs. Menu de GRUB0 : "Linux1" -> GRUB1 "Linux2" -> GRUB2 etc.
Re: update-grub2 : résolu mais...
Le 18/01/2018 à 23:43, Pascal Hambourg a écrit : > Le 18/01/2018 à 23:14, Pierre L. a écrit : >> >> Le 18/01/2018 à 22:19, Pascal Hambourg a écrit : >>> Le 18/01/2018 à 20:36, Pierre L. a écrit : Le 18/01/2018 à 20:09, Pascal Hambourg a écrit : > Le 18/01/2018 à 14:04, Pierre L. a écrit : >> Ca ne vaudrait pas le coup d'avoir qu'1 seul Grub sur une clé USB >> par >> exemple, et n'utiliser que cette clé comme périph' de boot ? > > Dans quel intérêt ? Je n'en vois aucun. 1 seul Grub plutôt que d'avoir 50 fichiers à gérer comme ca a l'air d'être le cas... On centralise... >>> >>> Mais pourquoi sur une clé USB plutôt que sur un disque interne ? >> Pourquoi pas ? ;) > > Eh, c'est toi qui a demandé si ça ne valait pas le coup. Tu > sous-entends donc que ça aurait un intérêt. Je n'ai pas dit que ça > avait un inconvénient. Je dis juste que je ne vois pas l'intérêt. On donne l'ordre aux distribs d'installer Grub dans /dev/sda qui est mon seul HDD. Donc systématiquement ces distribs écraseront Grub présent au boot de /dev/sda, non ? Sinon oui, l'intérêt d'avoir une clé, serait d'éviter les conflits de Grub (généré par les distribs) sur ce même disque dur, et ainsi extérioriser Grub dans un /dev/sdb > >>> Pour ma part, je serais plutôt partisan d'un GRUB principal >>> indépendant qui chaînerait les GRUB des différentes distributions. >>> >> Ce fameux "GRUB principal indépendant" pourrait alors être généré par >> chacune des distribs, > > Ben non, sinon il ne serait pas indépendant. Il le pourrait (être indépendant et généré par tous), car généré à chaque fois que c'est nécessaire. Dans mon exemple, appelons Grub0 celui qui est principal, le fameux indépendant. Mes distribs seront Linux1, Linux2, etc. qui auront chacune leur Grub1, Grub2, etc. Linux1 obtient un nouveau kernel via ses mises à jour, donc son Grub1 "personnel" sera mis à jour comme d'hab. De plus, Linux1 mettra à jour AUSSI le principal Grub0 dans la foulée (c'est une supposition, jamais testé), car si Grub0 n'est plus à jour, sa référence vers Linux1 sera erronée. Idem avec un Linux2 qui obtiendrait un nouveau kernel une semaine plus tard... qui mettrait à jour son Grub2 + Grub0 Etc. Linux3 -> Grub3 + Grub0 Bref, tout le monde pourrait effectivement générer ce Grub0 principal. (principe erroné ?) (j'espère avoir été précis dans l'exposition de mes pensées ! ) > >> dès lors que la distrib irait lire chaque grub.cfg >> dans la machine, mais alors en reprenant la précédente citation, il >> faudrait alors qu'une seule distrib gère ce GRUB principal ? > > C'est une autre possibilité, qui correspond à ce que j'ai répondu à > André. Mais ce n'est pas un GRUB indépendant, c'est le GRUB d'une > distribution qui récupère et inclut les paramètres des autres dans sa > config. > Mais alors, si c'est un Grub d'une distrib et qu'il n'est plus indépendant, c'est le serpent qui se mord la queue :) J'ai souvenir d'avoir utilisé des outils comme SuperGrub il y a un certain temps, tu penserais alors à ce genre de truc ? (qui si je me souviens bien, permettait de booter les distribs présentes sur les disques d'une machine, dans laquelle le programme de boot avait été corrompu ou effacé, une roue de secours pour booter tes systèmes Linux et autres windows...) signature.asc Description: OpenPGP digital signature
Re: update-grub2 : résolu mais...
Le 18/01/2018 à 23:14, Pierre L. a écrit : Le 18/01/2018 à 22:19, Pascal Hambourg a écrit : Le 18/01/2018 à 20:36, Pierre L. a écrit : Le 18/01/2018 à 20:09, Pascal Hambourg a écrit : Le 18/01/2018 à 14:04, Pierre L. a écrit : Ca ne vaudrait pas le coup d'avoir qu'1 seul Grub sur une clé USB par exemple, et n'utiliser que cette clé comme périph' de boot ? Dans quel intérêt ? Je n'en vois aucun. 1 seul Grub plutôt que d'avoir 50 fichiers à gérer comme ca a l'air d'être le cas... On centralise... Mais pourquoi sur une clé USB plutôt que sur un disque interne ? Pourquoi pas ? ;) Eh, c'est toi qui a demandé si ça ne valait pas le coup. Tu sous-entends donc que ça aurait un intérêt. Je n'ai pas dit que ça avait un inconvénient. Je dis juste que je ne vois pas l'intérêt. Pour ma part, je serais plutôt partisan d'un GRUB principal indépendant qui chaînerait les GRUB des différentes distributions. Ce fameux "GRUB principal indépendant" pourrait alors être généré par chacune des distribs, Ben non, sinon il ne serait pas indépendant. dès lors que la distrib irait lire chaque grub.cfg dans la machine, mais alors en reprenant la précédente citation, il faudrait alors qu'une seule distrib gère ce GRUB principal ? C'est une autre possibilité, qui correspond à ce que j'ai répondu à André. Mais ce n'est pas un GRUB indépendant, c'est le GRUB d'une distribution qui récupère et inclut les paramètres des autres dans sa config.
Re: update-grub2 : résolu mais...
Le 18/01/2018 à 22:19, Pascal Hambourg a écrit : > Le 18/01/2018 à 20:36, Pierre L. a écrit : >> >> Le 18/01/2018 à 20:09, Pascal Hambourg a écrit : >>> Le 18/01/2018 à 14:04, Pierre L. a écrit : Ca ne vaudrait pas le coup d'avoir qu'1 seul Grub sur une clé USB par exemple, et n'utiliser que cette clé comme périph' de boot ? >>> >>> Dans quel intérêt ? Je n'en vois aucun. >> >> 1 seul Grub plutôt que d'avoir 50 fichiers à gérer comme ca a l'air >> d'être le cas... On centralise... > > Mais pourquoi sur une clé USB plutôt que sur un disque interne ? Pourquoi pas ? ;) > Les différentes distrib iront regarder sur tout le système là où il y a moyen de booter non ? >>> >>> Peux-tu préciser ? Je ne vois pas de quoi tu parles. > > Pas de réponse ? C'était une question... Désolé de ne pouvoir trouver meilleurs termes plus explicites, techniques... > Et donc mettre à jour ce Grub à chaque fois que ce sera nécessaire ? >>> >>> Sûrement pas. Une distribution ne met à jour que son propre GRUB. >> >> On rejoint ma précédente pensée, chaque distribution pourrait actualiser >> le seul Grub de la machine présent sur la clé USB, car j'imagine que >> Grub2 est normalisé ? > > Pas tant que ça. Il y a de légères différences entre différentes > versions de GRUB Et c'est AMA une mauvaise idée car chaque > distribution ne ferait pas que réactualiser le fichier de > configuration mais le réécrirait complètement, en se mettant en > première position bien évidemment. D'autre part il vaut mieux que > chaque distribution garde son propre GRUB avec son propre fichier > grub.cfg avec ses paramètres de démarrage spécifiques car update-grub > se sert du fichier grub.cfg des autres distributions détectées par > os-prober pour récupérer et intégrer lesdits paramètres de démarrage > dans le fichier grub.cfg qu'il construit. > Ok c'est donc de cette manière que Grub fonctionne, interesting. A partir de ces infos, je comprends mieux la suite. > Pour ma part, je serais plutôt partisan d'un GRUB principal > indépendant qui chaînerait les GRUB des différentes distributions. > Ce fameux "GRUB principal indépendant" pourrait alors être généré par chacune des distribs, dès lors que la distrib irait lire chaque grub.cfg dans la machine, mais alors en reprenant la précédente citation, il faudrait alors qu'une seule distrib gère ce GRUB principal ? (evitant : "chaque distribution ne ferait pas que réactualiser le fichier de configuration mais le réécrirait complètement, en se mettant en première position bien évidemment") signature.asc Description: OpenPGP digital signature
Re: update-grub2 : résolu mais...
Le 18/01/2018 à 20:36, Pierre L. a écrit : Le 18/01/2018 à 20:09, Pascal Hambourg a écrit : Le 18/01/2018 à 14:04, Pierre L. a écrit : Ca ne vaudrait pas le coup d'avoir qu'1 seul Grub sur une clé USB par exemple, et n'utiliser que cette clé comme périph' de boot ? Dans quel intérêt ? Je n'en vois aucun. 1 seul Grub plutôt que d'avoir 50 fichiers à gérer comme ca a l'air d'être le cas... On centralise... Mais pourquoi sur une clé USB plutôt que sur un disque interne ? Les différentes distrib iront regarder sur tout le système là où il y a moyen de booter non ? Peux-tu préciser ? Je ne vois pas de quoi tu parles. Pas de réponse ? Et donc mettre à jour ce Grub à chaque fois que ce sera nécessaire ? Sûrement pas. Une distribution ne met à jour que son propre GRUB. On rejoint ma précédente pensée, chaque distribution pourrait actualiser le seul Grub de la machine présent sur la clé USB, car j'imagine que Grub2 est normalisé ? Pas tant que ça. Il y a de légères différences entre différentes versions de GRUB Et c'est AMA une mauvaise idée car chaque distribution ne ferait pas que réactualiser le fichier de configuration mais le réécrirait complètement, en se mettant en première position bien évidemment. D'autre part il vaut mieux que chaque distribution garde son propre GRUB avec son propre fichier grub.cfg avec ses paramètres de démarrage spécifiques car update-grub se sert du fichier grub.cfg des autres distributions détectées par os-prober pour récupérer et intégrer lesdits paramètres de démarrage dans le fichier grub.cfg qu'il construit. Pour ma part, je serais plutôt partisan d'un GRUB principal indépendant qui chaînerait les GRUB des différentes distributions.
Re: update-grub2 : résolu mais...
Le 18/01/2018 à 20:09, Pascal Hambourg a écrit : > Le 18/01/2018 à 14:04, Pierre L. a écrit : >> Ca ne vaudrait pas le coup d'avoir qu'1 seul Grub sur une clé USB par >> exemple, et n'utiliser que cette clé comme périph' de boot ? > > Dans quel intérêt ? Je n'en vois aucun. 1 seul Grub plutôt que d'avoir 50 fichiers à gérer comme ca a l'air d'être le cas... On centralise... Pour mémo, plus haut dans le fil : "J'ai recopié le répertoire /boot/grub sur toutes les partitions Linux." > >> Les différentes distrib iront regarder sur tout le système là où il y a >> moyen de booter non ? > > Peux-tu préciser ? Je ne vois pas de quoi tu parles. > >> Et donc mettre à jour ce Grub à chaque fois que ce sera nécessaire ? > > Sûrement pas. Une distribution ne met à jour que son propre GRUB. On rejoint ma précédente pensée, chaque distribution pourrait actualiser le seul Grub de la machine présent sur la clé USB, car j'imagine que Grub2 est normalisé ? signature.asc Description: OpenPGP digital signature
Re: update-grub2 : résolu mais...
Le 18/01/2018 à 14:04, Pierre L. a écrit : Ca ne vaudrait pas le coup d'avoir qu'1 seul Grub sur une clé USB par exemple, et n'utiliser que cette clé comme périph' de boot ? Dans quel intérêt ? Je n'en vois aucun. Les différentes distrib iront regarder sur tout le système là où il y a moyen de booter non ? Peux-tu préciser ? Je ne vois pas de quoi tu parles. Et donc mettre à jour ce Grub à chaque fois que ce sera nécessaire ? Sûrement pas. Une distribution ne met à jour que son propre GRUB.
Re: update-grub2 : résolu mais...
Ca ne vaudrait pas le coup d'avoir qu'1 seul Grub sur une clé USB par exemple, et n'utiliser que cette clé comme périph' de boot ? Les différentes distrib iront regarder sur tout le système là où il y a moyen de booter non ? Et donc mettre à jour ce Grub à chaque fois que ce sera nécessaire ? signature.asc Description: OpenPGP digital signature
Re: update-grub2 : résolu
Le Wed, 17 Jan 2018 20:52:20 +0100, Pascal Hambourg a écrit : > Le 17/01/2018 à 09:53, Stephane Ascoet a écrit : > [au sujet de l'utilité d'un swap] > > Le 16/01/2018 à 20:25, Pascal Hambourg a écrit : > > > Ou simplement utiliser l'hibernation (suspend to disk). > > > > Je fuis ce truc qui est juste bon a foutre en l'air le mecanisme > > d'amorcage en cas de loupe > > Source ou exemple ? pratique personnelle, je ne lui donne pas tort. Je veux dire par la que la "fiabilité" aléatoire de cet engin peut causer des petites tracasseries équivalent à un arrêt brutal ce qui n'est pas très cool quand on compte sur lui pour sauver le travail en cours, ou au moins se planter pour la restauration de l'état de la machine. > > pour un apport fonctionnel fort faible voire nefaste. > > Ce n'est pas l'avis de tout le monde. Chacun ses besoins. Je suis d'accord aussi, chacun ses besoin, ceci étant il y a quand même des machine plus ou moins fiable sur ce sujet, je suppose en fonction de , pardon, de l'ACPI qui est un peu usine a gaz pas très normalisée dans son genre selon les fabricants. C'est pas comme si le hardware était libre...
Re: update-grub2 : résolu mais...
Le 15/01/2018 à 23:52, andre_deb...@numericable.fr a écrit : Par contre, je trouve le fichier "/boot/grub/grub.cfg" très volumineux (142Ko et 2.771 lignes), et les partitions de /dev/sda2 à sda7 n'ont pas toujours leur bon UUID. Exemple : $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-4.4.0-109-generic-root=UUID=3ba3cb5b-5a71-4d13-90d2-dcdfbea7b3b8 ro single-6af32adf-87c5-4c3f-b390-9727185169ef' ... Dans un même menuentry /dev/sda5, deux UUID différents : 3ba3cb5b-5a71-4d13-90d2-dcdfbea7b3b8 = /dev/sda1 6af32adf-87c5-4c3f-b390-9727185169ef = /dev/sda5 Ce genre de chose peut arriver quand il y plusieurs systèmes installés avec chacun leur GRUB qui détecte tous les autres. Lors de la génération de grub.cfg les fichiers grub.cfg des autres systèmes détectés sont lus pour les intégrer. Une solution consiste à désactiver l'utilisation d'os-prober par GRUB dans les systèmes qui n'ont pas le GRUB actif et exécuter update-grub sur tous les systèmes en finissant par celui qui a le GRUB actif.
Re: update-grub2 : résolu
Le 17/01/2018 à 09:53, Stephane Ascoet a écrit : [au sujet de l'utilité d'un swap] Le 16/01/2018 à 20:25, Pascal Hambourg a écrit : > Ou simplement utiliser l'hibernation (suspend to disk). Je fuis ce truc qui est juste bon a foutre en l'air le mecanisme d'amorcage en cas de loupe Source ou exemple ? pour un apport fonctionnel fort faible voire nefaste. Ce n'est pas l'avis de tout le monde. Chacun ses besoins.
Re: update-grub2 : résolu
Le 16/01/2018 à 13:32, andre_deb...@numericable.fr a écrit : Humm, ici le "cordialement" est de trop. > Je ne t'ai rien demandé personnellement, > je n'ai vraiment pas besoin de tes réflexions, Bonjour, non, je n'ai rien contre toi. C'est juste que tu ne respectes pas les bonnes regles pour poser des questions ce qui cree de la confusion et fait perdre bien du temps a tourner en rond pour qu'au final tu n'en fasses qu'a ta tete et surtout en ne l'assumant pas, c'est ca le plus insupportable. Oui, c'est bien mon serveur, le problème ne vient pas du tout de "/dev/sdc ou /dev/sda", avant de poster j'ai évidemment testé, avec les 2 devices en sda et sdc, même réponse de Grub. Bien sur, Grub intervient alors que /dev n'existe meme pas encore. Les membres de l'association retrouvent un serveur bien fonctionnel. Qui ne serait peut-etre jamais tombe en panne si tu n'avais pas l'habitude de toucher a des trucs qui ne doivent pas l'etre, mais comme tu ne nous donnes jamais aucune information sur le pourquoi de ces manipulations... L'essentiel est que l'action réussisse. Tu compares des choses que ne le sont pas vraiment. Le 16/01/2018 à 20:25, Pascal Hambourg a écrit : > Ou simplement utiliser l'hibernation (suspend to disk). Je fuis ce truc qui est juste bon a foutre en l'air le mecanisme d'amorcage en cas de loupe pour un apport fonctionnel fort faible voire nefaste. -- Cordialement, Stephane Ascoet
Re: update-grub2
Le 16/01/2018 à 10:22, Stephane Ascoet a écrit : Mais franchement vu les quantites de RAM des ordinateurs actuels, il faut vraiment avoir un usage de folie pour avoir besoin de fichier d'echange!!! Ou alors etre un vieux chieur comme moi qui utilise des ordinausores Ou simplement utiliser l'hibernation (suspend to disk).
Re: update-grub2 : résolu
Le 16/01/18 à 13:32, andre_deb...@numericable.fr a écrit : AF> "Pire" encore, dans la "non-conformité", j'ai même re-rédigé AF> le fichier "/boot/grub/grub.cfg" à la mano. C'est effectivement déconseillé car c'est un fichier généré automatiquement, ce sont les sources de cette génération qu'il vaut mieux modifier (dans /etc/grub.d ou /etc/default/grub). Mais si tu tiens à ta façon de faire, gardes-en une copie car il sera écrasé à la prochaine màj de grub ou du noyau, ou à la prochaine commande grub. -- Daniel Le carré est un triangle qui a réussi, ou une circonférence qui a mal tourné… Pierre Dac
Re: update-grub2 : résolu
On Tuesday 16 January 2018 10:22:45 Stephane Ascoet wrote: > Quant aux problemes d'Andre je n'ai meme pas envie > d'y reflechir pour au moins ces raisons: > -il n'a pas pris la peine de nous faciliter la tache dans sa question > sur le renommage de sda en sdb; > -Il nous repose une question du meme style qui est peut-etre sur la meme > machine, sur laquelle il a fait des choses non conformes a un usage > normal en depit de nos conseils et revient la tout innocent comme si de > rien n'etait et comme si on ne le connaissait pas; > -Si c'est une autre machine, tiens comme c'est bizarre, le meme genres > de problemes... qui viennent peut-etre plutot de ce qui se trouve entre > la chaise et le clavier... > Cordialement, Stephane Ascoet Humm, ici le "cordialement" est de trop. Peu importe que ce soit sur un ordinateur perso ou un serveur à device (/dev/disque dur) renommé. Oui, c'est bien mon serveur, le problème ne vient pas du tout de "/dev/sdc ou /dev/sda", avant de poster j'ai évidemment testé, avec les 2 devices en sda et sdc, même réponse de Grub. > Quant aux problemes d'André je n'ai meme pas envie > d'y reflechir pour au moins ces raisons... Je ne t'ai rien demandé personnellement, je n'ai vraiment pas besoin de tes réflexions, surtout pour ce type de réponse. Le problème est résolu à 100%, Grub refonctionne avec mon disque en /dev/sda. "Pire" encore, dans la "non-conformité", j'ai même re-rédigé le fichier "/boot/grub/grub.cfg" à la mano. Les membres de l'association retrouvent un serveur bien fonctionnel. Si dans ma vie, j'avais toujours adopté la pensée unique de la conformité, je serais resté un chômeur invétéré au RSA. Dans le domaine de la voile, la conformité dit qu'en cas de tempête, il faut baisser le foc et jouer avec la grand voile. J'ai fait exactement le contraire un jour de grand vent, levé le foc, baissé la grand voile, et j'ai sauvé ma vie. L'essentiel est que l'action réussisse. André
Re: update-grub2
Le 16-01-2018, à 10:22:45 +0100, Stephane Ascoet a écrit : [snip] -il n'a pas pris la peine de nous faciliter la tache dans sa question sur le renommage de sda en sdb; -Il nous repose une question du meme style qui est peut-etre sur la meme machine, sur laquelle il a fait des choses non conformes a un usage normal en depit de nos conseils et revient la tout innocent comme si de rien n'etait et comme si on ne le connaissait pas; Mais si on le connaît notre André :) -Si c'est une autre machine, tiens comme c'est bizarre, le meme genres de problemes... qui viennent peut-etre plutot de ce qui se trouve entre la chaise et le clavier... Alors même machine ou autre machine ? Qui ouvre les paris ? En passant une newz qui lui fera plaisir: http://www.lemagit.fr/actualites/450433173/Barcelone-veut-son-poste-de-travail-Open-Source
Re: update-grub2
Le 15/01/2018 à 20:25, steve a écrit : Sous-entendu que la tête passe plus de temps au centre que vers l'extérieur. Mais est-ce bien le cas ? On pourrait se dire que ce serait Bonjour, je le fait aussi mais plutot en raison de l'argument comme quoi le debit est plus important a l'exterieur qu'a l'interieur(et oui: un disque dur commence par l'exterieur, comme un disque microsillon et non comme un CD). Mais franchement vu les quantites de RAM des ordinateurs actuels, il faut vraiment avoir un usage de folie pour avoir besoin de fichier d'echange!!! Ou alors etre un vieux chieur comme moi qui utilise des ordinausores :-D Quant aux problemes d'Andre je n'ai meme pas envie d'y reflechir pour au moins ces raisons: -il n'a pas pris la peine de nous faciliter la tache dans sa question sur le renommage de sda en sdb; -Il nous repose une question du meme style qui est peut-etre sur la meme machine, sur laquelle il a fait des choses non conformes a un usage normal en depit de nos conseils et revient la tout innocent comme si de rien n'etait et comme si on ne le connaissait pas; -Si c'est une autre machine, tiens comme c'est bizarre, le meme genres de problemes... qui viennent peut-etre plutot de ce qui se trouve entre la chaise et le clavier... -- Cordialement, Stephane Ascoet
Re: update-grub2 : résolu mais...
On Sunday 14 January 2018 19:37:35 Haricophile wrote: > Le Sun, 14 Jan 2018 19:00:16 +0100, andre_deb...@numericable.fr a écrit : > > Grub semble trouver la partition n° 1 (racine) > > mais pas /dev/sda2... et les autres. > > Comment créer le menu Grub avec toutes les partitions citées ? > > (création de grub.cfg) Grub semble réparé. J'ai recopié le répertoire /boot/grub sur toutes les partitions Linux. il détecte maintenant toutes les partitions rapidement de sda1 à sda7. Par contre, je trouve le fichier "/boot/grub/grub.cfg" très volumineux (142Ko et 2.771 lignes), et les partitions de /dev/sda2 à sda7 n'ont pas toujours leur bon UUID. Exemple : $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-4.4.0-109-generic-root=UUID=3ba3cb5b-5a71-4d13-90d2-dcdfbea7b3b8 ro single-6af32adf-87c5-4c3f-b390-9727185169ef' ... Dans un même menuentry /dev/sda5, deux UUID différents : 3ba3cb5b-5a71-4d13-90d2-dcdfbea7b3b8 = /dev/sda1 6af32adf-87c5-4c3f-b390-9727185169ef = /dev/sda5 Bonne soirée, André
Re: update-grub2
Le 15 janv. 2018 20:25, "steve" a écrit : Le 15-01-2018, à 16:52:44 +0100, hamster a écrit : Le 14/01/2018 à 19:00, andre_deb...@numericable.fr a écrit : > >> avec 4 partitions principales (/dev/sda1, sda2, swap et sda4 étendue) >> et trois partitions logiques sda5 à sda7. >> > > C'est hors sujet par rapport a grub, mais je met la partition swap en > premier pour que la tete de lecture du disque ait moins de chemin a > parcourir quand l'ordi swappe. > Sous-entendu que la tête passe plus de temps au centre que vers l'extérieur. Mais est-ce bien le cas ? On pourrait se dire que ce serait plus optimisé de le mettre au centre (moins de chemin à parcourir en moyenne). J'en sais à vrai dire rien, mais j'imagine que ça dépend fortement du partitionnement lui-même et du type d'utilisation de la machine. Intuitivement, je dirais que la tête doit être un peu n'importe où au gré des accès. Après, si on est certain de la partition la plus lue, ça doit pouvoir accélérer les choses de mettre le swap à proximité. Mais ça fait l'hypothèse que c'est plus avantageux de faire osciller une tête entre deux positions proches. Est-ce que tous les disques ont des têtes synchrones, où est-ce que les têtes peuvent être décalées entre elles ? À mon avis il vaut mieux en rester à : "swapper c'est lent, évitons au maximum de le faire" et laisser tomber le reste. Un truc qui est paraît-il vraiment efficace si on souhaite swapper plus vite, et qui ne repose pas sur des hypothèses au sujet du fonctionnement des disques, c'est de faire plusieurs swaps sur des disques différents, et laisser le noyau paralleliser les accès au swap. Cordialement
Re: update-grub2
Le 15-01-2018, à 16:52:44 +0100, hamster a écrit : Le 14/01/2018 à 19:00, andre_deb...@numericable.fr a écrit : avec 4 partitions principales (/dev/sda1, sda2, swap et sda4 étendue) et trois partitions logiques sda5 à sda7. C'est hors sujet par rapport a grub, mais je met la partition swap en premier pour que la tete de lecture du disque ait moins de chemin a parcourir quand l'ordi swappe. Sous-entendu que la tête passe plus de temps au centre que vers l'extérieur. Mais est-ce bien le cas ? On pourrait se dire que ce serait plus optimisé de le mettre au centre (moins de chemin à parcourir en moyenne). J'en sais à vrai dire rien, mais j'imagine que ça dépend fortement du partitionnement lui-même et du type d'utilisation de la machine.
Re: update-grub2
Le 14/01/2018 à 19:00, andre_deb...@numericable.fr a écrit : > avec 4 partitions principales (/dev/sda1, sda2, swap et sda4 étendue) > et trois partitions logiques sda5 à sda7. C'est hors sujet par rapport a grub, mais je met la partition swap en premier pour que la tete de lecture du disque ait moins de chemin a parcourir quand l'ordi swappe.
Re: update-grub2
On Sunday 14 January 2018 19:37:35 Haricophile wrote: > Le Sun, 14 Jan 2018 19:00:16 +0100, > andre_deb...@numericable.fr a écrit : > > Grub semble trouver la partition n° 1 (racine) > > mais pas /dev/sda2... et les autres. > > Comment créer le menu Grub avec toutes les partitions citées ? > > (création de grub.cfg) > Ton disque ne serait pas en gpt/efi ? En ce cas utiliser grub-efi > serait fortement conseillé. Non et il fonctionnait avec update-grub2
Re: update-grub2
On Sunday 14 January 2018 19:12:53 Michel wrote: > Le 14/01/2018 à 19:10, andre_deb...@numericable.fr a écrit : > > Mon ordinateur possède un seul disque dur /dev/sda, > > avec 4 partitions principales (/dev/sda1, sda2, swap et sda4 étendue) > > et trois partitions logiques sda5 à sda7. > > sda1, sda2, sda5, sda6 et sda7 = GNU/Linux en ext4, installé. > > # update-grub2 > > Création du fichier de configuration GRUB... > > Image Linux trouvée : /boot/vmlinuz-4.4.0-109-generic > > Image mémoire initiale trouvée : /boot/initrd.img-4.4.0-109-generic > > Failed to probe /dev/sda2 for filesystem type > > Failed to probe /dev/sda5 for filesystem type > > Failed to probe /dev/sda6 for filesystem type > > Failed to probe /dev/sda7 for filesystem type > > Grub semble trouver la partition n° 1 (racine) > > mais pas /dev/sda2... et les autres. > > Comment créer le menu Grub avec toutes les partitions citées ? > > (création de grub.cfg) > Mais tu as un système installé sur chaque partition? : Oui, comme je l'ai indiqué ci-dessus.
Re: update-grub2
Le Sun, 14 Jan 2018 19:00:16 +0100, andre_deb...@numericable.fr a écrit : > Grub semble trouver la partition n° 1 (racine) > mais pas /dev/sda2... et les autres. > > Comment créer le menu Grub avec toutes les partitions citées ? > (création de grub.cfg) > > Merci, André Ton disque ne serait pas en gpt/efi ? En ce cas utiliser grub-efi serait fortement conseillé.
Re: update-grub2
Le 14/01/2018 à 19:10, andre_deb...@numericable.fr a écrit : > Bonsoir, > > Mon ordinateur possède un seul disque dur /dev/sda, > avec 4 partitions principales (/dev/sda1, sda2, swap et sda4 étendue) > et trois partitions logiques sda5 à sda7. > > sda1, sda2, sda5, sda6 et sda7 = GNU/Linux en ext4, installé. > > # update-grub2 > Création du fichier de configuration GRUB... > Image Linux trouvée : /boot/vmlinuz-4.4.0-109-generic > Image mémoire initiale trouvée : /boot/initrd.img-4.4.0-109-generic > Failed to probe /dev/sda2 for filesystem type > Failed to probe /dev/sda5 for filesystem type > Failed to probe /dev/sda6 for filesystem type > Failed to probe /dev/sda7 for filesystem type > > Grub semble trouver la partition n° 1 (racine) > mais pas /dev/sda2... et les autres. > > Comment créer le menu Grub avec toutes les partitions citées ? > (création de grub.cfg) > > Merci, André > Mais tu as un système installé sur chaque partition?
update-grub2
Bonsoir, Mon ordinateur possède un seul disque dur /dev/sda, avec 4 partitions principales (/dev/sda1, sda2, swap et sda4 étendue) et trois partitions logiques sda5 à sda7. sda1, sda2, sda5, sda6 et sda7 = GNU/Linux en ext4, installé. # update-grub2 Création du fichier de configuration GRUB... Image Linux trouvée : /boot/vmlinuz-4.4.0-109-generic Image mémoire initiale trouvée : /boot/initrd.img-4.4.0-109-generic Failed to probe /dev/sda2 for filesystem type Failed to probe /dev/sda5 for filesystem type Failed to probe /dev/sda6 for filesystem type Failed to probe /dev/sda7 for filesystem type Grub semble trouver la partition n° 1 (racine) mais pas /dev/sda2... et les autres. Comment créer le menu Grub avec toutes les partitions citées ? (création de grub.cfg) Merci, André