Les UUIDs, ce sont des identifieurs uniques pour chaque support de stockage en interne. Cela permet d’éviter des erreurs quand on manipule les supports en les changeant de place par exemple. C’est quelque chose de puissant et de pratique, sauf quand le noyau n’arrive pas à monter les partitions en UUIDs 🙁
C’est le genre de bug qui m’est arrivé aujourd’hui. Ce matin, je vois arriver le noyau 6.3.8. Je ne redémarre pas étant donné que je ne comptais utiliser l’ordinateur plus d’une quarantaine de minutes.
Hors, en revenant et en démarrant mon PC, j’ai droit à une erreur comme quoi ma partition root ne pouvait pas être détectée.
J’arrivais sur l’erreur suivante :
You are now being dropped into an emergency shell.
sh: can't access tty: job control turned off
J’ai appellé à l’aide BabaOrhum pour qu’il m’aide à débloquer la situation à distance. En démarrant depuis un live USB de Manjaro, il a été possible d’entrer dans le système installé via un manjaro-chroot -a.
La solution a été en deux parties :
- installer le noyau linux lts pour avoir le double démarrage en cas d’ennuis
- Modifier le fichier /etc/fstab pour utiliser les vrais noms en lieu et place des UUIDs
Maintenant et grâce à la modification appliqué sur le /etc/fstab (les UUID n’étant que commenté avec des # sur les lignes concernées), je peux faire démarrer les deux noyaux.
Je me demande comment un tel bug a pu passer aux travers des tests… S’il y en a seulement eu !
On peut casser une Archlinux parfois – et c’est la première fois depuis 3 ans que je n’ai pas eu d’emmerdements avec le noyau – mais jamais complètement. Ou il faut vraiment y mettre la dose !
Tu vas pouvoir nous faire les « tutos » à la con des bugs d’Archlinux 🙂
Tu ne laisses pas l’ancien noyau au cas où?
A pluche.
Les noyaux d’une même génération se remplacent les uns les autres. Donc, à moins de jouer avec la commande downgrade (qui est sur AUR), il est difficile de rétrograder le noyau.
salut,
Il est l’hÔre misteur le casscadÔrrrrre de vivre moins dangereusement et d’enfiler une paire de charentaise, d’avoir un petit matou sur tes genoux, de te laisser bercer par ses doux ronronnements, de siphonner une grosse tasse de thé vert et d’avoir des petits biscuits à la cannelle à portée de main parce que tous les geeks en sont fans, c’est bien connu !
Moi par contre j’ai remplacé le thé vert par du pinard et ces saloperies de biscuits à la cannelle par du saucisson. Mais j’ai le droit parce que je ne suis pas un geekounet… Reprenons…
Pourrais savoir m’sieur l’artiste quel noyau tu utilisais avant la réparation ?
Parce qu’en utilisant la plus sublimissiiiiiiiiiiime distribution venant du monde du libre, je parle bien évidemment d’Endeavour OS, ( what else ???) Qui fait passer toutes les autres pour d’énormes bouses, je tourne très classiquement sur un core/linux 6.3.8 stable et tout se passe remarquablement bien…
Je pense que si j’avais eu le même problème que le tien, j’aurais pu m’en sortir facilement en utilisant un live-CD et AKM. Est-ce que je me trompe ?
Doucement sur le coup de bâton, j’ai déjà la fesse douloureuse après avoir dit à Madame que ses lazagnes étaient trop cuites ! OuilleOuilleOuille…..
C’est quoi les vrais noms pour toi ?
A pluche.
/dev/sdaX (avec X commençant à 1) par exemple.
A quoi te sers d’avoir le dernier noyau vu ta config? Tu en as eu en 6.2 et la maintenant.
Une simple question d’habitude.
Et a force d’avoir des bugs tu n’as pas pris l’habitude d’installer un noyau lts pour te dépanner tout seul ?
J’avais l’habitude d’être en mono noyau. Avec ce bug, c’est de l’histoire ancienne.
Bah didons heureusement que l’on peut toujours se dépatouiller avec un live-CD
Je suis sur Debian Sid totalement à jour, sur mon vieux laptop de 11 ans que je me sers quotidiennement, mais étant donné que le kernel de Sid me posait souvent des soucis (GPU Intel/Nvidia, technologie Optimus hasardeuse, on connaît les galères), avec utilisation des pilotes GPU open source, je me suis dis qu’un vieux kernel bien solide devrait faire l’affaire sans trop de soucis, du coup celui de Buster est bien dans cette optique, modif du sourcelists, et depuis jackpot, plus aucun soucis, en + le kernel sera EOL en décembre 2024, donc je passerai sur celui de Debian 11, et ainsi de suite, jusqu’à ce que mon PC finisse par claquer 🙂
Cela ne risque pas de m’arriver. Ici, noyau et initramfs en cours sont toujours conservés quand un nouveau noyau est fourni et un initramfs associé installé par ma distribution: seuls sont supprimés les plus anciens: ceinture et bretelles. Bon, on va encore dire que je fais de la pub pour …. mais j’assume 😉
Sinon, les UUID dans /etc/fstab c’est bien et pas seulement pour les supports amovibles.
Exemple: Je décide de déplacer ma partition racine /dev/sda3 (formatée avec BTRFS) du disque A vers le disque B. Je crée une partition de taille suffisante sur le disque B (par exemple /dev/sdb3) non formatée puis je tape:
mount /dev/sda3 /mnt # Pour transférer le volume entier avec ses sous-volumes
btrfs replace start 1 /dev/sdb3 /mnt # 1 est le « device id »
Une fois le transfert terminé il n’y a plus qu’à réinstaller et reconfigurer GRUB (eventuellement en changeant /boot/efi d’abord), pas besoin d’éditer /etc/fstab autrement car l’UUID de /dev/sda3 est transféré vers /dev/sdb3.
Pour répondre, loin de là de dire que c’est mal. J’ai juste regardé si ça bootait en realpath et oui ça boot, seule cette sous version du noyau bug. La 6.3.7 ne bug pas et le LTS non plus. Bien sûr qu’il faudra rétablir le système UUID une fois fix. En effet l’UUID ne bouge pas contrairement au realpath en cas de changement matériel.
Chose supplémentaire j’aurai préféré que mon nom soit absent de cet article. Merci.
Je ne voulais pas tirer tout le profit de l’installation du contournement du bug dans l’article.
Ya un commentaire qui n’est pas passé Fred
J’ai tout validé, pourtant. Je vais voir si ça ne traine pas ailleurs à cause d’une détection défaillante.
cela ressemble a un bug de la part de Grub ,
de mon côté en Testing avec la 6.3.8 Manjaro ( ou Endevouros version zen ) je ne rencontre pas ce problème.
j’ai toujours à minima 2 noyaux installé
Pour l’avoir installé ce vendredi matin, j’ai pas eu de soucis avec le 6.3.8. Et pourtant, mes /etc/fstab utilisent les UUID sur les deux PC. Si ça a été corrigé avant le passage à Core…
Je t’avoue que je ne comprends pas ce qui s’est passé. Je sais seulement que le noyau ne trouvait plus les UUIDs. Comme Didier l’a dit dans un autre commentaire, ça sent l’initramfs un brin faisandé.
Salut le monde
Bon je vois que tout a été dit, mais je vais mettre mon petit grain de sel quant même!
j’ai toujours eut 2 noyaux en place au cas où justement, car parfois quant un noyau est mis à jour,il peut y avoir…. et bien……des bugs!! et donc le démarrage de sa machine partit en cou……e(oups désolé) et donc avec le mode recovery il est donc possible de revenir en arrière et ainsi récupérer son système et attendre que le bug soit corrigé,à moins de rester sur un noyau stable, ce qui est le cas sur certaines de mes machines qui ont largement dépassées la date de péremption!!!
Bonne journée
Relisant ton billet, à ma connaissance le noyau est incapable de reconnaître les UUID, seul un initramfs peut le faire. La raison en est que l’UUID ( uuid pour lsblk) est celui du système de fichier auquel le noyau n’a pas directement accès, seul un initramfs y a accès, donc mon hypothèse est que le souci était avec ton initramfs. Le noyau ne sait reconnaître directement que le nom de partition (/dev/…) et l’UUID de la partition (partuuid pour lsblk).
Un bug dans mkinitcpio qui génère l’initramfs ? Ou dans grub ? Il a été modifié une journée auparavant mais lançait le système sans problème.
De plus en plus bizarre 🙁
Je ne connais pas mkinitcpio (j’utilise dracut). Pour savoir s’il y a un bug dans grub il faudrait lire ton /boot/grub/grub.cfg , dont je suppose qu’il a été re-généré après installation du nouveau noyau. Tu peux me l’envoyer pour que je regarde (la version en vigueur lors de l’incident).
j’active mon mode troll.
et dire que la version 6.3.8 est censée être en version stable.
Ça se stabilise, je vois, dans le monde de Linux.
ok, pas la peine de s’énerver, je suis en mode troll.
pour l’instant, aucun soucis avec win 10.
je désactive mon mode troll.
1. On ne sait pas si le problème vient du noyau.
2. Stable ne veut pas dire indemne de bogue.
Le seul paquet sensible qui a été modifié avant l’arrivée du bug, c’est le noyau justement. D’où mon accusation envers celui-ci.
Oui, mais il t’a bien fallu après mise à jour de ce paquet reconstruire un initramfs adapté et mettre ensuite à jour grub.cfg, à moins qu’un script fasse ça automatiquement après mise à jour du noyau (auquel cas c’est peut-être ce script qui a failli) ?
L’initramfs et le grub sont mis à jour par mkinitcpio dont c’est la tâche.
Peut-être qu’un bug dans celui-ci a été enclenché ? J’avoue que je suis un peu perdu.
Bah, déjà, tu peux regarder si la régénération des initramfs s’est faite sans erreur dans pacman.log : tu as bien une ligne « Image generation successful » après chaque salve de mkinitcpio (images default et fallback), pour le jour où l’OS s’est retrouvé en vrac ?
Voici ce que j’ai pour l’initramfs classique. Mis à part une gueulante par rapport à un périphérique USB introuvable, le log est correct.
[2023-06-16T07:33:34+0200] [ALPM] running '90-mkinitcpio-install.hook'...[2023-06-16T07:33:34+0200] [ALPM-SCRIPTLET] ==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default'
[2023-06-16T07:33:34+0200] [ALPM-SCRIPTLET] ==> Using configuration file: '/etc/mkinitcpio.conf'
[2023-06-16T07:33:34+0200] [ALPM-SCRIPTLET] -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
[2023-06-16T07:33:34+0200] [ALPM-SCRIPTLET] ==> Starting build: '6.3.8-arch1-1'
[2023-06-16T07:33:35+0200] [ALPM-SCRIPTLET] -> Running build hook: [base]
[2023-06-16T07:33:35+0200] [ALPM-SCRIPTLET] -> Running build hook: [udev]
[2023-06-16T07:33:35+0200] [ALPM-SCRIPTLET] -> Running build hook: [autodetect]
[2023-06-16T07:33:35+0200] [ALPM-SCRIPTLET] sort: impossible de lire: '/sys/devices/pci0000:00/0000:00:08.1/0000:08:00.3/usb3/3-2/3-2:1.3/ep_86/uevent': Aucun fichier ou dossier de ce type
[2023-06-16T07:33:35+0200] [ALPM-SCRIPTLET] modprobe: ERROR: missing parameters. See -h.
[2023-06-16T07:33:35+0200] [ALPM-SCRIPTLET] -> Running build hook: [modconf]
[2023-06-16T07:33:35+0200] [ALPM-SCRIPTLET] -> Running build hook: [kms]
[2023-06-16T07:33:36+0200] [ALPM-SCRIPTLET] -> Running build hook: [keyboard]
[2023-06-16T07:33:36+0200] [ALPM-SCRIPTLET] -> Running build hook: [keymap]
[2023-06-16T07:33:36+0200] [ALPM-SCRIPTLET] -> Running build hook: [consolefont]
[2023-06-16T07:33:36+0200] [ALPM-SCRIPTLET] -> Running build hook: [block]
[2023-06-16T07:33:37+0200] [ALPM-SCRIPTLET] -> Running build hook: [filesystems]
[2023-06-16T07:33:37+0200] [ALPM-SCRIPTLET] -> Running build hook: [fsck]
[2023-06-16T07:33:37+0200] [ALPM-SCRIPTLET] ==> Generating module dependencies
[2023-06-16T07:33:37+0200] [ALPM-SCRIPTLET] ==> Creating zstd-compressed initcpio image: '/boot/initramfs-linux.img'
[2023-06-16T07:33:37+0200] [ALPM-SCRIPTLET] ==> Image generation successful
Dans un cas comme celui-ci, je ne me pose même pas la question d’essayer avec un autre noyau, je reboote sur le snapshot BTRFS d’avant la mise à jour et j’attends que le bug soit corrigé. Mais pour ceux qui ne veulent pas de BTRFS, conserver le noyau précédent est effectivement une sage précaution même si ça ne résout pas tous les problèmes susceptibles d’arriver suite à une mise à jour.
Pour ma part ,et à chaque fois,je pense ne pas être le seul,après une mise à jour du noyau, un petit update-grub pour que cela soit bien prit en compte par le gub
Bonne journée
Achète un Mac 🙂
Dans un message précédent tu as écrit « L’initramfs et le grub sont mis à jour par mkinitcpio dont c’est la tâche », mais l’article d’ArchWiki sur mkinicpio ne dit pas qu’il mette à jour GRUB. Est-ce bien le cas?
En effet, j’ai été un peu trop loin dans les attributions de mkinitcpio. Il ne s’occupe pas du grub.cfg qu’il faut mettre à jour avec un petit
sudo grub-mkconfig -o /boot/grub/grub.cfg