Bonjour
je rencontre un problème récurrent depuis quelques mois : à chaque mise à jour du noyau, au prochain reboot, je suis bloqué juste après le GRUB, avec affichage de "Chargement du disque mémoire initial", et plus rien ne bouge ...
Je suis donc obligé de redémarrer en "mode fallback", qui fonctionne pour le moment, et de faire un
mkinicpio -p linux4xx
Ensuite, je peux redémarrer en mode normal (sauf avec les noyau 4.16 et 4.18 qui eux m'empêche de démarrer en mode normal et en fallback !)
J'ai donc installé le 4.19 RC3 en attendant, et il fonctionne bien pour ma machine.
comme indiqué, en changeant de place autodetect et block , exécuter un mkinitcpio , et cela a fonctionné.
Le problème est que je suis toujours obligé de faire ce mkinitcpio après chaque mise à jour du noyau, ce qui ne me semble pas normal , vu que cela arrive avec toutes les versions du noyau, depuis la 4.3 jusqu'à la 4.19 actuelle ...
Quelqu'un a une idée du problème ?
Merci pour votre aide
EDIT 25/10/2018 : après plusieurs MAJ , pas de réapparition de ce problème, je passe donc le sujet en résolu Merci à tous
Dernière modification par Aponia71il y a 5 ans, modifié au total 2 fois.
Bonjour.
Normalement, à chaque mise à jour du noyau, une régénération du kernel se lance automatiquement. Tu ne devrais utiliser mkinitcpio que lorsque tu modifies un paramètre propre.
Quelle image as tu installée ?
Donne nous le retour de inxi -Fx000
Noyau récent MANJARO x86_64 bits: 64 Xfce 4.16
ASUSTeK model: PRIME B350M-A v: Rev X.0x
6-Core: AMD Ryzen 5 2600X
AMD Baffin [Radeon RX 460/560D / Pro
driver: amdgpu v: kernel
Display: x11 server: X.Org driver: amdgpu,ati unloaded: modesetting
OpenGL: renderer: Radeon RX 560 Series
Arch en Dual. Aucun lien publicitaire ne saurait être toléré dans la signature!
Bonjour,
Tu as une jolie collection de disques Plus sérieusement, il serait intéressant de voir de plus près quels disques ou partitions sont montés automatiquement : cat /etc/fstab ainsi que les paramètres d’amorçage du noyau (s'il y en a) : cat /etc/default/grub | grep GRUB_CMDLINE
Pour info, le kernel 416 n'est plus dans les dépôts, pour le vérifier : yaourt -Qam ou pacman -Qem si yaourt non installé.
Le désinstaller par sudo mhwd-kernel -r linux416
Manjaro-Xfce-Compiz 64
Desktop
CPU amd-phenom-64(pci=nomsi dans grub)
CG nvidia GeForce GT 730
Ram : 4 Go
kernel : 54 branche : stable, driver GPU : Nvidia-non-libre
Perso je tenterai de virer** acpi_enforce_resources=lax en mode normal plutôt que de démarrer en fallback
** Sans modifier le fichier de conf de grub mais en éditant la ligne du kernel au démarrage
Manjaro-Xfce-Compiz 64
Desktop
CPU amd-phenom-64(pci=nomsi dans grub)
CG nvidia GeForce GT 730
Ram : 4 Go
kernel : 54 branche : stable, driver GPU : Nvidia-non-libre
Perso je tenterai de virer** acpi_enforce_resources=lax en mode normal plutôt que de démarrer en fallback
** Sans modifier le fichier de conf de grub mais en éditant la ligne du kernel au démarrage
Oui il y a 2 ans j'avais testé ce paramètre pour que sensors détecte bien les ventilo, afin que je puisse réduire leur vitesse (d'ailleurs çà ne marchait pas bien je crois)
Mais là cette ligne est en commentaire ... du coup le paramètre acpi_enforce_resources=lax n'apparait nulle part dans le code de grub en mode édition.
Sinon, hier soir il y a eu une nouvelle MAJ du noyau 4.19 (et 4.18 je crois), et je n'ai pas eu de blocage , pas eu besoin de faire de mkinicpio -p linux419
A priori il n'y a pas de solution triviale, on dirait un bug ou un concours de circonstances
Je vais donc surement fermer le sujet à la prochaine MAJ du noyau si elle se passe bien
Re...
Bon , nouvelle MAJ des noyaux ce soir, et pas de blocage avec la 4.19RC7.
Donc a priori, je suppose que c'était une incompatibilité entre les versions qui m'ont bloqué, et mon matériel....