Un peu de lecture ici.

iotop

sudo apt install iotop
sudo iotop

Permet de voir, à la manière de top, l’activité I/O des disques par processus. Ne distingue toutefois pas sur quel disque l’activité se produit.

dstat

sudo apt install dstat
dstat pour avoir un aperçu général.
dstat -d -D total,sdk,md0 pour n’afficher que les infos relatives aux disques (-d), et surveiller l’ensemble des I/O dans une colonne (-D total), /dev/sdk dans un autre (-D sdk)et /dev/md0 dans une autre (-D md0).

iostat

sudo apt install sysstat
iostat pour avoir des infos générales depuis le boot.
iostat -y 1 2 pour avoir des infos uniquement dans l’intervalle temporel spécifié ; ici : 1s, analyse répétée 2 fois (1 2). Si le 2e chiffre n’est pas spécifié, l’analyse sera faite en boucle.
iostat -d pour n’inclure que l’info relative aux disques.
iostat -p sdk,md0 pour n’inclure que l’info relative à ces périphériques.
iostat -t pour inclure le timestamp

En cumulant ces options, et avec l’utilisation de watch, on tombe sur un truc comme ça :
watch -t -n 0.1 iostat -p sdk,md0 -d -t -y 1 1

nmon

sudo apt install nmon
nmon puis presser la touche d

https://support.apple.com/fr-fr/HT201255
https://support.apple.com/fr-fr/HT204904

Alt : Boot menu
⇧ : Mode sans échec
Super+S : Mode monoutilisateur (root en CLI)

Super+R : Récupération via partition de récup (OS actuel)
Alt+Super+R : Récupération via internet (OS le plus récent compatible)
⇧+Alt+Super+R : Récupération via internet (OS d’origine, ou le plus proche encore disponible sur les serveurs)

Alt+Super+P+R : reset PRAM
Alt+⇧+Ctrl : reset SMC

D : AHT
Alt+D : AHT via internet

Suite à un changement de carte-mère, et donc à un remplacement de la puce TPM dedans, il peut arriver d’avoir des messages d’erreur (notamment 0x80090016) à l’ouverture de session Windows, ou Outlook (ou autre ?).

Ceci semble lié au fait que les infos d’identification étaient chiffrées grâce à un jeu de clés situé matériellement dans la puce TPM.
Pour corriger ceci, il faut renommer le dossier

C:\users\%username%\AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy

en .OLD (ou le supprimer…). Puis fermer la session.

Les infos d’identification seront redemandées au prochain lancement de la session ou de l’appli (et, je suppose, chiffrées grace au nouveau jeu de clés de la nouvelle puce).

Source

Il semble que dans certains cas (visiblement en lien avec la protection par code PIN), la solution soit plutôt (ou aussi ?) de supprimer le contenu du dossier

C:\Windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\Ngc\

/sbin/ntfsresize --force --no-action -s 100G /dev/sdX1 | grep -e ERROR -e relocations

--force peut ne pas être nécessaire
-s indique la nouvelle taille de partition, par défaut en octets, et peut être suivi des suffixes k,M,G,ki,Mi ou Gi

On peut aussi

Avec 12 disques (a -> l)

for i in {a..l}; do echo sd$i; udevadm info --query=all --name=/dev/sd$i | grep ID_SERIAL_SHORT; done

Sous Linux, il arrive que, pour économiser de l’énergie, la carte son se mette en veille après quelques temps d’inactivité. Ceci génère chez moi des craquements assez désagréables lors de sa remise en fonctionemment, ou parfois un craquement très régulier tout le long de la veille.

Pour voir si la mise en veille est activée :

cat /sys/module/snd_hda_intel/parameters/power_save

S’il contient autre chose que 0, alors le mode powersave est activé.

Pour le désactiver, on peut ajouter le fichier /etc/modprobe.d/snd_disable_powersave.conf et entrer dedans la ligne suivante :

options snd_hda_intel power_save=0

Puis redémarrer, ou bien décharger/recharger le module.

Disques tous en spare

Après une panne d’éléctricité, un RAID6 de 12 disques (dégradé, avec 1 disque manquant) a refusé de se remettre en route. Après vérification (par live-cd) via un cat /proc/mdstat, les 11 disques étaient tous en spare (se manifeste par un [S] ).
Pour ce raid sont utilisées les 2e partitions de chaque disque de sda -> sdk. J’ai vérifié l’état de synchronisation de tous les volumes : sudo mdadm --examine /dev/sd[abcdefghijk]2 | grep Events

Events : 2845752
Events : 2845752
Events : 2845752
Events : 2845752
Events : 2845752
Events : 2845752
Events : 2845752
Events : 2845752
Events : 2845752
Events : 2845752
Events : 2845752

Ils sont bien synchronisés, mais pas assemblés. J’ai alors testé
sudo mdadm --assemble --force /dev/md126 /dev/sd[abcdefghijk]2
mais ai obtenu 11 jolis “Device or ressource busy”. Ce qui est normal, les disques étant intégrés dans le RAID, mais en spare. J’ai alors lancé
sudo mdadm --stop /dev/md126
suite à quoi la commande d’assemblage précédemment citée a bien fonctionné, le RAID s’est resynchronisé sans perdre de données, en prenant toutefois son temps.

RAID fonctionnel qui ne se synchronise pas tout seul

Dans un autre cas, où le RAID était resté fonctionnel mais dans lequel un volume manquait (sdl2, détecté mais non intégré/synchronisé), j’ai pu le réintégrer avec la commande sudo mdadm --re-add /dev/md126 /dev/sdl2 (si re-add ne fonctionne pas, add devrait fonctionner mais prendre plus de temps).

Dans encore un autre cas, un seul disque était intégré au RAID, mais non synchronisé, car il restait en “spare”. J’ai pu forcer la réintégration avec la commande
echo check > /sys/block/md126/md/sync_action
De la lecture intéressante se trouve sur cette page.

Ici aussi : https://robbat2.livejournal.com/231207.html?nojs=1

Exclure disque d’un raid

Il doit être marqué en failed ; soit par mdadm suite à erreur de lecture ou autre, soit manuellement par :

sudo mdadm /dev/mdX --fail /dev/sdX

Il peut alors être retiré :

sudo mdadm /dev/mdX --remove /dev/sdX

Suite à quelques soucis de recherche dans la base CDDB avec Asunder, voici un mini-tuto pour abcde. Déjà,

sudo apt install abcde lame eyed3 glyrc imagemagick cdparanoia

Les préférences d’extraction se définissent dans le fichier /etc/abcde.conf ou bien dans un fichier user qui outrepassera le précédent, et que nous éditons ici : pluma ~/.abcde.conf

# VBR bonne qualité
LAMEOPTS='-V 0'
# On extrait la couverture
ACTIONS=default,getalbumart
# On range les fichiers finaux dans ce dossier :
OUTPUTDIR="/path/to/music/dir"
# On encode en mp3
OUTPUTTYPE=mp3
# Arborescence type Artiste/Album/01 - Morceau.mp3
OUTPUTFORMAT='${ARTISTFILE}/${ALBUMFILE}/${TRACKNUM} - ${TRACKFILE}'
# On ne remplace PAS les espaces par des underscores (et autres modifs)
mungefilename ()
{
echo "$@"
}

On peut ensuite lancer abcde ou encore abcde -d /dev/sr1 si on spécifie manuellement le lecteur CD.

Enfin, dans le dossier final, si on souhaite intégrer la pochette au fichier :

for i in *.mp3
do
eyeD3 --add-image cover.jpg:FRONT_COVER "$i"
done

(cf cette page)

Habituellement, lorsque je souhaite installer une Debian sur un pc avec double carte graphique Intel-Nvidia (système Optimus), il suffit d’installer bumblebee via apt install bumblebee bumblebee-nvidia (ou simplement bumblebee si on souhaite essayer avec les pilotes libres Nouveau, ce qui m’a semblé fonctionner moins souvent).
La configuration des paquets met en place toute la configuration nécessaire (glx, alternatives, modprobe/blacklist etc). Ceci installe également un module noyau bbswitch, dont le but est d’éteindre ou d’allumer à la demande la carte graphique dédiée.

Cependant, sur un poste, après avoir installé ces paquets, le pc freezait au démarrage, que le pilote soit nouveau ou nvidia. Comme le pc démarrait correctement en mode recovery, j’ai désactivé le lancement automatique du gestionnaire de connexion graphique. Ainsi, le pc démarrait correctement, je pouvais me connecter, mais dès le moindre service lightdm start ou startx, il freezait à nouveau. Après pas mal de lecture, j’ai appris que le fichier /proc/acpi/bbswitch contenait entre autre l’état de la carte graphique (ON ou OFF), et que la commande tee /proc/acpi/bbswitch <<<ON permettait de l’allumer à la demande.
Et j’ai constaté que la carte était en OFF à chaque démarrage, que si on essayait de lancer un programme graphique (même une interface graphique qui tourne sur la carte intégrée au CPU) alors que la carte dédiée était OFF, alors ça freezait. Si par contre on allumait manuellement la carte avant, on pouvait lancer l’interface, et ensuite ça fonctionnait, même si la carte était coupée. Mais si on souhaitait simplement se déconnecter, comme ceci coupe puis relance l’interface graphique, alors ça freezait à nouveau…

Mais avec le détail des cas où ca plantait, j’ai facilement trouvé ce rapport de bug, et après moult tests, modifier la ligne dans le fichier /etc/default/grub pour qu’elle ressemble à ceci :

GRUB_CMDLINE_LINUX_DEFAULT="quiet acpi_osi=! acpi_osi='Windows 2009'"

suivi d’un update-grub a bien fonctionné ! Les graphiques standards sont bien lancés sur le gpu intégré, le gpu dédié est éteint la plupart du temps, allumé correctement lorsqu’on lance un programme avec optirun, et bien éteint lorsque ce programme se termine.

HPBR

Un outil nommé HP Bios Reset permet, sur certains modèles, notamment des Probook et des Elitebook, de réinitialiser le mot de passe du bios. Lien vers le thread mydigitallife.
Et un exemplaire de HPBR mirroré chez moi

Il faut déjà créer la clé bootable.
Depuis Windows, il suffit de lancer l’exécutable, de brancher la clé (qui sera effacée), la sélectionner, cliquer sur Restore, choisir le fichier image fourni dans l’archive.
Sous Linux, je n’ai pas testé, mais je présume que l’image se dumpe simplement sur la clé avec dd.

On boote l’ordinateur sur la clé. Au lancement, il faut en trer les commandes suivantes :

cd ..
HPBR

Dans “reprogram” on peut sauvegarder les informations actuelles (fichiers .sav dans le répertoire HPBR).
Dans “first run” on peut lancer la réinit du mot de passe du bios en choisissant le bon modèle.

Forcer l’upgrade du bios

Dans mon cas, le bios était trop vieux, et n’était pas supporté par HPBR. J’ai donc du faire la mise à jour, mais la procédure standard me demandait le mot de passe, que je n’avais toujours pas.

Pour ceci, des indications données sur ce post peuvent être utiles. Les images et signatures de BIOS sont stockées dans le dossier Hewlett-Packard/BIOS/Current. L’image HPBR en contient certains, mais pas tous. On peut donc rajouter celui d’un autre modèle.
J’ai donc récupéré le bios le plus récent sur le site de support de HP.
J’ai extrait le fichier exe, puis le fichier rom.cab.
Dedans, il y’a un fichier “ver.txt”, on trouve dedans le numéro de la ROM, par exemple _ROM_ 68PDD v0F.20 12/07/2011 ROLL_BACK_WARNING
Dans ce cas, c’est “68PDD”. On renomme rom.bin par 68PDD.bin et efibios.sig par 68PDD.sig, on copie ces 2 fichiers dans “Current” (à noter que sur un clé usb vierge en fat32, l’arborescence et ces 2 fichiers suffisent pour la MAJ du BIOS, pas besoin de HPBR).
On éjecte la clé proprement.

Ensuite, il faut faire booter l’ordi sur la clé, mais pas par le boot habituel. Il faut, ordi éteint, brancher la clé, maintenir Super+B, allumer le pc en maintenant les touches enfoncées, normalement la LED de VerrMaj clignote, puis le voyant de la clé usb (s’il y’en a un…) va commencer à clignoter. C’est le moment de relacher les touches.

Normalement l’écran reste noir, pendant au maximum 2 minutes (selon le readme), puis devrait redémarrer tout seul et informer du succès de la mise à jour. Il est alors possible de reset le mot de passe via HPBR
Si rien ne se passe au bout de 10 minutes (soyons précautionneux…) ,c’est que la MAJ n’a pas réussi, et il faut redémarrer le poste.