Décidément, entre moi et Debian, c’est le grand amour :)
Ce qui devait arriver arriva : le dernier noyau fonctionnel (le 3.1.0) sur ma distribution est tombé en rade ce matin au démarrage, et donc là, je n’ai plus que ma clé USB de démarrage pour utiliser mon matériel informatique.
Je n’ai plus le choix, il va falloir que je prenne le taureau par les cornes.
Avant de jeter ma Debian par la fenêtre, je vais tenter dans les jours à venir (mais à petite dose vraisemblablement, car je sature un peu de toutes ces difficultés avec ma distribution).
J’en avais marre à chaque démarrage de devoir attendre le menu de Grub 2 pour aller sélectionner le seul noyau qui fonctionnait (sinon par défaut il démarrait le plus récent qui plantait), j’ai donc désinstallé (via synaptic) tous les autres sauf évidemment le fonctionnel. Et surprise : lui aussi ne démarre plus non plus maintenant :) !
En passant, avant certaines modifs de Grub 2 – il y a quelques années, on pouvait choisir le noyau à démarrer par défaut (via la commande « GRUB_DEFAULT=0 » dans /etc/default/grub), mais cette commande est devenue inutile depuis qu’un pré-menu a été mis en place (permettant de choisir de lancer le noyau par défaut, de tester la mémoire ou d’accéder au différents noyaux à lancer justement). Le changement de valeur de « GRUB_DEFAULT » (à 1 par exemple) déplace la sélection par défaut dans ce pré-menu et non plus dans le menu des noyaux à sélectionner : çà n’a plus aucun intérêt.
Un constat : on s’évertuent tous les 2 mois à sortir un nouveau noyau Linux – le 1er maillon de la chaîne qui initie le démarrage de nos PC, mais on laisse à l’abandon le second maillon de la chaîne : Grub 2 qui n’est plus maintenu depuis … 2012.
En lisant la page Wikipedia sur Grub je vois qu’il existe plein d’autres programmes d’amorçage (je ne connaissais que l’infâme Lilo qui plantait tout si l’on oubliait de lancer la commande de mise à jour du secteur d’amorçage après l’installation d’un nouveau noyau).
Néanmoins je ne suis pas sûr que le souci vienne de Grub 2. Peut-être que mes disques montés en RAID posent problème. Pourtant j’arrive très bien à les monter à partir de ma clé USB (par un # mount /dev/md1, …).
Ou bien est-ce un souci avec le n° des UUID des disques. Quel merdier là aussi. Il fût un temps où je pouvais nommer mes disques avec un nom lisible choisit par moi-même. Et puis tout ceci a été remplacé par un numéro imposé, ce qui donne des lignes tout à fait lisible sous /boot/grub/grub.cfg du type : « search –no-floppy –fs-uuid –set=root 6b84721a-d77c-476e-abf2-d3c1683f96e3 ». Tout à fait lisible. « 6b84721a-d77c-476e-abf2-d3c1683f96e3 » ? à oui bien-sûr, c’est mon disque SSD !
Mais mon véritable problème c’est qu’actuellement dans les dépôts Debian à peu près tous les paquets qui touchent au démarrage sont soit marqués comme buggés, soit dépendent de paquets qui le sont : grub, mdadm, util-linux
Ca semble donc périlleux de tenter une mise à jour pour débloquer la situation.
J’étais passé de Debian Sid (trop de bugs) à Debian Stable, mais finalement là aussi j’ai rencontré des bugs un peu pénibles (plantage de l’accélération graphique et donc de Xorg). Je suis donc revenu à Debian Sid :)
Aujourd’hui, au démarrage de grub 2, voilà en résumé ce que j’obtiens :
Loading … (je ne ré-écris pas le reste)
fsck from util-linux 2.26.2
root: clean, … (je ne ré-écris pas le reste)
Gave up waiting for /usr device. Common problems:
-Boot args (cat /proc/cmdline)
– check rootdelay=(did the system wait long enough?)
– Missing modules (cat /proc/modules; ls /dev)
ALERT! /dev/md3 does not exist. Dropping to a shell!
modprobe:
module i8042 not found in modules.dep
module atkbd not found in modules.dep
module ehci-pci not found in modules.dep
module ehci-orion not found in modules.dep
Busy box v1.22.1 built-in shell
Enter « help » for a list of built-in commands
/sbin/sh: can’t access tty; job control turned off (initramfs)
Précisons que :
/dev/sda1 / ext3 noatime,errors=remount-ro 0 1
/dev/md1 /home ext4 defaults 0 1
/dev/md3 /usr ext4 defaults 0 1
/dev/md2 /var ext4 defaults 0 1
Evidemment s’il n’arrive pas à monter /usr et /var, çà n’aide pas :)
Du coup le shell en question ci-dessus n’est pas d’une grande utilité : lorsque je saisi une commande je n’ai pas de retour à l’écran. Le merdier quoi.
Précisions :
(did the system wait long enough?)
set timeout=5 dans /boot/grub/grub.cfg
Il n’a pas changé et fonctionnait bien avant.
Le noyau 3.1.0 a toujours bien fonctionné, et encore hier il fonctionnait bien.
Mes montages RAID fonctionnent bien, j’en suis sûr.
Raison pour laquelle je suspecte plutôt un paramétrage automatique inapproprié (pour rester poli) :)
Comme indiqué dans un de mes posts précédents, le chroot à partir de ma clé USB ne fonctionne plus très bien.
Y a t’il quelque-chose qui fonctionne bien sur ma distribution Debian ?
Eh bien oui ma bonne Dame : hier encore je me louais de mon excellent environnement MATE joli et puissant !
Bon, problème : il faut pouvoir y arriver, c’est vrai.
J’ai réussi un moment donné à lancer une session de IceWm en chroot sur ma clé USB via les commandes suivantes :
Console 1 :
# mount -t ext3 /dev/sda1 /mnt/sda1
# chroot /mnt/sda1
# mount -a
# mount /proc
# mount /dev/md1
# mount /dev/md2
# mount /dev/md3
# mount /dev/pts
Console 2 :
$ Xnest -ac :1 &
$ export DISPLAY=127.0.0.1:1
$ icewm-session &
Mais elle a fini par planter au lancement de Synaptic à partir d’une console sous IceWm.
A Noter que bizarrement, le « mount -a » ne monte pas tout ce qu’il y a dans mon /etc/fstab, raison pour laquelle j’effectue les autres montages.
Bon voilà, j’en suis là ou presque.
J’ai été jusqu’à tester le truc un peu fou suivant :
A partir de ma clé USB j’ai copié manuellement de ma clé USB vers mon système en vrac -non sans avoir sauvegardé au préalable les fichiers précédents dans des répertoires séparés :
– le noyau 3.2.0 de /lib/modules/
– le contenu de /boot
– /etc/default/grub et associés
– /etc/grub.d
J’ai redémarré. Sous mon BIOS je sélectionne un démarrage sur mon disque SSD au lieu de la clé USB, çà démarre sous Grub, mais ensuite il poursuit son démarrage sans encombre sous ma clé USB. Logique, j’ai oublié de changer le disque de démarrage sous Grub.
En chroot j’édite /etc/boot/grub.cfg (pas le choix, la commande update-grub refuse de fonctionner dans mon chroot, et de toute façon comme je bypass pas mal de choses, çà n’aurait vraisemblablement pas changé grand chose) mais là je me retrouve confronté à l’épineux problème des noms de disque (d’où ma digression ci-avant sur tout le bien dont je pense sur l’actuelle dénomination des disques – l’UUID).
Yeeeeeesssssss !!!!!!!!!!!!!!!!!!!!!!!!!
Punaise, çà marche !!!!!
Un p’tit pas pour moi, un grand pour mon estim de ma Debian :)
Elle est bien buguée, bien branlante, mais on arrive à la réparer en la bricolant avec des bouts de ficelle et çà marche.
Récapitulatif de ma manip scabreuse mais fonctionnelle (bon à savoir et à garder dans un coin) :
– j’ai repompé à la main le noyau de ma clé USB sur mon disque planté (voir ci-dessus, recopie du noyau 3.2.0-4-686-pae avec ses modules situés dans /lib et ses fichiers situés dans /boot) ainsi que le fichier de configuration de grub (/boot/grub/grub.cfg)
– j’ai repris manuellement le fichier /boot/grub/grub.cfg récupéré de ma clé USB (et copié sur mon SSD) :
-> j’ai remplacé entièrement les sections « ### BEGIN /etc/grub.d/00_header ### » et « ### BEGIN /etc/grub.d/05_debian_theme ### » pour garder celles de mon disque planté (à cause des n° des disques UUID qui ne sont pas les mêmes)
-> j’ai conservé les autres sections mais j’ai juste remplacé les numéros d’UUID dans la section « ### BEGIN /etc/grub.d/10_linux ### » avec le n° de mon SSD (trouvé sur mon autre fichier grub.cfg planté), qui est le « 6b84721a-d77c-476e-abf2-d3c1683f96e3 » :)
J’ai enregistré, rebooté, enlevé ma clé USB (pour être sûr que çà démarre sans) puis redémarré. Nickel çà marche.
Sauf que sur mon disque SSD, Xorg plante puisque je n’avais pas de noyau 3.2.0-4-686-pae et donc je n’avais pas compilé de module nvidia. Et comme ce noyau est un peu ancien, pas moyen de faire un « apt-get install noyautoutbête ». Donc via mon autre vieux PC (il m’aura bien servi celui-là !) je recherche et installe le linux-headers-3.2.0-4-686-pae_3.2.68-1+deb7u6_i386.deb qui réclame linux-headers-3.2.0-4-common_3.2.68-1+deb7u6_i386.deb qui réclame linux-kbuild-3.2_3.2.17-1_i386.deb (ils n’ont décidément aucune pitié pour les gars qui tapent cela à la main en console). Puis j’installe l’accélération graphique (# m-a a-i nvidia-kernel-source) et relance Xorg, et … me re-voilà :)
Bon bien-sûr j’ai fais une sauvegarde de mon /boot/grub/grub.cfg (en /boot/grub/grub-bidouilleok.cfg) qui sera détruit dès la prochaine mise à jour du noyau ou toute autre manip impliquant grub-update.
Il faudra que je retente une remise au propre de mon installation grub, mais je vais attendre un peu.
Pour l’instant, je savoure ma victoire :)