update-grub2

Le 16/01/2018 à 13:32, andre_debian@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

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.

Le 15/01/2018 à 23:52, andre_debian@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;a3cb5b-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.

Le Wed, 17 Jan 2018 20:52:20 +0100,
Pascal Hambourg <pascal@plouf.fr.eu.org> 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 t rè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 co mme si
le hardware était libre...

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.

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.

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.

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.

Le 20/01/2018 à 18:54, andre_debian@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