Forum

Bonjour à tous,

Hier je fais la mise à jour qui m'est proposée. Elle inclut le kernel 4.14.
Ce matin au démarrage, plantage à la fin de la phase de détection des périphériques USB.

Je passe en failsafe et je vois que grub lance (hd0,5) root=/dev/ . Je corrige et je vois ensuite que /etc/fstab a lui aussi perdu la racine…

Je remets tout bien avec l'UUID de ma racine, j'enlève quiet et splash pour observer et toujours le même plantage à la fin de la détection des USB

Comme j'ai toujours un disque usb bootable, je décide de démarrer dessus. Lui, aussi a reçu sa mise à jour hier. J'ai un souci de uid=500 pour mon user de base au lieu de uid=1000 que je corrige puis je redémarre. Plantage derechef !

Finalement je démarre sur un mageia i586 et il m'est proposé la maj vers le noyau 4.14. J'ai toujours mon souci de uid=500 pour mon user que je corrige avec un chown -R mais ça marche. Je ne vais pas passer vers 4.14 car je soupçonne que ce soit mon souci. A suivre et étayer si d'autres ont eu le même souci. ça fait deux heures que je suis là-dessus sans trouver de solution…

Édité par Ami age Le 08/01/2018 à 19h12

(hier,
j'ai eu des plantages graphiques avec le 4.14
étant un peu bousculé, pour assurer sans encombre, au redémarrage suivant, j'ai choisi le noyau précédent
faudrait que je relance le 4.14 pour voir)

pas de pb chez moi ...

Bonjour

Pas de soucis également chez moi. Peut être aurais tu pu essayer de démarrer avec l'ancien noyau via le grub pour voir..

ça plantait également avec l'ancien noyau.

En fait c'est certainement lié au fait que mes partitions étaient dans le désordre sur /dev/sda suite à des changements multiples qui jusqu'alors n'avaient posé aucun souci (sda5 n'existait plus, sda6 contient la racine suivi de sda8 la swap, suivi de sda7 le /home).

J'ai supprimé la racine, la swap et je les ai recréées puis net install avec 4.14 et ça marche. (cette fois, j'ai sda5=racine, suivi de sda7=swap suivi de sda6=home).

Je vais redémarrer avec mon disque USB pour creuser un peu . Je vous tiens au courant..

C'est peut être plus lié à la configuration de grub avec le nouveau noyau plutôt qu'au noyau lui-même.

C'est exactement la conclusion que je suis en train de tirer Papoteur. Le changement de noyau implique la réinstallation de grub et dans ma configuration très particulière, ça a tout planté probablement à cause de la détection automatique des autres OS !

Voici ce que j'ai comme partitions :
- disque sata interne
sda1=win, sda2=win sda5=/ (mga6 en x86-64) sda6= swap sda7=/home

- disque usb
sda1=/(mga6 en x86-64), sda5=/(mga6 en i586) sda6=swap sda7=/home sda8=/sauvegarde

(sda ou sdb cela dépend de ce que je démarre bien sûr)

Et en fait, ça ne plante pas tout à fait : au bout de plusieurs minutes (environ 10), ça finit par se lancer et je trouve des bizarreries soit dans le lancement grub soit dans le fstab (cette fois-ci : les deux swap sont montées !)


Je ne vais pas pouvoir faire un rapport de bogue car j'ai fait tellement de tests que ce n'est plus très clair dans mon esprit.

Édité par beuz Le 07/01/2018 à 12h33

Bonjour
J'ai aussi des soucis avec la 4.14. x
je ne suis pas chez moi, mais j'avais testé des noyaux 4.14 1,2,5,9 et mon poste avec processeur AMD A8 n'accepte que me 4.14.1 , les autres noyaux bloquent le boot curieusement. Ce poste a 3 disques durs. (rapport de bogue éventuel dans quelques jours pour le 4.14.10.)
Mon poste avec un un processeur AMD A4 accepte les noyaux 4.14 essayés; de même que les postes à processeur Intel.

J'ai sous la main mon petit portable Inote Anyware avec un processeur AMD E1 "ESSENTIAL" que je n'ai jamais pu mettre en veille ( erreur au retour, et boot normal, même avec Mageia5).
L’hibernation fonctionne, et me fait gagner bien 50 seconde au lancement, mais pas avec un noyau 4.14. X qui me fait un écran noir a la reprise..
Je suis donc revenu au boot avec le noyau 4.9.50

(redemarré en 4.14 sur ma config, (q9550 + HD5770), c'est bon, ça tourne )

Hello,
un kernel 4.14???? Proposé depuis hier????
Rien de cela chez moi, n'y aurait il pas confusion avec le kernel 4.4.105-1 proposé en toute fin d'année 2017 et qui faisait suite au 4.4.92-1?

EDIT: j'ai posté trop vite ayant eu un pb aussi sur 1 PC en upgradant de 4.4.92 en 4.105 mais sur Mageia5...
ici 4.14 sans doute Mageia6
pour éviter cela ce serait bien de donner la version de Mageia quand on expose son pb!

Édité par kalagani Le 08/01/2018 à 16h57

merci pour la remarque, j'ai édité le titre du sujet

Plantage au demarrage (ecran noir) lors du passage de VM sur le nouveau kernel 4.14.10. Le kernel 4.14.10 plante aussi en mode recovery.
le dernier message est booting smp configuration puis plus rien, quelques lignes plus haut le message précédent le plus louche etait
unsupported P6 cpu model ...
je soupconne donc un patch de securité pour la faille intel decouverte recemment de faire planter cette version de kernel sur cette VM mageia6 par contre j'ai un autre PC portable en mageia6 pour lequel le passage à ce nouveau kernel n'a pas posé de problème ...

Bonjour
Sur ma machine (AMD A8) avec 3 disques dont un en UEFI, le noyau 4.14.10 ne convenait pas :
blocage du chargement sur les lignes :
" Finished initializing topology ret=0
kfd kfd: Initialized module
fb: switching to radeon mfb from EFI VGA "

le noyau 4.14.1 fait pareil en mode reparation, mais avec 2 lignes de plus, par contre en mode normal il boote normalement.

Comme le système date de Cauldron, installé à partir de la 5 , j'ai relancé l'installation de la 6 :
problème de blocage en mode mise à jour. Il y a bien une chose suspecte dans le système.

J'ai donc réinstallé Mageia6 et Plasma avec formatage du système ( mais pas le /home) et media Internet.
La partition EFI est bien trouvée sur un autre disque.
Au reboot c'est bien : le noyau 4.14.10 est opérationnel.

Édité par christian_fisch Le 12/01/2018 à 12h45

le nouveau kernel 4.14.13 n'a pas résolu le problème ... en ce qui me concerne en tout cas

Pareil pour moi : j'ai refait la même chose que la fois précédente, à savoir installation sur disque usb sur une machine X, lancement sur une machine Y. Dans les deux cas, présence de partitions enchevétrées et pas dans l'ordre (détectées en 1 7 5 6 8 ) = multiples désordres et instabilités sur kernel 4.14.18

J'ai ue l'idée de tester le kernel TMB car Thomas Backlund et son noyau m'avaient bien sorti d'affaire sur une machine récalcitrante voilà quelques années mais là, ça se terminait par un kernel panic donc j'ai voulu redescendre en 4.9.50 mais j'ai bien fini par me méanger les pinceaux donc retour en mga5 et ça roule.

J'aurais certainement dû tester l'option avancée de fdisk pour remettre les partitions dans le bon ordre car à chaque fois, c'était le premier indicateur et ensuite mes bidouillages ne faisaient qu'empirer les choses. Mais bon, j'y ai passé déjà beaucoup de temps.

Édité par beuz Le 14/02/2018 à 19h54