PC du Bottin toujours planté aka pb disques RAID (résolu)

Suite de la page « Vous allez rire : mon PC est encore planté :) »
Même pas drôle :)

Suivant mes observations précédentes, je m’oriente :
– soit vers un soucis de paquets mis à jours (que j’aurais tendance à privilégier, étant donné le nombre de partitions qu’il détecte comme « abîmées »)
– soit vers un réel souci de partitions endommagées (message « Warning: Partition 1 does not end on cylinder boundary » sur les disques sdb, sdc et sdf : mauvais réveil après 2 mises en hibernation de mes disques le week-end il y a 1 semaine ? Pour mémo, j’ai effectué entre ces 2 mises en hibernation des mises à jour de paquets – dont vraisemblablement mdadm).

J’effectuerai une tentative de réparation par e2fsck de mes partitions RAID
Mais avant de me lancer dans la destruction de mes données :) je vais effectuer quelques vérifications, mises à jour et sauvegardes.

Puisque la précédente version de mdadm ne donne pas de meilleurs résultats que l’actuelle, je réinstalle la nouvelle.
De plus, sur mon chroot avec Synaptic, je met à jour tout ce qui peut l’être (une centaine de paquets) et qui n’est pas un jeu ou un paquet en rapport avec le réseau (pas envie que celui-ci plante et me rajoute un souci de plus) ou un autre logiciel sans rapport avec le système (au risque important d’introduire de nouveaux bugs, tant pis).

Ensuite j’effectuerai un redémarrage, et si rien n’a progressé, je me lancerai :
– dans une sauvegarde de mes données sur un autre support,
– dans la tentative de réparation des montages RAID, opération qui me semble la plus dangereuse pour mes données.

Pour la réparation de mes disques RAID, j’ai trouvé ces docs qui me paraissent pas mal du tout :
HOWTO: Repair filesystem using fsck on a raid setup
– et la bible – comme d’habitude, sur Ubuntu-fr : RAID logiciel avec mdadm

Pour la mise à jour des paquets, j’en ai pour un moment (jusqu’à demain au moins).

————————————————————————————————————
Reprise le 29 mars 2016

J’ai mis à jour tout ce qui pouvait l’être en dehors des jeux, des imprimantes, du réseau, de libreoffice, gnome, KDE, du son et des drivers nvidia/xorg.
J’ai déjà testé hier soir : çà n’a pas fonctionné (mêmes messages et blocage au démarrage), ce soir dans les dépôts il y a encore des libc que je viens de mettre à jour.
Ce sont mes dernières cartouches, et je n’y crois plus vraiment.
Je la sent bien la galère de la longue phase de sauvegardes …
Je redémarre …

Résultat : çà ne marche pas.
Force est de constater que j’ai tout un tas de partitions qui ont morflées :(
Il va falloir que je me tape le travail ingrat de sauvegardes / réparations.

Récapitulatif des soucis (Warning: Partition xx does not end on cylinder boundary) :
(selon # fdisk -l)
/dev/sdb5, 6, 7, 8, 9, 10
/dev/sdc5, 6, 7, 8, 9, 10
/dev/sdf1, 2, 5

Partitions Ok :
/dev/sdb1, 2
/dev/sdc1, 2
/dev/sdd1, 2
/dev/sde1, 2

Plan de table :
(selon /etc/fstab)
/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
/dev/md6 /mnt/DDter ext4 defaults 0 2
/dev/md5 /mnt/DDsec ext4 defaults 0 2
/dev/md4 /mnt/DDprc ext4 defaults 0 2

(selon # cat /proc/mdstat)
Personalities : [raid1]
md8 : active raid1 sdd2[0] sde2[1]
md7 : active raid1 sdd1[0] sde1[1]
md6 : active raid1 sdb10[0] sdc10[1]
md5 : active raid1 sdb9[0] sdc9[1]
md4 : active raid1 sdb8[0] sdc8[1]
md3 : active raid1 sdb7[0] sdc7[1]
md2 : active raid1 sdb6[0] sdc6[1]
md1 : active raid1 sdb5[0] sdc5[1]
md0 : active raid1 sdb1[0] sdc1[1]

Donc à réparer :
/dev/md1 (/home)
/dev/md2 (/var)
/dev/md3 (/usr)
/dev/md4 (/DDprc)
/dev/md5 (/DDsec)
/dev/md6 (/DDter)

Merci Linux DEBIAN :) En gros : toutes celles qui étaient montées quoi :)
J’achète des disques en double (avec mes maigres petits deniers, je citerai John Hammond : J’ai dépensé sans compter) pour sécuriser mes données en RAID 1, je les confient à ma distrib favorite en toute confiance, et celle-ci me les saccagent 2 par 2. C’est mieux, çà va plus vite :)

Je déroule la doc de HOWTO: Repair filesystem using fsck on a raid setup

# mdadm –examine –scan
ARRAY /dev/md8 UUID=3eb7c783:f6587f95:8e600218:ffb3fb5f
ARRAY /dev/md7 UUID=83f773bb:f9366cc2:8e600218:ffb3fb5f
ARRAY /dev/md6 UUID=18459e4c:6aa51929:6e1a0c87:97e38a41
ARRAY /dev/md5 UUID=127032f2:6a2aa740:6e1a0c87:97e38a41
ARRAY /dev/md4 UUID=749b745f:12b5190f:6e1a0c87:97e38a41
ARRAY /dev/md3 UUID=35dcdf53:b3600e96:6e1a0c87:97e38a41
ARRAY /dev/md2 UUID=c3cd8d39:d0347554:6e1a0c87:97e38a41
ARRAY /dev/md1 UUID=6fcb95fe:25318162:6e1a0c87:97e38a41
ARRAY /dev/md0 UUID=436b1aa4:f1e2df6c:6e1a0c87:97e38a41

J’ai monté l’ensemble des partitions par un : # mount -a
Étonnant que là il faille monter la partition pour la réparer
Pas super chaud pour commencer :)
Allez, on se jette à l’eau sans sauvegarde sur le /usr, au pire ce n’est que du téléchargé :
En dehors de mon chroot je lance :
# fsck /dev/md3
fsck de util-linux 2.20.1
e2fsck 1.42.5 (29-Jul-2012)
/dev/md3 is mounted.
e2fsck: Ne peut continuer, arrêt immédiat.

Ah, c’est bien ce qu’il me semblait, il faut démonter au préalable, j’aime mieux çà.
# umount /dev/md3
# fsck /dev/md3
fsck de util-linux 2.20.1
e2fsck 1.42.5 (29-Jul-2012)
/dev/md3 a été monté 36 fois sans avoir été vérifié, vérification forcée.
Passe 1 : vérification des i-noeuds, des blocs et des tailles
^[[B^[[B^[[B^[[B^[[B^[[BPasse 2 : vérification de la structure des répertoires
Passe 3 : vérification de la connectivité des répertoires
Passe 4 : vérification des compteurs de référence
Passe 5 : vérification de l’information du sommaire de groupe
/dev/md3 : 1123107/3276800 fichiers (0.4% non contigüs), 9889752/13107008 blocs

Plouf. C’est tout ? Durée maxi : 20 secondes.
Je reste sur ma faim là.

# e2fsck
Usage : e2fsck [-panyrcdfvtDFV] [-b super-bloc] [-B taille-de-bloc]
[-I nombre-blocs-du-tampon-i-noeuds] [-P taille-i-noeud-processus]
[-l|-L fichiers-des-blocs-défectueux] [-C fd] [-j journal-externe]
[-E options-étendues] périphérique

Aide d’urgence :
-p Réparation automatique (sans question)
-n N’appliquer aucun changement au système de fichiers
-y Supposer « oui » pour toutes les questions
-c Vérifier la présence de blocs défectueux et les
ajouter à la liste des blocs défectueux
-f Forcer la vérification même si le système de fichiers
est marqué propre
-v Travailler en mode bavard
-b super-bloc Utiliser un bloc alternatif pour le superbloc
-B taille-de-bloc Forcer la taille des blocs lors de la recherche du
superbloc
-j journal-externe Définir la localisation du journal externe
-l fichier-des-blocs-erronés
Ajouter à la liste des blocs défectueux
-L fichier-des-blocs-erronés
Définir la liste des blocs défectueux

# e2fsck -fc /dev/md3
(c’est nettement plus long, après 2min il n’en est qu’à 24%)
8 minutes plus tard :
Vérification des blocs défectueux (test en mode lecture seule) : complété
/dev/md3: Updating bad block inode.
Passe 1 : vérification des i-noeuds, des blocs et des tailles
Passe 2 : vérification de la structure des répertoires
Passe 3 : vérification de la connectivité des répertoires
Passe 4 : vérification des compteurs de référence
Passe 5 : vérification de l’information du sommaire de groupe

/dev/md3: ***** LE SYSTÈME DE FICHIERS A ÉTÉ MODIFIÉ *****
/dev/md3 : 1123107/3276800 fichiers (0.4% non contigüs), 9889752/13107008 blocs

Dans mon chroot cette fois-ci, je monte /dev/md3 pour voir ce qu’il reste :)
Ok, il a l’air correct (je vois le /usr)

Je vais redémarrer pour voir s’il va un peu plus loin que /dev/md3 dans son cycle de démarrage (il commencait par planter sur /dev/md3).
Je vous tiendrais au courant demain.

————————————————————————————————————
Reprise le 2 avril 2016 (fallait éviter le 1 avril :) )

Me voilà de retour, plus (dé)motivé que jamais :)
Résumé des jours précédents :
çà ne marche pas ma p’tite dame. Puis 2 jours sans informatique.

Les derniers messages affichés :
Begin: Running /scripts/local-block … done
done.
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!

La vérification et « réparation » de cette partition /dev/md3 par e2fsck n’a donc rien donné.
Je m’oriente plus que jamais vers un bug du système de démarrage de Debian.
Je suis certain que le noyau n’y est pour rien.
Un module de gestion de disque / du RAID manquant ? Possible. A vérifier aussi.

Je rêve d’une ligne sous Grub (ou un autre système de démarrage plus simple) apportant l’option « détection / diagnostic / réparation de votre système de démarrage ».
Cette option conduirait à un noyau stable de référence / sauvegarde installé par dépendance avec ce Grub suivi d’un script de diagnostic aussi robuste qui proposerait une réparation une fois son analyse effectuée.
Ca se fait depuis des années sous Windows …

Quelques tests sous Palimpsest :

Sous ma clé USB j’ai un utilitaire qui s’appelle « Utilitaire de disque » (vous le trouverez sans problème sur Internet avec votre moteur de recherche : bon courage :) )
(Petite) Trêve de plaisanterie, en déverrouillant les composants graphiques de KDE, puis en copiant le raccourci sur le bureau, puis en faisant un clic droit dessus et en l’éditant je fini par trouver que c’est palimpsest (c’était compliqué d’ajouter son nom dans le raccourci ?)
Ce n’est pas ma première utilisation de cet utilitaire, qui me semble très bien pour l’analyse des disques.

Récapitulatif des soucis (Warning: Partition xx does not end on cylinder boundary) :
(selon # fdisk -l)
/dev/sdb5, 6, 7, 8, 9, 10
/dev/sdc5, 6, 7, 8, 9, 10
/dev/sdf1, 2, 5

Partitions Ok :
/dev/sdb1, 2
/dev/sdc1, 2
/dev/sdd1, 2
/dev/sde1, 2

Sous Palimpsest :
/dev/sdb : Le disque est sain
/dev/sdc : Le disque présente quelques secteurs endommagés
(11 mauvais secteurs)
/dev/sdd : Le disque est sain
/dev/sde : Le disque est sain

Rien de bien inquiétant, il arrive souvent surtout quand les disques prennent de l’âge, que quelques secteurs prennent une claque, mais la vérification du disque est là pour les flagger afin de ne plus les utiliser.

Finalement je relance Palimpsest en root pour avoir accès aux options réservées au root (réparation, …), d’où l’intérêt de connaître son nom :
# palimpsest
Je ne sais pas si c’est normal, mais toutes les partitions RAID son marquées comme « Non partitionné ».
Je sélectionné /dev/md3 et clique sur le bouton de réparation.
J’espère que je fais pas de bêtises … (il y avait une option « Démonter le volume » que je vois après coup).
Fin de la réparation : les fichiers y sont toujours. Ouf.
Je vais ensuite ré-essayer un démarrage pour voir si cela change quelque-chose.
Je m’en doutais un peu, çà ne fonctionne pas mieux, il a dû relancer une nouvelle fois e2fsck.

Module RAID absent au démarrage ou script foireux ?

Une commande trouvée sur un forum :

Je lance un test hdparm :
# hdparm -Tt /dev/sdc

/dev/sdc:
Timing cached reads: 18016 MB in 2.00 seconds = 9018.30 MB/sec
Timing buffered disk reads: 304 MB in 3.01 seconds = 100.93 MB/sec
goup2net:/# hdparm -Tt /dev/sdb

/dev/sdb:
Timing cached reads: 17926 MB in 2.00 seconds = 8972.91 MB/sec
Timing buffered disk reads: 314 MB in 3.02 seconds = 104.03 MB/sec

Pas super super utile :)

J’ai été jeter un oeil dans /etc/mdadm/mdadm.conf : bien qu’il ait été modifié récemment, je n’y vois rien d’anormal.

# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#

# by default, scan all partitions (/proc/partitions) for MD superblocks.
# alternatively, specify devices to scan, using wildcards if desired.
# Modif Goupil :
# DEVICE partitions
DEVICE /dev/sdb1 /dev/sdc1 /dev/sdb5 /dev/sdc5 /dev/sdb6 /dev/sdc6 /dev/sdb7 /dev/sdc7 /dev/sdb8 /dev/sdc8 /dev/sdb9 /dev/sdc9 /dev/sdb10 /dev/sdc10 /dev/sdd1 /dev/sde1 /dev/sdd2 /dev/sde2

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST « system »

# instruct the monitoring daemon where to send mail alerts
MAILADDR root

# definitions of existing MD arrays
# Modif Goupil :
ARRAY /dev/md0 level=raid1 UUID=436b1aa4:f1e2df6c:6e1a0c87:97e38a41
ARRAY /dev/md1 level=raid1 UUID=6fcb95fe:25318162:6e1a0c87:97e38a41
ARRAY /dev/md2 level=raid1 UUID=c3cd8d39:d0347554:6e1a0c87:97e38a41
ARRAY /dev/md3 level=raid1 UUID=35dcdf53:b3600e96:6e1a0c87:97e38a41
ARRAY /dev/md4 level=raid1 UUID=749b745f:12b5190f:6e1a0c87:97e38a41
ARRAY /dev/md5 level=raid1 UUID=127032f2:6a2aa740:6e1a0c87:97e38a41
ARRAY /dev/md6 level=raid1 UUID=18459e4c:6aa51929:6e1a0c87:97e38a41
ARRAY /dev/md7 level=raid1 UUID=83f773bb:f9366cc2:8e600218:ffb3fb5f
ARRAY /dev/md8 level=raid1 UUID=3eb7c783:f6587f95:8e600218:ffb3fb5f

Nota : ci-dessus j’ai remplacé HOMEHOST signe inférieur system signe supérieur par HOMEHOST « system » afin de pouvoir l’afficher sous WordPress sinon ce dernier le traduit par une balise texte.

Inspiré par ce forum askubuntu, je teste :
# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-4.4.0-1-rt-686-pae

Donc pas de message d’erreur particulier.

Une autre commande intéressante trouvée ci-dessus :
# mdadm –misc –detail /dev/md3
/dev/md3:
Version : 0.90
Creation Time : Sat Oct 24 23:13:38 2009
Raid Level : raid1
Array Size : 52428032 (50.00 GiB 53.69 GB)
Used Dev Size : 52428032 (50.00 GiB 53.69 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 3
Persistence : Superblock is persistent

Update Time : Sat Apr 2 10:53:06 2016
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

UUID : 35dcdf53:b3600e96:6e1a0c87:97e38a41 (local to host goup2net)
Events : 0.82845

Number Major Minor RaidDevice State
0 8 23 0 active sync /dev/sdb7
1 8 39 1 active sync /dev/sdc7

Donc là aussi il me dit que mon /dev/md3 fonctionne bien …
Rappel : # fdisk -l m’affiche toujours (je viens de le relancer pour voir) : « Warning: Partition x does not end on cylinder boundary. »

Direction /etc/boot/grub/grub.cfg de mon disque à réparer :
J’y retrouve des lignes :
insmod part_msdos
insmod part_msdos
insmod diskfilter
insmod mdraid09
insmod ext2

Sur ma clé USB :

# modprobe mdraid09
modprobe: FATAL: Module mdraid09 not found in directory /lib/modules/3.2.0-4-686-pae

# lsmod | grep md
md_mod 85719 7 raid1

# modinfo md_mod
filename: /lib/modules/3.2.0-4-686-pae/kernel/drivers/md/md-mod.ko
alias: block-major-9-*
alias: md
description: MD RAID framework
license: GPL
depends:
intree: Y
vermagic: 3.2.0-4-686-pae SMP mod_unload modversions 686
parm: start_dirty_degraded:int

# modinfo raid1
filename: /lib/modules/3.2.0-4-686-pae/kernel/drivers/md/raid1.ko
alias: md-level-1
alias: md-raid1
alias: md-personality-3
description: RAID1 (mirroring) personality for MD
license: GPL
depends: md-mod
intree: Y
vermagic: 3.2.0-4-686-pae SMP mod_unload modversions 686
parm: max_queued_requests:int

# lsmod | grep ext
ext3 134152 1
jbd 47281 1 ext3
ext4 306996 7
crc16 12327 2 ext4,bluetooth
jbd2 52330 1 ext4
mbcache 12938 2 ext4,ext3

# modprobe ext2
# lsmod | grep ext
ext2 49826 0
ext3 134152 1
jbd 47281 1 ext3
ext4 306996 7
crc16 12327 2 ext4,bluetooth
jbd2 52330 1 ext4
mbcache 12938 3 ext4,ext3,ext2

Dans grub.cfg il semble charger 2 fois le module part_msdos, charge le module mdraid09 qui n’existe pas sur ma clé USB, et charge le module ext2 antédiluvien qui n’est plus utilisé mais toujours présent.
Il ne me semble pas super super optimisé ce fichier de configuration Grub :)

Pour mémo, les modules :
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
sont toujours là (ils sont revenus avec la mise à jour de Grub).
Je n’ai toujours pas de carte graphique bochs ou cirrus et n’utilise toujours pas uefi …

A tout hasard, j’ajoute à la suite dans grub.conf (on verra pour mettre çà en dur si çà marche) :
insmod ext3
insmod md_mod
insmod raid1

Je redémarre.
Ca ne démarre pas mieux.
Mais j’ai pu lancer un lsmod dans ce mode minimaliste en QWERTY et voir qu’il n’y avait pas plus de module md_mod que de module raid1 chargé en mémoire.
Je retire ce que j’ai dis, peut-être se pourrait-il que :
– le noyau linux utilisé soit foireux – non pas par un bug, mais compilé sans fournir les modules RAID
– dans les mises à jour il y ait eut une nouvelle version du même noyau (car j’avais installé un nouveau noyau mais il me semble aussi une mise à jour du noyau existant).

Une petite recherche « raid* » avec Konqueror sur ma clé USB dans /lib/modules/3.2.0-4-686-pae (le noyau de ma clé) :
raid6/ dans kernel/lib/
raid_class.ko dans kernel/drivers/scsi/
raid1.ko dans kernel/drivers/md/
raid10.ko dans kernel/drivers/md/
raid456.ko dans kernel/drivers/md/
raid6_pq.ko dans kernel/lib/raid6/

et avec « md* », j’ai (entre-autres) :
/lib/modules/3.2.0-4-686-pae/kernel/drivers/md/md-mod.ko

Perdu :
Une fois monté sur ma clé USB, le disque incriminé contient bien les mêmes fichiers dans /mnt/sda1/lib/modules/4.4.0-1-rt-686-pae/kernel/drivers/md/ et dans /mnt/sda1/lib/modules/4.3.0-1-686-pae/kernel/drivers/md/.
Par contre les tailles des drivers sont bien supérieures à ceux trouvés dans /mnt/sda1/lib/modules/3.2.0-4-686-pae/kernel/drivers/md/

Exemples :
md-mod.ko : 167.2ko (en 4.3.0), 169.9ko (en 4.4.0) vs 122.5ko (3.2.0-4)
raid1.ko : 44.7ko (en 4.3.0), 44.8ko (en 4.4.0) vs 33.5ko (3.2.0-4)

Problème : je n’arrivais plus à charger le noyau 3.2.0.
Mais je pense avoir trouvé pourquoi : le fichier image /boot/initrd.img-3.2.0-4-686-pae avait mystérieusement disparu (c’est pas moi :) ). Pas grave, je le recopie de ma clé USB vers mon disque non opérationnel.
Et je redémarre pour tester cet ancien noyau 3.2.0 …

Résultat :
Ca ne marche pas.
Ca se termine par :
List of all partitions :
No filesystem could mount root, tried:
Kernel panic – not syncing: VFS: Unable to mount root fs on unknown-block (0,0)

Mais EUREKA. Je crois que j’ai trouvé la solution.
Comme le noyau 3.2.0 ne fonctionnait pas (alors là je ne comprend pas non plus pourquoi il fonctionnait avant et plus maintenant … les mystères de Linux …) j’ai testé le noyau 4.3.0-1-686-pae qui ne fonctionne pas non plus.

Mais là je remarque un message que je n’ai pas vu avec le noyau 4.4.
Je redémarre pour voir s’il est affiché avec le noyau 4.4, je veux en avoir le coeur net :)
Confirmé !!!!

Je vous explique :

– lorsque l’on démarre sur un noyau 4.4 et qu’il ne trouve pas les montages RAID, les derniers messages affichés à l’écran sont :
Begin: Running /scripts/local-block … done
done.
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!

– lorsque l’on démarre sur un noyau 4.3 et qu’il ne trouve pas les montages RAID, les derniers messages affichés à l’écran sont :
grosso-modo les mêmes :)
mais juste au-dessus il affiche :
« Begin: Mounting root file system…
Begin: Running /scripts/local-top … Warning: INITRDSTART set to « none » in /etc/default/mdadm, not assembling raid arrays »

Punaise … :)
Direction /mnt/sda1/etc/default/, dans lequel je trouve 2 fichiers:
mdadm daté du 28/03/2016
et mdadm~ daté du 25/10/2009

Dans mdadm j’ai effectivement :

# mdadm Debian configuration
#
# You can run ‘dpkg-reconfigure mdadm’ to modify the values in this file, if
# you want. You can also change the values here and changes will be preserved.
# Do note that only the values are preserved; the rest of the file is
# rewritten.
#

# INITRDSTART:
# list of arrays (or ‘all’) to start automatically when the initial ramdisk
# loads. This list *must* include the array holding your root filesystem. Use
# ‘none’ to prevent any array from being started from the initial ramdisk.
INITRDSTART=’none’

# AUTOCHECK:
# should mdadm run periodic redundancy checks over your arrays? See
# /etc/cron.d/mdadm.
AUTOCHECK=true

# START_DAEMON:
# should mdadm start the MD monitoring daemon during boot?
START_DAEMON=true

# DAEMON_OPTIONS:
# additional options to pass to the daemon.
DAEMON_OPTIONS= »–syslog »

# VERBOSE:
# if this variable is set to true, mdadm will be a little more verbose e.g.
# when creating the initramfs.
VERBOSE=false

et dans mdadm~ daté du 25/10/2009 :

# mdadm Debian configuration
#
# You can run ‘dpkg-reconfigure mdadm’ to modify the values in this file, if
# you want. You can also change the values here and changes will be preserved.
# Do note that only the values are preserved; the rest of the file is
# rewritten.
#

# INITRDSTART:
# list of arrays (or ‘all’) to start automatically when the initial ramdisk
# loads. This list *must* include the array holding your root filesystem. Use
# ‘none’ to prevent any array from being started from the initial ramdisk.
INITRDSTART=’none’

# AUTOSTART:
# should mdadm start arrays listed in /etc/mdadm/mdadm.conf automatically
# during boot?
AUTOSTART=false

# AUTOCHECK:
# should mdadm run periodic redundancy checks over your arrays? See
# /etc/cron.d/mdadm.
AUTOCHECK=true

# START_DAEMON:
# should mdadm start the MD monitoring daemon during boot?
START_DAEMON=true

# DAEMON_OPTIONS:
# additional options to pass to the daemon.
DAEMON_OPTIONS= »–syslog »

# VERBOSE:
# if this variable is set to true, mdadm will be a little more verbose e.g.
# when creating the initramfs.
VERBOSE=false

# MAIL_TO:
# this variable is now managed in /etc/mdadm/mdadm.conf (MAILADDR).
# Please see mdadm.conf(5).

Espoir un peu refroidi, c’est bizare, cela veut dire qu’avant non plus le montage RAID n’était pas activé, mais il démarrait quand-même – si j’en crois la date de mon fichier (ce que je ne remet pas en question).

Sur ma clé USB j’ai :

# mdadm Debian configuration
#
# You can run ‘dpkg-reconfigure mdadm’ to modify the values in this file, if
# you want. You can also change the values here and changes will be preserved.
# Do note that only the values are preserved; the rest of the file is
# rewritten.
#

# INITRDSTART:
# list of arrays (or ‘all’) to start automatically when the initial ramdisk
# loads. This list *must* include the array holding your root filesystem. Use
# ‘none’ to prevent any array from being started from the initial ramdisk.
INITRDSTART=’all’

# AUTOSTART:
# should mdadm start arrays listed in /etc/mdadm/mdadm.conf automatically
# during boot?
AUTOSTART=true

# AUTOCHECK:
# should mdadm run periodic redundancy checks over your arrays? See
# /etc/cron.d/mdadm.
AUTOCHECK=true

# START_DAEMON:
# should mdadm start the MD monitoring daemon during boot?
START_DAEMON=true

# DAEMON_OPTIONS:
# additional options to pass to the daemon.
DAEMON_OPTIONS= »–syslog »

# VERBOSE:
# if this variable is set to true, mdadm will be a little more verbose e.g.
# when creating the initramfs.
VERBOSE=false

# MAIL_TO:
# this variable is now managed in /etc/mdadm/mdadm.conf (MAILADDR).
# Please see mdadm.conf(5).

Bon, vous imaginez la suite …
Je modifie dans /mnt/sda1/etc/default/ :
# Modif Goupildb :
# INITRDSTART=’none’
INITRDSTART=’all’

# Modif Goupildb :
# AUTOSTART:
# should mdadm start arrays listed in /etc/mdadm/mdadm.conf automatically
# during boot?
AUTOSTART=true

# Modif Goupildb :
# VERBOSE=false
VERBOSE=true

J’enregistre.
Et dans mon chroot je lance :
# dpkg-reconfigure mdadm

Configuration de mdadm
Si le système de fichiers racine se trouve sur un ensemble MD (RAID), il doit être lancé au début de la procédure de démarrage. Si le système de fichiers racine se trouve sur un volume logique (« LVM »), qui se trouve aussi sur un volume MD, tous les composants de l’ensemble doivent être démarrés.

Si vous savez exactement quels sont les ensembles RAID nécessaires au démarrage du système de fichiers racine et si vous souhaitez différer le démarrage de tous les autres ensembles, veuillez les indiquer ici. Vous pouvez aussi indiquer « all » pour démarrer tous les ensembles existants.

Si vous n’avez pas besoin ou ne souhaitez pas démarrer d’ensemble RAID pour le système de fichiers racine, veuillez laissez l’entrée vide (ou entrez « none »). Ceci peut être le cas si vous utilisez l’option de démarrage automatique (« autostart ») du noyau ou si vous n’avez besoin d’aucun ensemble pour démarrer.

Veuillez indiquer « all », « none » ou une liste de périphériques, séparés par des espaces, par exemple, « md0 md1 » ou « md/1 md/d0 » (vous pouvez omettre « /dev/ »).

Ensembles MD requis par le système de fichiers racine :
none

(j’ai changé d’avis : je vais tester « none » puisqu’effectivement j’ai ajouté l’option AUTOSTART=true, mon disque de démarrage /dev/sda1 est un disque SSD qui n’est pas monté en RAID)

Lorsque le système de base a démarré, mdadm peut démarrer tous les ensembles (RAID) indiqués dans /etc/mdadm/mdadm.conf qui n’ont pas encore été démarrés. Cela est recommandé, sauf si la gestion MD a été compilée dans le noyau et que toutes les partitions faisant partie d’un ensemble RAID ont été marquées avec le type 0xfd (car seul ce type de partition sera démarré automatiquement par le noyau).

Faut-il démarrer automatiquement les ensembles RAID ?
Oui

Si le noyau le gère (à partir de la version 2.6.14), mdadm peut vérifier périodiquement la redondance des ensembles RAID. Cette action peut demander beaucoup de ressources selon la configuration, mais cela aide à prévenir les rares cas de pertes de données. Notez que ce test est réalisé en lecture seule à moins que des erreurs ne soient rencontrées. Si des erreurs sont détectées, mdadm essayera de les corriger, ce qui entraînera des écritures sur le média.

Par défaut, la vérification s’effectuera tous les premiers dimanche du mois à 01 h 06.

Faut-il vérifier chaque mois la redondance des ensembles RAID ?
Oui

Le démon de surveillance MD envoie des notifications par courriel lors d’importants événements MD (comme une panne de disque dur).

Il est recommandé d’activer cette option.

Faut-il démarrer le démon de surveillance MD ?
Oui

Veuillez indiquer l’adresse électronique de l’utilisateur qui doit recevoir les notifications lors d’importants événements MD.

Destinataire des notifications par courriel :

goupil2

Running in chroot, ignoring request.
update-initramfs: deferring update (trigger activated)
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
Running in chroot, ignoring request.
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
Running in chroot, ignoring request.
Traitement des actions différées (« triggers ») pour initramfs-tools (0.123) …
update-initramfs: Generating /boot/initrd.img-4.4.0-1-rt-686-pae
I: mdadm: using configuration file: /etc/mdadm/mdadm.conf
I: mdadm: no MD arrays will be started from the initial ramdisk.
I: mdadm: use `dpkg-reconfigure –priority=low mdadm` to change this.

Je vais redémarrer.
Si çà ne fonctionne pas, je lancerai le démarrage de mdadm dès la procédure de démarrage.
Suspens …

Ca ne marche pas :(

Je retrouve mon fichier /etc/default/mdadm (du disque à réparer):

# mdadm Debian configuration
#
# You can run ‘dpkg-reconfigure mdadm’ to modify the values in this file, if
# you want. You can also change the values here and changes will be preserved.
# Do note that only the values are preserved; the rest of the file is
# rewritten.
#

# INITRDSTART:
# list of arrays (or ‘all’) to start automatically when the initial ramdisk
# loads. This list *must* include the array holding your root filesystem. Use
# ‘none’ to prevent any array from being started from the initial ramdisk.
INITRDSTART=’none’

# AUTOCHECK:
# should mdadm run periodic redundancy checks over your arrays? See
# /etc/cron.d/mdadm.
AUTOCHECK=true

# START_DAEMON:
# should mdadm start the MD monitoring daemon during boot?
START_DAEMON=true

# DAEMON_OPTIONS:
# additional options to pass to the daemon.
DAEMON_OPTIONS= »–syslog »

# VERBOSE:
# if this variable is set to true, mdadm will be a little more verbose e.g.
# when creating the initramfs.
VERBOSE=true

Effectivement il a bien pris mes paramètres mais a effacé mes commentaires – ce qui est bien précisé en début de fichier.
MAIS il a enlevé l’option :
# Modif Goupildb :
# AUTOSTART:
# should mdadm start arrays listed in /etc/mdadm/mdadm.conf automatically
# during boot?
AUTOSTART=true

Ils ont donc changé le comportement de mdadm qui ne démarre plus les grappes RAID (car il supprime automatiquement l’option « AUTOSTART=true ») dès qu’il est reconfiguré (ce qui est probable lors du changement de version via dpkg/apt/synaptic) : Bug !
Bug car s’il fait çà, au minimum il devrait retenir l’option INITRDSTART=’all’ pour respecter le souhait de l’utilisateur de démarrer ses disques RAID dès le démarrage !
Il faut donc à présent absolument retenir l’option INITRDSTART=’all’ pour être sûr que les disques RAID soient montés au démarrage, sous peine de plantage magistral.

Donc je change :
INITRDSTART=’none’
pour :
INITRDSTART=’all’

# Modif Goupildb :
# AUTOSTART:
# should mdadm start arrays listed in /etc/mdadm/mdadm.conf automatically
# during boot?
AUTOSTART=true

ET je ne lance PAS : # dpkg-reconfigure mdadm
(il est précisé en début de fichier « if you want. You can also change the values here and changes will be preserved. »)

Je reboot …

Résultat :
Re-bug !
J’ai les mêmes messages avec le noyau 4.3 (pas de montage des grappes RAID du fait de l’option non sélectionnée dans /etc/default/mdadm) et le noyau 4.4 bloque aussi.
Donc contrairement à ce qui est écrit dans le fichier /etc/default/mdadm, il faut absolument lancer un :
# dpkg-reconfigure mdadm
pour le configurer et du coup on perd l’option AUTOSTART qui n’est pas reprise et dans ce cas il faut absolument retenir INITRDSTART=’all’

# dpkg-reconfigure mdadm
Running in chroot, ignoring request.
update-initramfs: deferring update (trigger activated)
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
Running in chroot, ignoring request.
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
Running in chroot, ignoring request.
Traitement des actions différées (« triggers ») pour initramfs-tools (0.123) …
update-initramfs: Generating /boot/initrd.img-4.4.0-1-rt-686-pae
I: mdadm: using configuration file: /etc/mdadm/mdadm.conf
I: mdadm: will start all available MD arrays from the initial ramdisk.
I: mdadm: use `dpkg-reconfigure –priority=low mdadm` to change this.

A noter aussi que visiblement il ne met à jour que l’initrd.img du noyau par défaut (ici le 4.4.0) et ne met pas à jour les autres !
Re-re-bug (à quoi çà sert de pouvoir sélectionner plusieurs noyaux sous Grub quand un seul n’est mis à jour ?)

Redémarrage …

Bingo !!!
Ca démarre !

Me revoilà sur mes unités de disques de base, exit la clé de dépannage et le chroot.
Il me reste encore un certain nombre de tâches à régler et des mises à jour à faire, mais çà démarre. Ca me fait bigrement plaisir de retrouver MATE et mon environnement.

Ce qu’il me reste à régler :
– Je démarre et utilise le noyau 4.4.0-1-rt-686-pae, mais après l’avoir laissé un moment au repos, mon système était complètement léthargique. Il ne m’a pas l’air super stable.
– le splash est activé sous Grub et du coup pendant toute la phase de démarrage je ne vois rien (sauf à démarrer en mode dépannage).

Je met mon système à jour et en profite pour virer linux-image-4.4.0-1-rt-686-pae au profit de linux-image-4.4.0-1-686-pae (en 2 étapes car je ne peux pas supprimer un noyau que je suis entrain d’utiliser simultanément), en espérant que les mises à jour ne vont pas m’attirer de nouveaux ennuis :)

Ouaouhh. Décidément, c’est la journée des bonnes nouvelles. Ce noyau linux-image-4.4.0-1-686-pae est décoiffant ! : il démarre mon système en 30 secondes chrono (du lancement via grub à l’invit de connexion en console, juste avant lightdm) vs près d’1 minute précédemment.
Du coup c’est lightdm qui se fait attendre un peu : à lui seul il prend 7-8 secondes à se lancer.

Bilan des MAJ du 18 au 20 mars (le coupable se trouve forcément là-dedans, bon d’accord çà a été un peu violent :) ) :

Les paquets suivants ont été supprimés :
(liste supprimée : trop longue et sans intérêt)

Un debriefing s’impose pour en tirer quelques leçons :
☑ Le paquet qui a semé le trouble est mdadm ainsi qu’un autre non identifié (bug de cet autre corrigé après une mise à jour, mais je n’ai pas pu identifier le coupable : il s’en sort bien :) ).
☑ En ce qui concerne mdadm, il ne s’agissait pas d’un bug à proprement parlé, mais d’une modification de son paramétrage (après un upgrade) rendant non fonctionnel le précédent, et ceci sans avertissement de l’utilisateur – raison pour laquelle j’assimile ceci à un bug. Cette modification est intervenue lors du passage de la version 3.3.4-1 à la version 3.4-1 (survenue le 28 mars d’après synaptic, merci aux développeurs pour la fonctionnalité de recherche dans l’historique de synaptic).
☑ Le plantage de mon PC à eut lieu le 21 mars, suite à des mises à jour intervenues les 18, 19 et 20 mars sans redémarrer le PC (mise en veille et non extinction du PC). Soit 7 jours avant le changement de version de mdadm, donc il semble acquis qu’un autre paquet est à l’origine d’un 1er plantage et que mdadm est venu compliquer la situation.
☑ les jours qui ont suivis, j’ai mis à jour à peu près tout ce qui pouvait l’être, ce qui ne permet plus de retrouver quel était le paquet défectueux.
☑ La mise à jour de mdadm a provoqué l’interruption du démarrage automatique des disques montés en RAID 1.
☑ Mon diagnostique a été faussé / rendu particulièrement difficile à établir du fait :
• que le noyau 4.4.0 (contrairement au noyau 4.3) fraîchement installé n’indique pas que la grappe RAID n’est pas montée (il s’agit pourtant d’une information cruciale, elle devrait être affichée en rouge et dans les derniers messages juste avant l’arrêt : « Warning: INITRDSTART set to « none » in /etc/default/mdadm, not assembling raid arrays »). Le noyau 4.4.0 indique simplement que /dev/md3 n’existe pas.
• que le noyau 4.3.0 ne démarre pas sur ce PC. Il ne démarre toujours pas alors que le 4.4.0 démarre. En revanche il m’a permis de voir le message d’erreur clé énoncé ci-dessus : je remercie chaudement le développeur qui a pensé à mettre ce message :)
• que le noyau 3.2.0 ne démarrait plus sur ce PC (sauf via la clé USB), il ne parvenait plus à monter le SSD en /dev/sda (qui n’est pourtant pas en RAID, message « Kernel panic – not syncing: VFS: Unable to mount root fs on unknown-block (0,0) »). Après avoir créé son fichier /boot/initrd.img, il ne démarrait pas davantage. Bizarrement, à présent il démarre, mais avec un clavier QWERTY et sans accélération graphique. Le problème est que j’ai le réseau 1 fois sur 4 (voir plus bas), donc je verrai cela plus tard.
• que mdadm fonctionne, mais :
⚬ que contrairement à ce qui est indiqué dans le fichier de configuration de mdadm (/etc/default/mdadm) la simple modification du fichier ne suffit pas / ne sert à rien. Pour que les paramétrages soient pris en compte, il faut absolument lancer la commande « # dpkg-reconfigure mdadm » et répondre aux questions.
⚬ que la commande « # dpkg-reconfigure mdadm » efface vos paramètres et commentaires précédents si vous les avez écrits dans le fichier.
⚬ que la commande « AUTOSTART=true » – permettant de démarrer le RAID automatiquement au démarrage, vient d’être supprimée dans cette version 3.4-1 (il manque clairement une communication pour les utilisateurs : il faut les prévenir via une fenêtre quand ce genre de modif intervient). Elle est à présent remplacée par la commande INITRDSTART=’all’ (vs INITRDSTART=’none’, qui existait déjà, mais que l’on pouvait remplacer par « AUTOSTART=true », ce qui n’est plus le cas).
• que la commande « # fdisk -l » affiche des messages « Warning: Partition xx does not end on cylinder boundary ». Je viens de la relancer pour voir : les messages sont toujours présents. Ils m’ont induit en erreur. Les disques sont sains (confirmé par l’utilitaire Palimpsest et par la commande « # mdadm –misc –detail /dev/md3 »). Ce message reste néanmoins à creuser (c’est fait : voir ci-dessous).
☑ Dans mon script de chroot, la commande « # mount -a » ne fonctionne pas ! (bug). Il est nécessaire de la relancer manuellement en console. Ce bug m’aura là aussi fait perdre pas mal de temps avant que je ne finisse par me rendre compte que ma grappe RAID n’était pas montée et que je ne travaillais non pas sur 2 disques miroirs mais sur un seul (toutes mes mises à jours de paquets ne se faisaient que sur un seul disque. Lors du montage en RAID le 2nd disque apairé remplaçait le contenu du 1er – et donc c’est comme si je n’avais rien fait). A l’usage je constate que la manière la plus fiable de détecter un non montage des grappes RAID est d’utiliser KDiskFree ou de lancer la commande « # fdisk -l ». Pour cette dernière, si les disques RAID ne sont pas apairés, elle affiche pour chaque partition le message « fd RAID Linux autodétecté » mais aussi « Le disque /dev/mdx ne contient pas une table de partitions valable ». Message très inquiétant mais qui finalement se révèle être un bon révélateur d’un non montage RAID. La commande « # watch cat /proc/mdstat » ne semble pas très fiable à ce sujet : elle affichait que les disques étaient apairés alors qu’ils ne l’étaient pas. De même, se méfier des messages au démarrage de ma clé USB (noyau 3.2) quand ils disent que les disques RAID sont montés sans afficher la moindre erreur (alors qu’ils ne l’étaient pas).
☑ Palimpsest est l’outil de référence (qui de plus rassure … ou non :) ) pour vérifier ses disques. Il est fiable.
☑ apt-listbugs est un paquet plus important / dangereux qu’il n’y paraît au premier abord (celui de signaler des paquets défectueux) : en cas de plantage, il peut planter apt, dpkg et aptitude. J’ai bien cru que j’allais être obligé de réinstaller mon OS.
☑ les paquets hal et hal-info ont été supprimés des dépôts Debian Sid. Aujourd’hui il me reste encore les paquets libhal-storage1 et libhal1 qui sont dans Debian wheezy (old). Je viens de les désinstaller car visiblement ils ne servent plus à rien.
☑ les miroirs Debian à travers le monde ne sont pas exactement des « miroirs ». J’ai constaté sur certains (Européens) des anomalies « Somme de contrôle de hachage incohérente » alors que sur le miroir US je n’en avais pas.
☑ Rappel du chroot (script) :
# /bin/bash
mount -t ext3 /dev/sda1 /mnt/sda1
mount -o bind /proc /mnt/sda1/proc
mount -o bind /dev /mnt/sda1/dev
mount -o bind /sys /mnt/sda1/sys
mount /dev/pts
chroot /mnt/sda1
Inutile d’ajouter « mount -a », çà ne marche pas, le faire manuellement en console.
☑ Pour avoir Synaptic en chroot depuis une clé USB :
Installer iceWm via le chroot si ce n’est déjà fait.
Sur la console 2, on lance :
# Xnest -ac :1 -fp /usr/share/fonts/X11 &
(éventuellement Ctrl C pour reprendre la main)

Retour sur la console 1 (chrootée) :
# export DISPLAY=127.0.0.1:1
# icewm-session &
☑ en cas de souci avec le message « contient l’élément de données non compris (data.tar.xz ), abandon », lzma est à remplacer par les paquets liblzma5 et xz-utils.
☑ une commande intéressante : « # update-initramfs -h » (affiche les options disponibles) pour mettre à jour les initramfs des noyaux. Exemple de commande lancée ce matin à partir de mon noyau 4.4 :
# update-initramfs -k 3.2.0-4-686-pae -ut
update-initramfs: Generating /boot/initrd.img-3.2.0-4-686-pae
I: mdadm: using configuration file: /etc/mdadm/mdadm.conf
I: mdadm: will start all available MD arrays from the initial ramdisk.
I: mdadm: use `dpkg-reconfigure –priority=low mdadm` to change this.

☑ je pense raisonnablement que la mise en veille / hibernation peut être écartée des causes de mes problèmes informatique. Néanmoins après une grosse mise à jour il vaut mieux effectuer un redémarrage afin de détecter au plus vite un éventuel problème.
☑ il manque un outil de dépannage accessible depuis Grub ou équivalent. Cet outil permettrait de lancer un noyau robuste et stable avec un script de diagnostic / réparation robuste tel que çà se fait sous Windows. Personnellement j’arrive encore à m’en sortir pour dépanner mon système, mais il est vraisemblable que des utilisateurs moins expérimentés jettent l’éponge et retournent sous leur OS privateur après une ou plusieurs expériences de ce type. En ce qui me concerne, Linux Debian répond pleinement à mes attentes côté fonctionnalités et utilisation au quotidien, mais ces bugs à répétition tous les ans me laissant seul ou presque (il y a internet et j’ai heureusement un autre vieux PC fonctionnel) me gavent au plus haut point. Le manque d’outils de diagnostique et de dépannage efficaces et simples est criant. S.V.P. : aidez-nous les utilisateurs.

Voilà, c’est à peu près tout ce que j’ai appris avec cette galère. C’est pas si mal.
Pas mécontent d’arriver au bout.
Malgré le bon fonctionnement général, je vais encore creuser les messages « Warning: Partition x does not end on cylinder boundary »

Ce Blog : (Blog O’ Matty) Why “partition X does not end on cylinder boundary” warnings don’t matter est assez rassurant, « This was a bit disconcerting at first, but after a few minutes of thinking it dawned on me that modern systems use LBA (Logical Block Addressing) instead of CHS (Cylinder/Head/Sector) to address disk drives. If we view the partition table using sectors instead of cylinders ».
Si j’ai bien compris, c’est lié à l’utilisation de LBA sur les systèmes modernes, vs CHS.
Mais alors pourquoi mettre des messages si alarmants ?
Information confirmée sur les forums Ubuntu : « It is not a problem.
Drives have not used cylinder boundaries since hard drives exceeded 8GB and BIOS uses LBA or large block allocation. But all the partition tools thru Linux & XP installs still followed cylinders so partition tools never changed the error messages. ».

————————————————————————————————————
Le 3 avril 2016

Il me reste quelques trucs horriblement agaçants à régler (mais pas nécessairement tous aujourd’hui) :
– A chaque arrêt ou redémarrage, j’ai un message « A stop job is running for Make remote CUPS printers available locally » avec une minuterie réglée sur quelque-chose comme 2m30 (de mémoire, c’est peut-être un peu moins). Mon imprimante est connectée sur le PC internet, et j’utilise CUPS pour imprimer à la fois depuis ce PC internet et depuis le PC du Bottin (heureusement que mon scanner est sur le PC du Bottin sinon j’aurais en plus SANE :) ). Pas moyen d’arrêter ce foutu compteur (j’ai bien-sûr essayé le Ctrl C, le Ctrl Back Space et le Ctrl Alt Suppr) : la dictature du compteur, faut attendre qu’il s’égrène. Avec ce qui suit vous allez comprendre mon agacement au plus haut point.
– Depuis la période à laquelle j’ai mis à jour le PC internet, le démarrage de la liaison réseau entre le PC internet et le PC du Bottin est erratique : la plupart du temps il ne démarre pas (en moyenne il démarre 1 fois sur 4 ou sur 5) et la seule manière de le faire fonctionner est de redémarrer le PC du Bottin voir parfois (comme ce matin) les 2 PC ! Je suis certain que le souci est sur le PC du Bottin car avec la clé USB (noyau 3.2) branchée sur le PC du Bottin, j’ai le réseau dans 100% des cas. Vous imaginez ce souci conjugué au précédent :) Je dois attendre 3 x 2 min 30 l’extinction du PC + les redémarrages complets avant de pouvoir espérer avoir de l’internet. Comme les boutons reset et extinction sont tout proches : j’avoue, parfois je ne résiste pas :) C’est pas bon pour mon Linux çà. Le souci vient soit du noyau, soit de l’infrastructure logicielle du réseau. J’aimerai bien arriver à faire fonctionner le noyau 3.2.0 pour vérifier cela (pour l’instant je n’ai que le 4.4 de fonctionnel, et je sais qu’avec la clé USB sous le noyau 3.2 çà fonctionne bien).

Plusieurs heures plus tard …

Voilà, la majeure partie de mes problèmes sont résolus :
– j’ai cherché dans /etc/ le moyen de raccourcir la durée d’attente de la minuterie ci-dessus, mais je n’ai rien trouvé. Du coup j’ai essayé du côté de http://localhost:631/. Je n’ai pas trouvé non plus. Pas de job en attente. J’ai essayé de supprimer des imprimantes (les drivers sont en double). J’ai pu en supprimer mais 2 sont restées. Je les ai réinstallé. Ensuite j’ai mis à jour tous les paquets du PC internet. L’idée initiale n’était que de ne mettre à jour CUPS pour écarter tout problème éventuel de communication entre 2 versions différentes du même logiciel ; je l’ai finalement étendu à la mise à jour de tous les paquets :) . J’en ai aussi profité pour installer le noyau 4.4 qui est vraiment plus rapide que les précédents. Tout fonctionne à présent – sauf l’imprimante qui semble recevoir (voyant clignotant) mais n’imprime pas. Je verrais çà plus tard. Pour l’instant le souci avec le compteur lors de la phase d’arrêt ne s’est pas reproduit (2 ou 3 redémarrage de REX). Je croise les doigts pour que çà soit résolu.
– Sur le PC du Bottin je suis parvenu à démarrer sur le noyau 3.2 et à installer l’accélération graphique (# m-a a-i -f nvidia-legacy-340xx-kernel-source). Donc bonne nouvelle, j’ai à présent un 2nd noyau fonctionnel de secours. Internet semble bien fonctionner, mais pour l’instant je n’ai pas assez de REX de redémarrage pour être sûr que çà marche systématiquement. J’ai redémarré sur le noyau 4.4 avec le réseau du 1er coup. A voir si c’est à nouveau fiable. Wait & See.

De retour donc sur le Bottin …

————————————————————————————————————
Épilogue, le 5 avril 2016

Je suis à présent pleinement satisfait (au moins jusqu’à aujourd’hui :) ) des récentes mises à jour de ma Debian Sid :
• Grâce au récent noyau 4.4.0 et aux derniers scripts de démarrage, mes 2 PC démarrent pratiquement 2 fois plus rapidement (environ 30 secondes de Grub à LightDM vs près d’1 minute avant) et s’arrêtent en un temps record (à peine 10 secondes) !
• Le PC du Bottin a démarré du premier coup avec l’accès réseau. Je croise les doigts pour que çà continue.

Un grand merci aux développeurs pour leur réactivité !

Laisser un commentaire