Forum

yop a tous

rien de bien gravissime, mais comme indique dans le titre j'ai un ptit soucis lors de l'arrive d'un nouveau kernel

j'explique: il y a quelque jours j'ai vu passer une maj kernel (le 4.14.16), mais au redemarrage suivant mon conky me donne toujours le 4.14.10 ...
n'etant pas d'humeur a fouiller la raison (c'est peut etre mon conky qui bug ... ou le kernel qui s'est mal installe ...) bref je laisse couler
mais hier soir juste avant de couper le pc pour aller pioncer, je recois une nouvelle maj kernel (le 4.14.20) ... je fais donc la maj et coupe le pc
ce matin au lancement je surveille mon conky ... et je suis toujours en 4.14.10

bon la je m'inquiete
direction le ccm -> demarrage -> configurer le demarrage du systeme
et la dans la 2eme page je trouve bien les derniers kernel installe ... mais c'est toujours le 4.14.10 qui est selectionne
je selectionne donc le dernier ... reboot ... et nickel je suis bien avec mon dernier kernel

question: pourquoi il me l'active pas (plus ?) automatiquement apres la maj ?

merci si quelqu'un peut m'eclairer la dessus

Bonjour,
C'est une très bonne question.
C'est une modification des paramètres de Grub qui doivent le permettre.
Cela voudrait dire que la configuration de grub après l'installation n'a pas fonctionné ou ne s'est pas lancée.

Bonjour, je me demande si je n'ai pas déjà eu ce soucis et l'ai résolu en réinstallant le kernel en question ?

salut
je crois que j'ai un problème identique : j'ai deux mageia6 installée sur la même machine, et la seconde n'est pas encore passée en cauldron; donc elles sont identiques, à part les bureaux;
hier soir, je vois passer la maj pour le kernel 4.14.20 sur celle de travail (sur sdb1)
bon je me dis que j'allais aussi mettre à jour celle sur sda3; je fais la maj , tout est Ok;
sauf que lorsque je lance celle sur sdb1, elle est bien avec le kernel 4.14.20 tandis que celle sur sda3 est restée sur le précedent 4.14.18;
je pense que cela vient du grub;
sdb1, c'est avec celle là que j'ai refait le grub sur sda et sur sdb en dernier, et elle se met à jour normalement;
je pense que la solution sera de refaire à nouveau le démarrage dans le CCM pour qu'il prenne en compte la maj sur sda3.
je vais de ce pas le faire et vous dire le résultat
A+

Ok ça fonctionne, je suis actuellement sur sda3 et elle est bien avec le dernier kernel 4.14.20 mis à jour hier soir;
la solution a donc été d'aller dans le CCM, menu démarrage et refaire une installation du grub sur sda;
ça ne s'est pas fait automatiquement avec celle là, je pense parce que ce n'est pas la "principale" (celle avec qui j'ai justement fait cette opération dans le CCM; )
en fait cela à l'air assez subtil : la mise à jour du grub n'a lieu qu'avec la distribution qui a elle même installée le grub, le grub lui appartient en quelque sorte; pour l'autre, elle n'est qu'une "invitée", lors de sa mise à jour, le grub n'est pas modifié, et reste donc sur la version antérieure.

A+

Ma foi, c'est une explication qui se tient.
Mais comment grub sait-il que ce qui est installé pour l'amorçage n'est pas de lui mais d'un autre système parallèle ?

Salut,

Désolé, je suis presque hors-sujet.

J'ai procédé à ladite mise à jour aujourd'hui, suite à quoi on demande de redémarrer pour kernel-desktop-quelquechose.
Quand soudain, il est 13h pile.
Quelques secondes après le passage de l'heure, l'ordi freeze.
(je suspectais déjà le passage d'heure de pouvoir être parfois à l'origine de bugs, mais rarement, et sans preuve)

Depuis l'époque de Winchows, je crois qu'il existe une différence entre "redémarrer" le système, et "éteindre puis démarrer".
Je crois que ça a son importance lors d'installation ou mise à jour.
Je crois que c'est un peu différent sur Linux.
Cela-dit, quand c'est demandé gentiment, je veux bien faire plaisir.

Ma question :
Quand on me demande de redémarrer et que je ne peux pas (par exemple dans le cas ci-dessus), un redémarrage "sauvage" (via le bouton physique laissé appuyer assez longtemps) fait-il l'affaire ?
Ou dois-je éteindre, rallumer, pour redémarrer ?

En tout cas (mais je maintiens ma première question), dans CCM/Démarrage/Config le dém syst, sur la seconde page, c'est bien chez moi la 4.14.20.

Papoteur
"Ma foi, c'est une explication qui se tient.
Mais comment grub sait-il que ce qui est installé pour l'amorçage n'est pas de lui mais d'un autre système parallèle ? "

Eh bien, j'en sais trop rien; c'est une explication que je me suis imaginé d'après le comportement observé;
à priori, chaque OS dans une partition, a son /boot propre qui lui appartient; il peut donc le mettre à jour;
mais ça commence par le MBR qui renvoit vers /boot de la partition choisie;
or, ce MBR il est unique à tout le système;
je ne sais pas comment sont organisés les droits sur ce record;
ce qu'il me semble, c'est que la mageia sur sdb1 c'est celle avec laquelle j'ai fait ce MBR via le CCM et lors de la mise à jour, la dernière version est prise en compte, car elle doit avoir des droits sur le MBR que n'a pas celle sur sda3;

dulbi

le coup du bug de l'an 2000 au passage des 00h, c'est effectivement hors sujet.
après un freeze, éteindre et laisser un peu "refroidir", c'est pas plus mal;
sinon, dans le cas normal d'une mise à jour qui se passe bien, redémarrer le système, c'est pas urgent; ça peut attendre jusqu'au prochain boot, qui peut n'arriver que le lendemain à moins que tu sois pressé de tester la maj car elle règle un bug peut être qui te gènes;

A+

Auquel cas, un simple boot se substituerait à un reboot.?

Bonjour



Vu que tu as connu un freeze, tu n'avais pas d'autres solutions. Il faut espérer que ce genre de problème ne se produise pas juste au moment où une mise à jour du kernel à lieu. Dans ce cas, il faut forcer le démarrage sur l'ancien kernel depuis l'écran d’accueil du démarrage de ton système (bref Grub 2) et retenter la mise à jour.....

Ce n'était pas le cas puisque l'installation du dit kernel était terminée. Tu risquais peut être un petit problème au niveau des partitions de ton disque , mais au démarrage il aurait indiqué le soucis et sans doute proposé un fsck pour vérifier les disques.

Après il faudrait voir si ton système était vraiment gelé. Parfois il s'agit de la couche graphique qui plante. Dans ce cas précis, on peut contourner le problème en faisant un CTRL+ALT+F2 pour ouvrir une session en mode texte sous root, puis en tapant un "shutdown -Fr" pour forcer le reboot

Ca c'est au moins l'info du jour pour moi.
Merci pour toute cette réponse.

bonjour

à propos de mise à jour de kernel et de grub, il semblerait que fedora se comporte de la même façon :
hier soir, il y a eut une mise à jour sur fedora27; je la fait et je relance le système : il est resté sur le kernel précédent;
j'arrête, je relance la mageia6 "principale", dans le CCM je régénère le démarrage sur sda et j'arrête;
je relance option avancée pour fedora et le nouveau kernel était là;

mais cela reste assez énigmatique puisque je ne sait pas exactement comment ça marche, mais il y a bien une notion de propriétaire pour le MBR.

Bonjour,

Il faut, effectivement, faire la mise à jour de chaque Grub indépendamment. C'est d'ailleurs pour cette raison que je me "casse la tête" un seule fois (un petit effort, faut quand même pas pousser, heing !)pour paramétrer mon grub principal afin de les cascader. Rien compris ? Après chaque mise à jour d'un noyau (peu importe la distribution), il faudra toujours remettre à jour le paramétrage du grub correspondant. Pour une seule distribution installée, pas de problème. Mais dans le cas de plusieurs, il faut aller dans chacune des distributions et le Grub maître n'est alors plus à jour parfois. L'idée est donc que le Grub maître pointe systématiquement vers chaque Grub secondaires, qui eux seront systématiquement à jour (sauf cas particulier). Ainsi, le Grub maître pointera toujours vers le dernier noyau. Les détails de la manipulation sont dans le Wiki :
https://www.mageialinux-online.org/wiki/grub2-personnalisation

je constate que ce fil derape vers ceux qui ont un multi boot
meme si ca reste interressant pour les concernes, je precise que ce n'est pas mon cas

perso j'attend la prochaine maj kernel "pour voir"

salut et excuse moi d'avoir squatté ton post;
mais il me semble que c'est bien le même problème, puisque c'est en tout cas la même solution qui marche, c'est à dire de refaire le démarrage avec le CCM;
le fait d'être en multiboot fait juste que le problème apparaît plus souvent;
et le wiki indiqué par teutates est une excellente piste pour régler ce problème et mieux comprendre le grub et son organisation.
merci au passage!
alors toi tu dis que ça marchait normalement (en simple boot) et puis la dernière fois ça n'a pas marché; et il t'a fallu intervenir avec le CCM pour que le dernier kernel soit pris en compte; en fait, étant en simple boot, ça n'aurait pas du arriver; effectivement, quand j'étais en simple boot avec mageia5, j'ai pas souvenir de ce genre de problème; c'est spécifique aux systèmes multiboot;
A+