pense-bête de bruno sanchiz

secure boot

bruno — 2024-08-12T15:48:49Z

secure boot

Le secure boot est une "protection" présente dans le bios. Elle peut empêcher de démarrer sur une clé usb.

Pour démarrer sur une clé usb, il faut parfois désactiver le secure boot, parfois il faut aussi créer un mot de passe boot.

Pour cela il faut aller dans le bios et désactiver(disabled) secureboot

https://blog.liberetonordi.com/index.php?post/astuces-installation-Linux
https://doc.ubuntu-fr.org/desactiver_secure_boot

TPM

désactiver TPM dans le bios :

chercher trus, security ou un truc du genre
chercher TPM state OU security chip OU security device support ... sur disabled, oof ...

passer un système Debian avec Secure Boot desactivé vers un Secure Boot activé

d'après https://www.debian-fr.org/t/activer-le-demarrage-securise-secure-boot-dans-debian/91380 de @zargos
Attention, pas encore testé !

Introduction
L'installation d'un systsème Debian sur une machine où Secure Boot est activé se passe normallement assez bien, et le résultat sera un système avec Secure Boot activé utilisant la clef par défaut Debian.
Quand il s'agit de passer un système Debian avec Secure Boot desactivé vers un Secure Boot activé c'est une autre paire de manche.
Je vais essayer ici de vous donner la démarche que j'ai suivi avec ma machine sur laquelle est installée Debian 12 Bookworm sur deux disques NVME entièrement chiffrés (LVM over LUKs).
Les documents sources que j'ai utilisé sont les suivants et j'en remercie leurs auteurs :
Detlev Zundel : Switching on Secure Boot in Debian :

Je me permet d'en utiliser une bonne partie directement, pour le traduire à l'usage des non-anglophones tout en y ajoutant mes propres éléments.

En quoi consiste Secure Boot
L'idée derrière le démarrage sécurisé est d'autoriser uniquement le code du système d'exploitation à s'exécuter sur votre machine provenant d'une partie de confiance. Notez que le démarrage sécurisé ne s'étend pas à l'espace utilisateur, c'est-à-dire aux programmes d'application. Nous pensons que les systèmes d'exploitation peuvent confiner ces éléments, afin qu'ils ne puissent pas faire de mauvaises choses. « Les mauvaises choses » dans ce contexte sont généralement des renifleurs de clavier, des exfiltrateurs de données et d'autres logiciels malveillants. Ainsi, même avec le démarrage sécurisé activé, nous pouvons exécuter des programmes arbitraires dans GNU/Linux, mais nous sommes sûrs que le système d'exploitation n'est pas compromis. Si vous souhaitez confiner davantage les applications, alors vous aurez besoin de techniques supplémentaires comme le sand-boxing ou SELinux mais cela va au-delà de cet article de blog.

La transitivité des chaînes de signatures est fondamentale pour la définition de la confiance. Parce que nous ne pouvons pas évaluer nous-mêmes chaque morceau de code pour sa fiabilité, nous déléguons cette évaluation à d'autres parties. Cette confiance s'étendra ensuite de manière transitive aux morceaux de code approuvés par ces parties. Chaque logiciel est livré avec son propre certificat et ces relations de confiance sont exprimées par des signatures sur ces certificats. Donc pour comprendre le flux de démarrage sécurisé, nous devrons comprendre non seulement le logiciel mais aussi l'ensemble des certificats et signatures à un moment donné. Bien que le démarrage sécurisé soit fonctionnel, cet ensemble est vraiment l'état du processus, donc il peut et va changer au fil du temps et nécessite sa propre attention. L'origine de ce processus transitif est appelée la racine de la confiance et joue bien sûr un rôle particulier. La chaîne de confiance peut potentiellement être compromise à n'importe quel endroit, mais si la racine de la confiance est compromise, tout le flux de démarrage sécurisé s'arrête.

Flux de démarrage
La racine de confiance pour un PC x86 standard est l'interface UEFI (Unified Extensible Firmware Interface) qui s'affiche sur la carte mère dans une puce flash. L'image UEFI et les clés dans ses tables sont considérées comme fiables. UEFI implémente une chaîne de démarrage sécurisée où chaque membre de la chaîne doit être digne de confiance avant d'être exécuté. Avant de passer le contrôle au composant suivant, l'intégrité de ce composant suivant doit être assurée, avant de lui passer le transfert.

Notez qu'il y a aussi le mode d'exécution de démarrage mesuré. Dans ce mode, les maillons de la chaîne seront « mesurés » par rapport à des valeurs connues et l'exécution s'arrêtera si les mesures dérivent de ces valeurs. En pratique, cela est mis en œuvre par un TPM et un ensemble de registres de configuration, mais ce n'est pas le sujet de cet article.

So let's look at the boot flow and the key tables involved :

Afin de comprendre ce flux, nous devons considérer les tables clés impliquées et examiner leur contenu sur cette machine. Le binaire mokutil (du paquetage mokutil) nous permet de regarder ces données. Nous allons regarder de plus près ce qu'est un MOK (Machine Owner Key) plus loin dans ce document.

Clefs	Vérifie	Mise à jour vérifiée par	Note
PK	Nouveau PK, Nouvelle KEK, Nouvelle db/dbx	PK	clé de plateforme
KEK	Nouvelle db/dbx	PK	Clé d'Echange de Clés
db	UEFI Image	PK/KEK	Base de données d'images autorisée
dbx	UEFI Image	PK/KEK	Base de données d'images interdite

# PK

Les Platform Keys (PK) représentent le fabricant de la plateforme :
mokutil --pk | grep '$^[ \t]*\[\|CN$'

[clé 1] Issuer: CN=ASUSTeK MotherBoard PK Certificate Subject: CN=ASUSTeK MotherBoard PK Certificate

# KEK

Seuls les propriétaires de clés d'échange de clés (KEK : Key EQxchange Keys) sont autorisés à modifier la base de données des clés :
mokutil --kek | grep '$^[ \t]*\[\|CN$'

[clé 1] Issuer: CN=ASUSTeK MotherBoard KEK Certificate Subject: CN=ASUSTeK MotherBoard KEK Certificate [clé 2] Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation KEK CA 2011 [clé 3] Issuer: C=US, O=Microsoft Corporation, CN=Microsoft RSA Devices Root CA 2021 Subject: C=US, O=Microsoft Corporation, CN=Microsoft Corporation KEK 2K CA 2023

Encore une fois, nous voyons une clé par le fabricant de la carte mère, une clé Microsoft et une clé canonique. Je suis assez sûr que les deux premières clés étaient déjà là lors de l'achat de la machine, mais je ne suis pas trop sûr d'où vient la clé canonique. Il a peut-être été ajouté à la base de données en démarrant Ubuntu il y a longtemps. Ces trois parties sont donc en mesure de changer les clés pour un démarrage sécurisé sans que vous ne le remarquiez.

# DB

La base de données (DB) des clés (et des hachages) contient des clés pour valider les étapes ultérieures du processus de démarrage :

mokutil --db | grep '$^[ \t]*\[\|CN$'

[key 1] Issuer: CN=ASUSTeK MotherBoard SW Key Certificate Subject: CN=ASUSTeK MotherBoard SW Key Certificate [key 2] Issuer: CN=ASUSTeK Notebook SW Key Certificate Subject: CN=ASUSTeK Notebook SW Key Certificate [key 3] Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011 [key 4] Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Root Certificate Authority 2010 Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Windows Production PCA 2011 [key 5] Issuer: C=US, O=Microsoft Corporation, CN=Microsoft RSA Devices Root CA 2021 Subject: C=US, O=Microsoft Corporation, CN=Microsoft UEFI CA 2023 [key 6] Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Root Certificate Authority 2010 Subject: C=US, O=Microsoft Corporation, CN=Windows UEFI CA 2023 [key 7] [SHA-256]

Le certificat racine du marché tiers de Microsoft Corporation est particulièrement remarquable. Il est inclus dans pratiquement toutes les versions commerciales de l'UEFI et l'écosystème GNU/Linux a décidé d'utiliser une signature avec cette clé pour initialiser sa propre gestion des clés. Comme il est peu pratique pour Microsoft de signer chaque mise à jour du chargeur d'amorçage (par exemple GRUB), il a été décidé d'introduire un logiciel très petit, facilement audité, dans le flux de démarrage régulier. Ce logiciel est la cale décrite dans l'organigramme ci-dessus.

# DBX

La liste de révocation (DBX) des clés (et des hachages) contient des entrées qui sont explicitement révoquées en raison de problèmes de sécurité. Habituellement, cette liste se compose de hachages pour exclure des versions problématiques uniques des programmes plutôt que des clés de signature entières qui ont été révoquées.

Ainsi, lorsqu'un problème de sécurité est connu, la sécurisation des machines se fait en poussant le hachage du logiciel affecté dans les tables DBX. Bien sûr, cela ne devrait se produire qu'après l'installation d'une nouvelle version (sécurisée) du logiciel. Sinon, la chaîne de démarrage se brisera et le système ne pourra plus démarrer. Cela semble être un problème théorique, mais le logiciel malveillant BlackLotus a montré qu'il s'agit également d'un problème pratique. Microsoft a reconnu en 2023 qu'un correctif approprié pour ce malware prend au moins un an parce qu'ils ont peur de rendre les systèmes non amorçables s'ils n'ont pas reçu de mises à jour logicielles avant de pousser les hachages pour révoquer le logiciel problématique.

Voici quelques entrées pour montrer à quoi elles ressemblent :
mokutil --dbx | head -5

[key 1] [SHA-256] 80b4d96931bf0d02fd91a61e19d14f1da452e66db2408ca8604d411f92659f0a f52f83a3fa9cfbd6920f722824dbe4034534d25b8507246b3b957dac6e1bce7a c5d9d8a186e2c82d09afaa2a6f7f2e73870d3e64f72c4e08ef67796a840f0fbd

# État du démarrage sécurisé

Pour vérifier, activer ou désactiver le démarrage sécurisé, encore une fois mokutil peut être utilisé. Ici, nous voyons qu'il est activé sur ma machine :

mokutil --sb-state
réponses :

SecureBoot activé
SecureBoot disabled
Platform is in Setup Mode
SecureBoot disabled

# Flux de contrôle

Chargement d'une image UEFI (dans notre cas, Shim), suit cette procédure :

MOK

Avec les clés et les certificats que nous avons examinés jusqu'à présent, notre système ne ferait pas confiance à un noyau que nous avons compilé nous-mêmes. Même les modules du noyau que nous compilons localement ne seront pas chargés tant que le noyau Linux est configuré en mode verrouillé et ce sera le cas par défaut lorsque le démarrage sécurisé est activé dans UEFI. Ainsi, les modules du noyau compilés par dkms ne seront pas chargés sur la machine. En pratique, cela signifie généralement que les pilotes propriétaires Nvidia distribués sous forme de "source", compilés par dmks, ne se chargeront pas sans étapes supplémentaires.

Créer un MOK unique (Machine Owner Key), l'inscrire dans la base de données et signer les modules du noyau avec cela résout ce problème. Un MOK peut avoir une phrase de passe pour protéger son utilisation. Spécifier une phrase de passage vide et s'appuyer sur les autorisations de fichier pour autoriser uniquement root signifie que tout malware fonctionnant avec des droits root pourra signer un malware et l'exécuter sur votre machine. Je vais donc utiliser une phrase de passe, mais cela signifie qu'il ne sera pas possible pour les mises à jour automatiques d'installer et de signer avec succès les modules du noyau. Au lieu de cela, une étape manuelle est requise lorsque je dois fournir la phrase secrète manuellement.

# Créer et inscrire un MOK

La création d'une clé de signature est assez standard avec l'ensemble des outils OpenSSL, donc je ne vais pas le décrire en détail. Voici une transcription pour montrer comment cela fonctionne pour créer la clé ci-dessous /var/lib/shim-signed/mok et /var/lib/dkms. L'emplacement n'est pas vraiment important, mais il semble que de nombreux exemples utilisent ces endroits, donc je vais simplement m'y tenir.
Je vais mettre la clef dans /var/lib/dkms en premier lieu, puis copier dans l'autre répertoire.

Pour commencer, installer dkms : apt-get install dkms
Ensuite on créé la clé :

~# openssl req -new -x509 \ -newkey rsa:2048 -keyout /var/lib/dkms/mok.key \ -outform DER -out /var/lib/dkms/mok.der \ -nodes -days 36500 -subj "/CN=Secure boot Signing MOK"

On converti en .pem
openssl x509 -inform der -in MOK.der -out MOK.pem

On s'assure que seul root y a accès :
chmod u+rw,go-rw,ugo-x /var/lib/dkms/mok*

Après quoi, on copie les clés dans l'autre répertoire :

mkdir -p /var/lib/shim-signed/mok ~# cp -p /var/lib/dkms/mok.key /var/lib/shim-signed/mok/MOK.priv ~# cp -p /var/lib/dkms/mok.der /var/lib/shim-signed/mok/MOK.der ~# cp -p /var/lib/dkms/mok.pem /var/lib/shim-signed/mok/MOK.pem

Et on enrôle la clé :
mokutil --import /var/lib/dkms/mok.der
Un mot de passe d'enrôlement va être demandé. Un redémarrage est nécessaire pour enrôler la clé avec le mot de passe d'enrôlement.

L'inscription réelle a lieu lors du prochain redémarrage, lorsque l'UEFI démarrera l'application UEFI MOKManager. Cela vous demandera le mot de passe que vous avez défini dans l'appel mokutil —import. L'idée derrière cela est que seule une personne réelle peut inscrire une clé. Même si certains malwares appellent mokutil —import, la clé n'est pas encore enrôlée mais seulement préparée pour être inscrite par le MOKManager. Espérons que l'utilisateur remarquera lors du prochain redémarrage qu'il y a quelque chose de louche si la machine démarre dans MOKManager et peut alors simplement refuser la nouvelle inscription.

Pour vérifier après le redémarrage :
Pour connaitre la nouvelle clé :
mokutil --list-new
Pour lister toutes les clés :
mokutil --list-enrolled ou mokutil --list-enrolled | grep '$^\[key\|CN$'

Si on se trompe dans le mot de passe, il faudra recommencer l'enrôlement.

# Signer les modules
La documentation du noyau nous montre comment utiliser le fichier de signature de script fourni par le noyau (compilé à partir de scripts/sign-file.c dans n'importe quel arbre source Linux) pour signer des modules. Probablement pour des raisons historiques, Ubuntu distribue ce binaire renommé en kmodsign et donc la documentation d'Ubuntu donne ce modèle de base pour signer un kernel-module (sous Debian cet executable n'existe pas) :

KBUILD_SIGN_PIN="xxxx" kmodsign sha512 MOK.priv MOK.der module.ko

En pratique, nous avons généralement quelques modules à signer, il est donc logique de regrouper les appels dans une simple boucle shell :

~# cd /var/lib/shim-signed/mok/ ~# for f in /lib/modules/5.4.0-126-generic/updates/dkms/*. ko ; do KBUILD_SIGN_PIN="xxxx" kmodsign sha512 MOK.priv MOK.der $f ; done

Bien sûr, nous pouvons pousser cette approche un peu plus loin et l'emballer dans un script qui fera tout cela et même plus :

-* {{!/bin/bash}} -* {{}} -* {{ sign-kernel-modules: Sign previously unsigned kernel modules for}} -* {{ secure boot. Only the dkms modules need to be handled as the}} -* {{ upstream modules are signed correctly.}} -* {{}} set -e shopt -s nullglob usage() { echo "usage: $(basename "$0") [-h] [-r ]" >&2 echo " Signs all previously unsigned kernel modules below" >&2 echo " /lib/modules//updates/dkms" >&2 echo " If no revision is specified with -r, then all installed versions" >&2 echo " will be processed." 2>&2 exit 1 } HELP=no KVER='*' while getopts hr: OPTION do case $OPTION in r) KVER=$OPTARG ;; h) HELP=yes ;; *) echo "Unknown option: $OPTION" ;; esac done shift $(( OPTIND - 1 )) if [ "yes" = "$HELP" ]; then usage fi MOKDIR=/var/lib/shim-signed/mok/ KMODSIGN=/usr/bin/kmodsign if [ ! -x $KMODSIGN ]; then KMODSIGN=/usr/src/linux-headers-$(uname -r)/scripts/sign-file if [ ! -x "$KMODSIGN" ]; then echo "No usable 'kmodsign' binary found - aborting" >&2 echo "You should try installing a kernel headers package," >&2 echo "like 'linux-headers-amd64'" >&2 exit 1 fi echo "Seems to be a Debian system, i.e. using KMODSIGN=$KMODSIGN" fi MODINFO=/sbin/modinfo get_x509_subject() { # In older versions, there are spaces around the equal sign ... openssl x509 -in $1 -subject -noout | sed 's/subject=CN \?= \?//' } get_ko_signer() { $MODINFO $1 | grep signer: | sed 's/^signer:[ ]\+//' } SUBJECT=$(get_x509_subject $MOKDIR/MOK.der) cd /lib/modules || exit for rev in $KVER do if [ ! -d "$rev" ]; then echo "Revision $rev not found. Exiting." >&2 exit 1 fi echo Processing "$rev" for module in "${rev}"/updates/dkms/*.ko "${rev}"/updates/dkms/*.ko.xz do # Check if module is signed by correct key already SIGNER=$(get_ko_signer $module) if [ "$SIGNER" = "$SUBJECT" ]; then echo "$module" already signed with correct certificate continue fi if [ -n "$SIGNER" ]; then echo Module signed by $SIGNER - will be overwritten fi if [ -z "$KBUILD_SIGN_PIN" ] then read -rs -p "Enter MOK passphrase: " KBUILD_SIGN_PIN export KBUILD_SIGN_PIN echo fi if [[ "$module" =~ .xz$ ]] then sudo unxz "$module" sudo --preserve-env=KBUILD_SIGN_PIN \ $KMODSIGN sha512 $MOKDIR/MOK.priv $MOKDIR/MOK.der "${module%%.xz}" sudo xz "${module%%.xz}" else sudo --preserve-env=KBUILD_SIGN_PIN \ $KMODSIGN sha512 $MOKDIR/MOK.priv $MOKDIR/MOK.der "$module" fi echo Successfully signed module "$module" done done

Ce script peut être exécuté à tout moment et s'assurera que les modules du noyau nouvellement compilés sont signés par la clé située à /var/lib/shim-signed/mok/MOK.der.

# Signatures du noyau

Maintenant que nous savons comment signer les modules du noyau, nous devons également comprendre comment le noyau lui-même est signé pour être chargé dans GRUB. Si ce n'est pas déjà installé, nous aurons besoin du package sbsigntool pour que cela fonctionne :

~# apt-get install sbsigntool
L'outil sbverify nous donne un outil facile pour montrer les signatures sur les applications EFI. Comme le shim, GRUB et le noyau sont de ce format, nous pouvons l'utiliser pour montrer les signatures :

~# sbverify --list /boot/efi/EFI/debian/shimx64.efi warning: data remaining[833960 vs 960080]: gaps between PE/COFF sections? signature 1 image signature issuers: - /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011 image signature certificates: - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows UEFI Driver Publisher issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011 issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root ~# sbverify --list /boot/efi/EFI/debian/grubx64.efi signature 1 image signature issuers: - /CN=Debian Secure Boot CA image signature certificates: - subject: /CN=Debian Secure Boot Signer 2022 - grub2 issuer: /CN=Debian Secure Boot CA ~# sbverify --list /boot/vmlinuz-6.12.33+deb12-amd64 signature 1 image signature issuers: - /CN=Debian Secure Boot CA image signature certificates: - subject: /CN=Debian Secure Boot Signer 2022 - linux issuer: /CN=Debian Secure Boot CA signature 2 image signature issuers: - /CN=Secure boot Signing MOK image signature certificates: - subject: /CN=Secure boot Signing MOK issuer: /CN=Secure boot Signing MOK

On voit bien la signature 2 avec ma clé.
Pour signer le noyau en utilisant dkms (ainsi en cas de mise à jour du moyau ce sera automatiquement pris en compte) :

~# vim /etc/dkms/framework.conf mok_signing_key=/var/lib/dkms/mok.key mok_certificate=/var/lib/dkms/mok.pub sign_tool="/etc/dkms/sign_helper.sh" ~# vim /etc/dkms/sign_helper.sh /lib/modules/"$1"/build/scripts/sign-file sha512 /var/lib/shim-signed/MOK.priv /var/lib/shim-signed/MOK.der "$2"

On créé le script de définitoin des variables d'enrironnement :

~# vim ./set_signing_kernel_env.sh -* {{!/bin/bash}} export VERSION="$(uname -r)" export SHORT_VERSION="$(uname -r | cut -d . -f 1-2)" export MODULES_DIR=/lib/modules/$VERSION export KBUILD_DIR=/usr/lib/linux-kbuild-$SHORT_VERSION

On donne les droit d'execution :
~# chmod 700 set_signing_kernel_env.sh

Et on signe le noyau :

~# . ./set_signing_kernel_env.sh ~# sbsign --key /var/lib/dkms/mok.key --cert /var/lib/dkms/mok.pem "/boot/vmlinuz-$VERSION" --output "/boot/vmlinuz-$VERSION.tmp" ~# mv "/boot/vmlinuz-$VERSION.tmp" "/boot/vmlinuz-$VERSION"

La difficulté ici sera de protéger les clefs dans les deux répertoire, car restreindre à root uniquement n'est aps suffisant dans le cas d'un malware s'executant avec les droits root par exemple.

Au redémarrage, vous activez Secure Boot dans le Bios et cela doit démarrer correctement :)

disparition des partitions

bruno — 2024-04-25T02:36:35Z

utilisation de testdisk

– installation : apt-get install testdisk

– utilisation :
sudo testdisk /log /dev/sdf

Sélectionner le disque :

Select a media (use Arrow keys, then press Enter): >Disk /dev/sdf - 250 GB / 232 GiB - WDC WD25 00JB-00REA0

On utilise gauche/droite haut/bas et

Sélectionner le type de partition :

Please select the partition table type, press Enter when done. >[Intel ] Intel/PC partition [EFI GPT] EFI GPT partition map (Mac i386, some x86_64...) [Humax ] Humax partition table [Mac ] Apple partition map (legacy) [None ] Non partitioned media [Sun ] Sun Solaris partition [XBox ] XBox partition [Return ] Return to disk selection Hint: Intel partition table type has been detected.

Choisir Analyse

>[ Analyse ] Analyse current partition structure and search for lost partitions [ Advanced ] Filesystem Utils [ Geometry ] Change disk geometry [ Options ] Modify options [ MBR Code ] Write TestDisk MBR code to first sector [ Delete ] Delete all data in the partition table [ Quit ] Return to disk selection

Puis quick search et A pour ajouter ula partition trouvée

carte vidéo qui plante

bruno — 2023-12-20T02:05:55Z

radeon : ring stalled for more than

une carte vidéo plante avec ce message : radeon : ring stalled for more than 1113ms

solution trouvées non essayées ( https://forums.linuxmint.com/viewtopic.php?t=361652 )

This might be a power-state issue. Let's see if the radeon.dpm=0 kernel parameter works. Here is How to add a kernel parameter temporarily or permanently.
enlever l'hardware acceleration du programme
You could try adding another one radeon.hard_reset=1 in addition to the radeon.dpm=0 to see if that helps.

cat /proc/cmdline
grep " ring" /var/log/syslog

températures de l'ordinateur

bruno — 2023-09-11T09:25:40Z

nouvelle méthode

activation non automatique : modprobe drivetemp
activation automatique ( prochain démarrage ) : echo drivetemp > /etc/modules-load.d/drivetemp.conf

Utilisation par script :
par exemple , pour afficher nom du disque puis temperature :
grep -l "drivetemp" /sys/class/hwmon/hwmon*/name | while read f;do Nom="$(cat ${f%/*}/device/model)"; Temp="$(($(cat ${f%/*}/temp1_input)/1000))" ; echo "${Nom} : ${Temp} °C" ;done

on les a aussi ici :
cat /sys/block/sd*/device/hwmon/hwmon*/temp1_input|sed 's#$[0-9][0-9][0-9]$$#,\1 °C#'

car/sys/block/sda -> /sys/devices/pci0000:00/0000:00:17.0/ata3/host2/target2:0:0/2:0:0:0/block/sda
et /sys/class/hwmon/hwmon4 -> /sys/devices/pci0000:00/0000:00:17.0/ata3/host2/target2:0:0/2:0:0:0/hwmon/hwmon4

A noter qu'en plus de temp1_input ; on peut trouver aussi
temp1_crit ; temp1_highest ; temp1_lcrit ; temp1_lowest ; temp1_max ; temp1_min

htop

sudo apt-get install htop
Il faut faire afficher par F2 la température.

apt-get install psensor psensor-common lm-sensors

hddtemp

apt-get install hddtemp
hddtemp est obsolète à partir de bookworm ( deb12)
hddtemp $(blkid |grep /dev/sd|sed "s#$sd[a-z]$.*#\1#"|sort -u)

/dev/sda: Hitachi HTSCBA987654321: 45°C

sensors

apt-get install lm-sensors

acpitz-acpi-0 Adapter: ACPI interface temp1: +73.0°C (crit = +98.0°C) coretemp-isa-0000 Adapter: ISA adapter Core 0: +72.0°C (crit = +100.0°C) Core 1: +74.0°C (crit = +100.0°C) BAT1-acpi-0 Adapter: ACPI interface in0: 7.79 V curr1: 1.46 A

psensor

peut aider :

sensors-detect
/etc/init.d/kmod start
watch sensors

impossible de monter

bruno — 2020-09-16T14:47:07Z

Impossible de monter une clé usb
Ouvrir une clé usb
Not authorized to perform operation
...

solution compliquée - à faire une fois pour toutes pour monter une carte photo sur un ordi en ssh

le fichier - de type xml - /usr/share/polkit-1/actions/org.freedesktop.udisks2.policy ( ou /usr/share/polkit-1/actions/org.freedesktop.UDisks2.policy ) contient des blocs ( des actions ).

Cette action :

doit finir par
yes

docs : https://wiki.archlinux.org/index.php/Polkit#Allow_mounting_a_filesystem_on_a_system_device_for_any_user

mises à jour avec problème

bruno — 2020-09-11T10:51:49Z

avec cette erreur ( non résolu ) :

apt-get -f install Paramétrage de sane-utils (1.0.25-4.1+deb9u1) ... [....] Restarting SANE network scanner server: saned[....] Stopping SANE network scanner server: sanedstart-stop-daemon: invalid schedule item (must be [-], -,  or 'forever' Try 'start-stop-daemon --help' for more information. invoke-rc.d: initscript saned, action "restart" failed. dpkg: erreur de traitement du paquet sane-utils (--configure) : le sous-processus script post-installation installé a retourné une erreur de sortie d'état 3 Des erreurs ont été rencontrées pendant l'exécution : sane-utils E: Sub-process /usr/bin/dpkg returned an error code (1)

dpkg --purge --force-all sane-utils apt-get --purge remove sane-utils apt-get -s upgrade apt-cache policy sane-utils apt-get -s autoremove --purge dpkg --configure -a dpkg -r sane-utils dpkg -P sane-utils dpkg -r sane-utils --ignore-depends

Boucles de conflits ou de prédépendances

Il est parfois nécessaire d'activer l'option d'APT APT::Force-LoopBreak pour pouvoir temporairement retirer un paquet essentiel à cause de boucles « Conflicts/Pre-Depends ». apt vous alertera à ce propos et interrompra la mise à niveau. Vous pouvez contourner ce problème en passant l'option -o APT::Force-LoopBreak=1 sur la ligne de commande d'apt.

Il est possible que la structure de dépendances d'un système soit tellement défectueuse qu'elle requière une intervention manuelle. Habituellement, cela signifie qu'il faut utiliser apt ou :

apt -f install dpkg --configure --pending

Dans certains cas extrêmes, vous pourriez devoir forcer une réinstallation à l'aide d'une commande comme :
dpkg --install /chemin/vers/nom_du_paquet.deb

Enregistrer la session

Enregistrer la session
script -t 2>~/upgrade-bookwormétape.time -a ~/upgrade-bookwormétape.script

rejouer la session entière :
scriptreplay ~/upgrade-bookwormétape.time ~/upgrade-bookwormétape.script

https://www.debian.org/releases/bookworm/amd64/release-notes/ch-upgrading.fr.html#minimal-upgrade

mise à jour impossible

bruno — 2019-08-26T16:47:17Z

En cas de problème de mise à jour : essayer de passer en ligne de commande , passer en root ( su root , sinon sudo -s ) puis taper
apt-get update && apt-get -f install
Lire alors le message, qui donne souvent la solution.

Solutions classiques à essayer :

apt-get -f install
dpkg-reconfigure -a

Messages d'erreur :

E : Le paquet « machin » n'a pas de version susceptible d'être installée : essayer d'abord un apt-get update
E : Le dépôt « http://deb.debian.org/debian buster-updates InRelease » a modifié E: Le dépôt « http://deb.debian.org/debian buster-updates InRelease » a modifié sa valeur « Suite » de « testing-updates » à « stable-updates » N: Ceci doit être pleinement accepté avant que les mises à jour depuis ce dépôt puissent être appliquées. Veuillez vous référer aux pages de manuel « apt-secure(8) » pour plus de détails.
: essayer un apt-get --allow-releaseinfo-change update

un message avec le mot dépendances : apt-get -f install ou apt-get update && apt-get -f install
un message avec mal configuré : dpkg-reconfigure -a
"tentative de remplacement de machin qui appartient aussi à truc" dpkg: erreur de traitement de l'archive /var/cache/apt/archives/php5-json_1.3.6-1_amd64.deb (--unpack) : tentative de remplacement de « /usr/include/php5/ext/json/php_json.h », qui appartient aussi au paquet php5-dev 5.5.22-1~dotdeb.1 Des erreurs ont été rencontrées pendant l'exécution : /var/cache/apt/archives/php5-json_1.3.6-1_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1)
dpkg -i --force-overwrite /var/cache/apt/archives/php5-json_1.3.6-1_amd64.deb && dpkg --configure -a && apt-get -f install

Certificate verification failed : The certificate is NOT trusted. The certificate chain uses not yet valid certificate. Could not handshake : Erreur de vérification du certificat. [IP : 2a04:4e42:6a::644 443]

Commencer par vérifier la date : elle doit être la bonne.
On peut la changer de cette façon :
date --set 2024-03-26 date --set 18:54:32

systemd

bruno — 2019-04-26T21:42:14Z

journalctl |grep blue

systemctl status dbus

sudo systemctl status dbus ● dbus.service - D-Bus System Message Bus Loaded: loaded (/lib/systemd/system/dbus.service; static; vendor preset: enabled) Active: active (running) since Fri 2019-04-26 21:19:42 UTC; 17min ago Docs: man:dbus-daemon(1) Main PID: 488 (dbus-daemon) Tasks: 1 (limit: 4180) Memory: 4.5M CGroup: /system.slice/dbus.service └─488 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only avril 26 21:19:52 ordi dbus-daemon[488]: [system] Successfully activated service 'org.blueman.Mechanism' avril 26 21:19:52 ordi blueman-mechanism[964]: /usr/lib/blueman/blueman-mechanism:94: PyGIDeprecationWarning: GObject.timeout GObject.timeout_add(1000, self.tick) avril 26 21:19:52 ordi blueman-mechani[964]: gtk_icon_theme_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed avril 26 21:19:52 ordi blueman-mechanism[964]: loading Network avril 26 21:19:52 ordi blueman-mechanism[964]: loading RfKill avril 26 21:19:52 ordi blueman-mechanism[964]: loading Rfcomm avril 26 21:19:52 ordi blueman-mechanism[964]: loading Ppp avril 26 21:19:56 ordi dbus-daemon[488]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit=' avril 26 21:19:56 ordi dbus-daemon[488]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' avril 26 21:20:22 ordi blueman-mechanism[964]: Exiting

systemd-analyze

Startup finished in 9.632s (kernel) + 17.825s (userspace) = 27.457s graphical.target reached after 17.774s in userspace

sudo journalctl -xeu fail2ban.service
sudo systemctl reload fail2ban
sudo systemctl enable fail2ban
sudo systemctl disable fail2ban

exemple d'unit d'après zargos

/etc/systemd/system/myscript.service

[Unit] Description=Reboot message systemd service. [Service] Type=simple ExecStart=/usr/local/sbin/script.sh [Install] WantedBy=multi-user.target

chmod 644 /etc/systemd/system/myscript.service
systemctl enable myscript.service

PCIe Bus Error : severity=Corrected, type=Physical Layer, device [80oo:all6] error status/rrask=0ûû00û0l/00002û0û [ 0] Receiver Error (First)

bruno — 2018-04-17T22:09:29Z

erreur de type

PCIe Bus Error: severity=Corrected, type=Physical Layer, device [80oo:all6] error status/rrask=0ûû00û0l/00002û0û [ 0] Receiver Error (First) PCIe Bus Error: severity=Corrected, type=Physical Layer, device [B086:all6] error status/mask=00000ûûl/000020ûû t 0] Receiver Error (First) PCIe Bus Error: severity=Corrected, type=Physical Layer, device [8086:all6] error status/mask=ûOOOQûOl/00002000 [ 0] Receiver Errer (First) PCIe Bus Error: severity=Corrected, type=Physical Layer, device [8û86:all6] error status/mask=0û00ûûûl/000020û0 [ 0] Receiver Error (First)

d'après https://askubuntu.com/questions/771899/pcie-bus-error-severity-corrected , et https://h30434.www3.hp.com/t5/Notebook-Software-and-How-To-Questions/Error-Spam-AER-id-00e5-PCIe-Bus-Error-severity-Corrected/td-p/5933687

ajouter dans grub GRUB_CMDLINE_LINUX_DEFAULT="quiet splash pci=nomsi"
ou
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash pci=noaer"

installer sans vérification

bruno — 2018-04-16T18:08:53Z

Lors de l'installation d'un programme, il est vérifié avant d'être installé. Mais parfois on ne peut pas et on a ce genre de message : Install these packages without verification? [y/N]

Solution :
vérifier l'installation des programmes keyrings :

apt-get install gnome-keyring debian-keyring debian-ports-archive-keyring debian-archive-keyring && apt-get update && apt-get install gnupg && apt-key update && apt-get update