Aller au contenu principal
Sujet: Mise à Jour du jour ... Echec : Failled to start apply Kernel variables (Lu 3723 fois) sujet précédent - sujet suivant

Mise à Jour du jour ... Echec : Failled to start apply Kernel variables

Coucou les gens...
Ben oui... c'était trop beau que ça se passât bien... Bordel...
J'ai fait les 3200 paquets de mise à jour du Tumbleweed et voilà qu'au milieu de la mise à jour il plante complet... Devient tout noir de rage et m'affiche un écran de "Mode de sauvetage ou un truc dans le genre"
Message d'erreur :
[FAILED] Failed to start Apply Kernel Variables.
See `systemctl status systemd-sysctl.service` for details.
ou un truc dans le genre...
--
Je suis allé voir sur des forum et essayé uniquement la solution de mettre en "Remarque" une ligne du fichier /usr/lib/sysctl.d/50-default.conf
mais bien entendu ça fonctionne pas...

Du coup je suis bien paumé car j'arrive même pas à me connecter à Internet en mode console de secours pour rééssayer un zypper dup...

Os cours !!!
Si quelqu'un peut voler à mon secours
Amicalement
Philippe

Re : Mise à Jour du jour ... Echec : Failled to start apply Kernel variables

Répondre #1
Hello,

si tu as btrfs en systeme de fichiers pour la racine avec les snapshots activés, tu peux peut-être tenté les deux manips suivantes:

sudo snapper list

puis

sudo snapper remove (le numéro du snapshot APRES mise à jour

tu rebootes, et normalement tu retombes sur ton système avant la mise à jour.


A+

NB=Essaie peut être les commandes en root si tu es en console de secours

Re : Mise à Jour du jour ... Echec : Failled to start apply Kernel variables

Répondre #2
Bonsoir Luckyboy,
Nan, je suis en EXT4...
-
Pour l'instant je cherche des pistes car ça pue quand même la bonne vieille réinstall... Je suis pas vraiment à l'aise avec le Kernel... ça impressionne non ?

Amicalement
Philippe

Re : Mise à Jour du jour ... Echec : Failled to start apply Kernel variables

Répondre #3
essaie peut etre avec l'option d'upgrade de ton dvd ou clé d'install j'ai sauvé pas mal de maj foireuses comme ça.

Et essaie de voir aussi si ta racine n'est pas pleine, ce qui pourrait expliquer la plantade?

Re : Mise à Jour du jour ... Echec : Failled to start apply Kernel variables

Répondre #4
Bonsoir,

Avez-vous tenter en passant via un tty ?

Souvent ça permet de décoincer les problèmes de mises à jours

Re : Mise à Jour du jour ... Echec : Failled to start apply Kernel variables

Répondre #5
Bonsoir Gerinald,
En fait le système ne démarre même pas jusqu'à la possibilité d'une console classique (TTY).
Il s'arrête très tôt dans le démarrage, affiche le message "Failed to start Apply Kernel Variables" en rouge et s'arrête sur :
"You are in emergency mode. After logging in, type ... etc etc"
On peut alors se loguer en root mais c'est extrêmement limité ... Notamment l'accès a Internet n'est pas opérationnel et donc c'est impossible de faire un zypper quelconque...
Philippe

Re : Mise à Jour du jour ... Echec : Failled to start apply Kernel variables

Répondre #6
Bonsoir Luckyboy,

J'ai essayé effectivement avec une clé USB chargée avec la dernière version de TW mais ça n'a pas fonctionné.
Précisément, j'ai pu lancer un update qui s'est déroulé avec tout de même quelques erreurs de fichiers introuvable ... (mais ça me semblais pas être des fichiers vitaux...)
Mais malheureusement au redémarrage, bien que le nouveau Kernel semblait installé... (le 5.8)
ça re faisait la même erreur...
Il semble qu'il conserve des fichiers de paramétrage qui ont foiré initialement car lorsque je suis allé inspecter le fichier "/usr/lib/sysctl.d/50-default.conf" la modification que j'avais faite y était toujours...
Et... malheureusement ... Même après modification de ce fichier = toujours même erreur...
Je rage un peu là....
Amicalement
Philippe

essaie peut etre avec l'option d'upgrade de ton dvd ou clé d'install j'ai sauvé pas mal de maj foireuses comme ça.

Et essaie de voir aussi si ta racine n'est pas pleine, ce qui pourrait expliquer la plantade?

Re : Mise à Jour du jour ... Echec : Failled to start apply Kernel variables

Répondre #7
ah oui merde désolé mais je sèche là...

et l'état de ta racine? elle est pleine ou pas?

tu as essayé de démarrer avec noapic, acpi=off nomodeset dans les options du grub ou encore avec startx? (bon en même temps je serais bien incapable de te dire ce qui merde comme ça). Réinstallation de grub?

Re : Mise à Jour du jour ... Echec : Failled to start apply Kernel variables

Répondre #8
Salut,

Le problème ne vient pas forcément de ce message (Failed to start Apply Kernel Variables).
J'ai le même message au démarrage mais aucune implication négative.

D'après mon /var/log/boot.log, sur plusieurs démarrages, ce message intervient pendant le démarrage de Plymouth.

Soit juste avant ou juste après une de ces deux lignes :

[FAILED] Failed to start Apply Kernel Variables.
[  OK  ] Finished Tell Plymouth To Write Out Runtime Data.

[  OK  ] Finished Tell Plymouth To Write Out Runtime Data.
[  OK  ] Started Show Plymouth Boot Screen.
[FAILED] Failed to start Apply Kernel Variables.
See 'systemctl status systemd-sysctl.service' for details.
         Starting Tell Plymouth To Write Out Runtime Data...
         Starting Apply Kernel Variables...

Si ça peut aider tes recherches...


à plus,
oh!rocks

Re : Mise à Jour du jour ... Echec : Failled to start apply Kernel variables

Répondre #9
Bonjour les amis,

@Luckyboy : J'ai oublié de te répondre à propos du remplissage de mes volumes mais non, je suis à 32% pour la racine et aucun de mes volumes ne dépassent 60%

J'ai pas essayé encore la commande dans Grub ni de démarrer starx après log en console de secours Je tenterais.

@oh!rocks : C'est intéressant effectivement car ce matin, après une mise à jour sur mon portable (qui est aussi sous TW mais n'a pas eu ce problème) j'ai fouillé dans le journal et Ô surprise :
Citer
Sep 19 12:46:26 Alienware systemd[1]: Starting dracut cmdline hook...
Sep 19 12:46:26 Alienware systemd[1]: systemd-sysctl.service: Main process exited, code=exited, status=1/FAILURE
Sep 19 12:46:26 Alienware systemd[1]: systemd-sysctl.service: Failed with result 'exit-code'.
Sep 19 12:46:26 Alienware systemd[1]: Failed to start Apply Kernel Variables.
Sep 19 12:46:26 Alienware systemd-journald[239]: Journal started
Voilà ce que j'y trouve ...
Pas après plymouth mais après la tentative de démarrage de systemd-sysctl....
Je continue mes zinvestigations....
Amicalement et bon WE
Philippe

Re : Mise à Jour du jour ... Echec : Failled to start apply Kernel variables

Répondre #10
Re re Bonjour,

Alors me revoici pour exposer mes quelques avancées.
Pas des moindres car j'ai partiellement réussi à réparer le truc...
--
Tout d'abord j'ai téléchargé la toute dernière version de TW (celle d'hier) et j'ai retenté l'update à partir d'une clé USB.
Ce coup ci je n'ai pas eu d'erreurs pendant l'update mais ça démarrait toujours pas, enfin, j’étais rendu presque au même point : la console de secours... Mais sans le message à propos de Kernel Apply variable...

Du coup en faisant un journalctl - xn je trouve une autre erreur ... Une histoire d'impossibilité de passer au Runlevel supérieur... (désolé j'ai pas noté la phrase exacte)  et je me rends compte que certains de mes disques n'ont pas été monté au démarrage...
Essentiellement les partition NTFS...
Du coup je les met en remarque dans le FSTAB...
Et là ça démarre ....
J'arrive jusqu'à l'écran de login et sur mon bureau....
-
Cependant il y a encore plein de ligne en jaune dans le journal de boot et je suis obligé de monter à la main les deux partitions NTFS...
---
Faut que je revois le FSTAB ce qui ne va pas ...
Si vous avez une idée voici ci-dessous :
Citer
UUID=564cc653-21d5-44a8-9377-66ec937774c7 /          ext4  acl,user_xattr  0  1
#/dev/disk/by-id/ata-SanDisk_SDSSDH2256G_130504401275-part3  /          ext4  acl,user_xattr  0  1
UUID=dbe1f71d-b0ff-45cf-a41d-05b2ceb5d28f /usr       ext4  acl,user_xattr  0  2
#/dev/disk/by-id/ata-SanDisk_SDSSDH2256G_130504401275-part4  /usr       ext4  acl,user_xattr  0  2
UUID=92eb863b-1da2-4be4-9b86-7b6a51fdaf1e  /home      ext4  acl,user_xattr  0  2
UUID=9845-5C40  /boot/efi  vfat  codepage=437    0  0
# UUID=41fc41eb3b22eff1 /WIN7      ntfs  auto,user,rw,users,gid=users,umask=0002,locale=fr_FR.UTF-8  0  0
#/dev/disk/by-id/ata-SanDisk_SDSSDH2256G_130504401275-part1  /WIN7      ntfs  user,rw,users,gid=users,umask=0002,locale=fr_FR.UTF-8  0  0
UUID=f3cef834-b6b8-4379-9afa-af830a4148f6 /OSVIRT    ext4  acl,user_xattr  0  2
#/dev/disk/by-id/ata-ST2000DM001-1CH164_W1E327DN-part2  /OSVIRT    ext4  acl,user_xattr  0  2
# UUID=6b8b025814eb6ae2  /EXCHANGE  ntfs  auto,user,users,gid=users,umask=0002,locale=fr_FR.UTF-8  0  0
#/dev/disk/by-id/ata-ST2000DM001-1CH164_W1E327DN-part3  /EXCHANGE  ntfs  user,users,gid=users,umask=0002,locale=fr_FR.UTF-8  0  0
#UUID=dbe0f71d-b0ff-45cf-a41d-05b2ceb5d28f   /usr   ext4   defaults   0   2

Amicalement Philippe

Re : Mise à Jour du jour ... Echec : Failled to start apply Kernel variables

Répondre #11
Re re re ...
Petite question à propos du FSTAB

Je n'ai pas trouvé d'explication convaincante à propos de l'utilisation du format UUID ou /dev/disk/by-id/....
En gros est ce que l'un d'entre vous sait s'il y a une réelle différence et si oui, dans quels cas il vaut mieux utiliser l'un ou l'autre des formats ?
Comme vous avez remarqué dans le mien de FSTAB j'avais initialement un espèce de mélange entre les déclarations de périphérique en UUID et en /dev...
J'ai unifié en UUID mais ça n'a pas empêché de merdé...

A vous lire
Philippe


 

Re : Mise à Jour du jour ... Echec : Failled to start apply Kernel variables

Répondre #13
Merci oh!rocks,

A priori je fais bien donc de tout passer en UUID...
Mais je ne m'explique pas ce qui s'est passé ...
En même temps aujourd'hui j'ai pas eu le temps d'investiguer....
Je verrais ça plus tard.
Pour l'instant ça fonctionne correctement
Amicalement
Philippe

@Philoupes  : l'UUID reste constant alors que les /dev/disk peuvent changer (sda peut devenir sdb au boot, il n'y a pas de persistance).

https://wiki.archlinux.org/index.php/Persistent_block_device_naming
https://debian-facile.org/doc:systeme:fstab


à plus,
oh!rocks

Re : Mise à Jour du jour ... Echec : Failled to start apply Kernel variables

Répondre #14
Re re re ...
Petite question à propos du FSTAB

Je n'ai pas trouvé d'explication convaincante à propos de l'utilisation du format UUID ou /dev/disk/by-id/....
En gros est ce que l'un d'entre vous sait s'il y a une réelle différence et si oui, dans quels cas il vaut mieux utiliser l'un ou l'autre des formats ?
Comme vous avez remarqué dans le mien de FSTAB j'avais initialement un espèce de mélange entre les déclarations de périphérique en UUID et en /dev...
J'ai unifié en UUID mais ça n'a pas empêché de merdé...

A vous lire
Philippe
 Bonjour

En faite, il y a 3 manières d'identifier ses partitions dans fstab :

1°) Périphériques  de stockage et partitions
/dev/sda  
/dev/sdb 
et les partitions 
/dev/sda1 
/dev/sdb1 

 tu peux les identifier avec la commande 
fdisk -l

2°) Identification alpha-numérique de périphérique et partition 
UUID=0c23e856-7edb-47d4-a3f3-f078ddb1eg3f

tu retrouves cette identification dans Le fichier de configuration de GRUB et FSTAB
a chaque formatage l'UUID change

Si tu as une partition en GPT, Linux ne se servira pas d'elle pour reconnaître la partition

tu peux les identifier avec la commande 
sudo blkid

3°) LABEL (nom que l'on donne si l'on le souhaite a chacune des partitions créés.
tu retrouves les noms des LABELS  avec différentes commandes, je préfère celle-ci ou tu trouveras plus d'infos pour les bidouilleurs (selon moi)

lsblk --fs
 sinon cette commande pour des infos synthétiques sur les LABEL déclarés 

df -h | grep -v loop

Le plus sécure est : UUID
Le plus pratique pour partitions a vocation Stockage de donnés : LABEL
Le plus intéressants pour admin-sys : sda, sdb etc (généralement ils listent les partitions sda1 etc etc, et en cas de bidouille, ils savent que par exemple la partition sda2 est la partition /tmp, et ils peuvent travailler dessus si c'est elle qui pose un problème. 

Perso je préfère UUID, mais je fais une correspondance entre UUID et sda1 etc..  si je dois réinstaller un OS sur une partition multi-boot, je sais qu'elles sont les partitions choisir pour la réinstalle, sans erreurs.

Voilà, j'espère avoir porter ma petite lumière sur mes pratiques Linuxiens.

A vrai dire je ne fais jamais de partitionnement automatique a l'installation d'un OS, je déclare toutes mes partitions manuellement
(/;/root;/swap;/opt;/var;/var;/home; /usr/local;/srv......) en XFS , je suis donc assez a l'aise avec ce type de reflexion.