# Plus de démarrage, UEFI cassé

**URL:** <https://www.debian-fr.org/t/plus-de-demarrage-uefi-casse/86129>\
**Category:** Support Debian\
**Tags:** boot, grub\
**Created:** [Février 12, 2022, 12:23 UTC](https://www.debian-fr.org/t/plus-de-demarrage-uefi-casse/86129 "2022-02-12T00:23:33Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![littlejohn75](https://www.debian-fr.org/user_avatar/www.debian-fr.org/littlejohn75/32/3840_2.png) [@littlejohn75](https://www.debian-fr.org/u/littlejohn75)\
**Post date:** [Février 12, 2022, 12:23 UTC](https://www.debian-fr.org/t/plus-de-demarrage-uefi-casse/86129/1 "2022-02-12T00:23:33Z")

</div>

La machine ASUS ( 7 ans d’âge ) de mon fils, avec une Debian 11 version XFCE depuis environ un an (windows irrécupérable) ne démarre plus : on arrive directement sur la configuration du BIOS.  
Mon fils m’explique que comme Firefox ramait trop, il a fermé Firefox et activé le bouton «&nbsp;éteindre&nbsp;».  
Vu la catastrophe au redémarrage, je me suis empressé de télécharger l’ISO netinst de de la copier sur une clé USB.

```auto
⏚ fp2@debpacha:/tmp 6s $ sudo dd if=debian-11.2.0-amd64-netinst.iso of=/dev/sdc bs=1M
378+0 enregistrements lus
378+0 enregistrements écrits
396361728 octets (396 MB, 378 MiB) copiés, 154,278 s, 2,6 MB/s
⏚ fp2@debpacha:/tmp 2m34s $ sudo fdisk -l /dev/sdc

```

La machine ASUS démarre bien sur cette clé, je lance donc le mode de récupération Nous retrouvons les paramètres réseau sans problème avec la connexion filaire Ethernet. Je surveille les messages affichés dans la console _tty4_. Je constate qu’il y des erreurs d’entrée/sortie à la détection des disques.  
J’ai aussi ouvert un shell sur _tty2_. Je vois que le système retrouve le groupe de volumes nommé ouaoua\_vg et les volumes logiques root\_lv, home\_lv et swap.  
Pas de problème donc pour retrouver la partition racine. En lançant un shell, je peux monter /home et même activer le swap

```auto
swapon /dev/ouaoua_vg/swap

```

Par contre pour l’écran qui demande si on veut bien monter _/boot/efi_ c’est le drame Les erreurs sur _tty4_ réapparaissent et se terminent par une impossibilité de lire le super bloc La partition _/dev/sda1_ est inaccessible et ne se monte pas.  
mount /boot/efi ==\> UUID non trouvé (un UUID très court d’ailleurs )  
mount -t vfat /dev/sda1 /boot/efi ==\> échec et mêmes erreurs sur _tty4_

Naturellement, impossible de réinstaller _grub_ dans ces conditions. Que ce soit directement sur _/dev/sda_ ou en forçant cette histoire rocambolesque de chemin de périphérique amovible. Franchement, baser une opération aussi critique que l’amorçage et l’interface avec le BIOS sur un système de fichiers conçu au XX ième siècle c’est invraisemblable  
Pas de copie de secours du super bloc, UUID ridicule, introduit au chausse pied, ce n’est pas sérieux On reconnaît bien là la patte de Microsoft pour des solutions bâtardes. Tout cela pour 100 Mo !

Est-il possible de trouver et restaurer cette partition «&nbsp;EFI System&nbsp;» ?

Cordialement,  
Regards,  
Mit freundlichen Grüßen,  
مع تحياتي الخالصة

* * *

F. Petitjean  
Ingénieur civil du Génie Maritime.

« Celui qui, parti de rien, n’est arrivé nulle part n’a de merci à dire à personne !! »  
Pierre Dac

---

<div class="post-metadata">

**Author:** ![zao](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/z/ce7236/32.png) [@zao](https://www.debian-fr.org/u/zao)\
**Post date:** [Février 12, 2022, 7:32 UTC](https://www.debian-fr.org/t/plus-de-demarrage-uefi-casse/86129/2 "2022-02-12T07:32:04Z")

</div>

j’espère que mes interrogations qui visent juste à une amélioration personnelle , ne seront pas aussi ridicules qu’une UUID type Windows . Mais :

> [@littlejohn75](#):
>
> mount /boot/efi ==\> UUID non trouvé (un UUID très court d’ailleurs )  
> …  
> Que ce soit directement sur _/dev/sda_ ou en forçant cette histoire rocambolesque de chemin de périphérique amovible.

- UUID Debian de ma partition boot/efi ⁼ 2972-05E7 ce qui est ridiculement court par r apport aux autres UUID partitionnels  
\*\* la remarque au sujet du chemin amovible est-elle spécifique au cas ASUS/Windows ou bien a-t-elle une portée plus générale comme par exemple le chemin amovible que j’ai dû spécifier à l’installateur debian pour avoir un ssd externe autonome ?

en espérant n’avoir pas écrit trop d’âneries … sinon toute correction , verte ou non , est la bienvenue .

---

<div class="post-metadata">

**Author:** ![jipete](https://www.debian-fr.org/user_avatar/www.debian-fr.org/jipete/32/11729_2.png) [@jipete](https://www.debian-fr.org/u/jipete)\
**Post date:** [Février 12, 2022, 9:02 UTC](https://www.debian-fr.org/t/plus-de-demarrage-uefi-casse/86129/3 "2022-02-12T09:02:37Z")

</div>

Bonjour,

> [@littlejohn75](#):
>
> Par contre pour l’écran qui demande si on veut bien monter _/boot/efi_ c’est le drame Les erreurs sur _tty4_ réapparaissent et se terminent par une impossibilité de lire le super bloc La partition _/dev/sda1_ est inaccessible et ne se monte pas.  
> mount /boot/efi ==\> UUID non trouvé (un UUID très court d’ailleurs )  
> mount -t vfat /dev/sda1 /boot/efi ==\> échec et mêmes erreurs sur _tty4_

Mais je ne comprends pas : si Windows est irrécupérable, qu’est-ce que tu te prends la tête avec cette partoche dédiée à Windows ?  
Tu la dégages, tu crées un dossier /boot classique, tu dis à grub de faire ce qu’il faut dedans, tu lui demandes d’installer le MBR sur sda et ça devrait être tout bon, non ?

Par contre, j’aurais tendance à conserver cette partition comme zone morte à ne plus jamais utiliser, si par hasard des hard bad-blocks y traîneraient.

(Et les UUID très courts, j’en ai déjà vu [mais je ne me souviens plus où], donc ça existe, oui).

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Février 12, 2022, 9:19 UTC](https://www.debian-fr.org/t/plus-de-demarrage-uefi-casse/86129/4 "2022-02-12T09:19:14Z")

</div>

> [@littlejohn75](#):
>
> mount -t vfat /dev/sda1 /boot/efi ==\> échec et mêmes erreurs sur _tty4_

Il serait utile de rapporter ces erreurs. Secteur défectueux ?  
Puisqu’il est possible de lancer un shell dans la racine du système, il faudrait vérifier

- les données SMART du disque avec smartctl,
- la présence de secteurs défecfueux (sur la partition dans un premier temps, sur tout le disque ensuite) avec badblocks,
- l’identification du type de contenu de la partition avec wipefs, file -s…
- éventuellement vérifier le système de fichiers avec dosfsck.

Si la partition EFI contient des secteurs défectueux (mais pas le reste du disque), passer badblocks en mode écriture (-w) pour tenter de les faire réallouer par le contrôleur intégré du disque. Si cela échoue, reformater la partition avec mkdosfs et l’option -c pour marquer les secteurs défectueux. Ou bien recréer une partition Mettre à jour l’UUID dans /etc/fstab, monter la partition, réinstaller GRUB avec `dpkg-reconfigure grub-efi-amd64`

> [@littlejohn75](#):
>
> un UUID très court d’ailleurs

Ce n’est pas un vrai UUID (sur 128 bits). C’est l’identifiant de volume FAT (sur 32 bits) qui est utilisé comme UUID faute de mieux. Rien n’empêche d’utiliser un LABEL bien trapu à la place, avec 11 caractères on se rapproche des 128 bits d’un vrai UUID. Même chose avec les UUID de partition (PARTUUID) factices des tables de partition MSDOS basés sur l’identifiant de disque sur 32 bits du MBR.

> [@zao](#):
>
> la remarque au sujet du chemin amovible est-elle spécifique au cas ASUS/Windows ou bien a-t-elle une portée plus générale comme par exemple le chemin amovible que j’ai dû spécifier à l’installateur debian pour avoir un ssd externe autonome ?

L’installation du chargeur d’amorçage dans le «&nbsp;chemin de périphérique amovible&nbsp;» (qui n’est qu’un nom et ne signifie absolument pas que le disque est amovible) n’est pas spécifique à Asus mais nécessaire avec tout firmware UEFI buggé qui gère mal les variables de boot EFI.

> [@jipete](#):
>
> Mais je ne comprends pas : si Windows est irrécupérable, qu’est-ce que tu te prends la tête avec cette partoche dédiée à Windows ?

La partition EFI n’est pas dédiée à Windows, elle est utilisée par tous les OS pour l’amorçage en mode EFI.

> [@jipete](#):
>
> tu dis à grub de faire ce qu’il faut dedans, tu lui demandes d’installer le MBR sur sda

Pas d’installation dans le MBR pour l’amoçage EFI.

---

<div class="post-metadata">

**Author:** ![zao](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/z/ce7236/32.png) [@zao](https://www.debian-fr.org/u/zao)\
**Post date:** [Février 12, 2022, 10:11 UTC](https://www.debian-fr.org/t/plus-de-demarrage-uefi-casse/86129/5 "2022-02-12T10:11:41Z")

</div>

> [@PascalHambourg](#):
>
> L’installation du chargeur d’amorçage dans le « chemin de périphérique amovible » (qui n’est qu’un nom et ne signifie absolument pas que le disque est amovible) n’est pas spécifique à Asus mais nécessaire avec tout firmware UEFI buggé qui gère mal les variables de boot EFI.

je suis un âne : la remarque que tu fais était déjà donnée , hormis le "ne signifie pas que le disque est amovible ", par l’installateur debian et je l’avais déjà oubliée ( même pas 2 semaines !! ) .  
merci pour la réponse .

---

<div class="post-metadata">

**Author:** ![littlejohn75](https://www.debian-fr.org/user_avatar/www.debian-fr.org/littlejohn75/32/3840_2.png) [@littlejohn75](https://www.debian-fr.org/u/littlejohn75)\
**Post date:** [Février 13, 2022, 5:30 UTC](https://www.debian-fr.org/t/plus-de-demarrage-uefi-casse/86129/6 "2022-02-13T17:30:26Z")

</div>

> [@PascalHambourg](#):
>
> Il serait utile de rapporter ces erreurs. Secteur défectueux ?

Je ne vous le fais pas dire. J’ai recommencé en prenant le soin d’enregistrer la sortie de commandes passées dans un fichier, pour ensuite les copier sur mon portable et coller ici les bonnes feuilles de ce feuilleton

> [@PascalHambourg](#):
>
> les données SMART du disque avec smartctl,

Avant même d’avoir lu votre message, j’ai lancé smartctl avec l’option `--test=short` sur tout le disque d’1 T, au bout d’un peu plus de deux minutes, j’ai constaté que ce «&nbsp;selftest&nbsp;» s’était terminé sans erreur, et portait le numéro 7

> [@PascalHambourg](#):
>
> la présence de secteurs défecfueux (sur la partition dans un premier temps, sur tout le disque ensuite) avec badblocks,

J’ai lancé

```auto
badblocks -o /tmp/sda1_bblocks /dev/sda1

```

et j’ai été trahi par ma mauvaise vision en croyant que le fichier généré étatit vide. Voilà une sortie qui le confirme

```auto
ls -lst /tmp
     4 -rw-r--r-- 1 root root 8 Feb 12 16:03 sda1_bblocks
     4 drwx------ 3 root root 4096 Feb 12 15:59 cdebconf-terminal.oMH3Xq
     4 -rw------- 1 root root 569 Feb 11 07:33 tmp.fQdCzBXcLN
     4 -rw------- 1 root root 560 Feb 11 07:03 tmp.qlOgimoJqm
     4 -rw------- 1 root root 490 Feb 10 07:33 tmp.8qXpekK2Ut
     4 -rw------- 1 root root 560 Feb 10 07:03 tmp.5N8xk6D9ze
     4 -rw------- 1 root root 560 Feb 9 06:33 tmp.uOyGVFJLpS
     4 -rw------- 1 root root 560 Feb 8 06:03 tmp.bNfmOkVJxq
     4 drwx------ 3 1000 1000 4096 Feb 7 06:35 Temp-e72f7936-f948-43f8-9139-8261fd973225

```

en fait 8 octets donc.

Voici comment j’ai procédé pour obtenir les messages d’erreurs :  
sur \__tty1_ c’est un processus assez long pour arriver au montage de la racine  
sur _tty2_ j’ouvre une console, je lance des commandes du genre

```auto
date >> /tmp/ouaoua.txt
dmesg | tail >> /tmp/ouaouatxt

```

sur _tty4_ c’est la console de sortie

Voici la fin de cette première séquence

```auto
[806.480011] sd 0:0:0:0: [sda] tag#10 CDB: Read(10) 28 00 00 00 08 00 00 01 00 00
[806.480017] blk_update_request: I/O error, dev sda, sector 2048 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 0
[806.480060] ata1: EH complete
[845.369702] EXT4-fs (dm-0): recovery complete
[845.378444] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)

```

Après le montage du répertoire racine, je peux (sur tty1) ouvrir un shell dans le système à réparer, y lancer le montage de /home, activer le swap, etc .  
Mais je dois récupérer le résultat de la première séquence, donc (dans _tty2_)  
copier `cp /tmp/ouaoua.txt /target/tmp/`  
La suite se fait systématiquement dans _tty1_.

```auto
df -hTx tmpfs
Sys. de fichiers Type Taille Utilisé Dispo Uti% Monté sur
/dev/ouaoua_vg/root_lv ext4 28G 7,5G 19G 29% /
devtmpfs devtmpfs 1,9G 0 1,9G 0% /dev
/dev/mapper/ouaoua_vg-home_lv xfs 47G 4,8G 42G 11% /home

```

```auto
fdisk -l /dev/sda
Disque /dev/sda : 931,51 GiB, 1000204886016 octets, 1953525168 secteurs
Modèle de disque : TOSHIBA MQ01ABD1
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d'étiquette de disque : gpt
Identifiant de disque : 0DFB4264-91EE-4048-A0F1-2544B2D63495

Périphérique Début Fin Secteurs Taille Type
/dev/sda1 2048 206847 204800 100M Système EFI
/dev/sda2 206848 2050047 1843200 900M Environnement de récupérati
on Windows
/dev/sda3 2050048 2312191 262144 128M Réservé Microsoft
/dev/sda4 2312192 783718399 781406208 372,6G Données de base Microsoft
/dev/sda5 783718400 1922045951 1138327552 542,8G Données de base Microsoft
/dev/sda6 1922045952 1953523711 31477760 15G Environnement de récupérati
on Windows
/dev/sda1: ERROR: cannot read `/dev/sda1' (Input/output error)

```

```auto
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931,5G 0 disk
├─sda1 8:1 0 100M 0 part
├─sda2 8:2 0 900M 0 part
├─sda3 8:3 0 128M 0 part
├─sda4 8:4 0 372,6G 0 part
├─sda5 8:5 0 542,8G 0 part
│ ├─ouaoua_vg-root_lv 253:0 0 27,9G 0 lvm /
│ ├─ouaoua_vg-swap 253:1 0 5,6G 0 lvm [SWAP]
│ └─ouaoua_vg-home_lv 253:2 0 46,6G 0 lvm /home
└─sda6 8:6 0 15G 0 part
sdb 8:16 1 1,9G 0 disk
├─sdb1 8:17 1 378M 0 part
└─sdb2 8:18 1 2,5M 0 part
sr0 11:0 1 1024M 0 rom

```

> [@PascalHambourg](#):
>
> l’identification du type de contenu de la partition avec wipefs, file -s…

C’est là que ça coince 😪 Pour sda1 c’est Inpu-Output error et 16 lignes d’injures dans la sortie de dmesg (voir ci-dessous)

```auto
file -s /dev/sda2
/dev/sda2: DOS/MBR boot sector, code offset 0x52+2, OEM-ID "NTFS ", sectors/cluster 8, Media descriptor 0xf8, sectors/track 63, heads 255, hidden sectors 206848, dos < 4.0 BootSector (0x80), FAT (1Y bit by descriptor); NTFS, sectors/track 63, sectors 1843199, $MFT start cluster 76800, $MFTMirror start cluster 2, bytes/RecordSegment 2^(-1*246), clusters/index block 1, serial number 0f89ccf6b9ccf22cc; contains bootstrap BOOTMGR

```

```auto
file -s /dev/sda3
/dev/sda3: data

```

```auto
file -s /dev/sda4
/dev/sda4: DOS/MBR boot sector, code offset 0x52+2, OEM-ID "NTFS ", sectors/cluster 8, Media descriptor 0xf8, sectors/track 63, heads 255, hidden sectors 2312192, dos < 4.0 BootSector (0x80), FAT (1Y bit by descriptor); NTFS, sectors/track 63, sectors 781406207, $MFT start cluster 786432, $MFTMirror start cluster 2, bytes/RecordSegment 2^(-1*246), clusters/index block 1, serial number 09616d2c616d2a711; contains bootstrap BOOTMGR

```

```plaintext
file -s /dev/sda5
/dev/sda5: LVM2 PV (Linux Logical Volume Manager), UUID: Oq3p4f-MQfz-rUPm-4mbS-F45A-SAap-xiQvbO, size: 582823706624

```

Toutes ces informations étaient dans le fichier ouaoua.txt que j’ai copié avec scp sur ma machine. J’ai aussi copié la sortie de `dmesg`.  
En parcourant le contenu des 1997 lignes de dmesggtxt on voit une répétition de blocs de ligne avec «&nbsp;exception&nbsp;» sur la première ligne et «&nbsp;EH complete&nbsp;» sur la dernière.

```auto
[263.848077] ata1.00: exception Emask 0x0 SAct 0x178000 SErr 0x40000 action 0x0
[263.848082] ata1.00: irq_stat 0x40000008
[263.848086] ata1: SError: { CommWake }
[263.848091] ata1.00: failed command: READ FPDMA QUEUED
[263.848101] ata1.00: cmd 60/00:78:00:08:00/01:00:00:00:00/40 tag 15 ncq dma 131072 in
                        res 41/40:00:00:08:00/00:01:00:00:00/40 Emask 0x409 (media error) <F>
[263.848104] ata1.00: status: { DRDY ERR }
[263.848107] ata1.00: error: { UNC }
[263.851412] ata1.00: configured for UDMA/100
[263.851470] sd 0:0:0:0: [sda] tag#15 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=3s
[263.851476] sd 0:0:0:0: [sda] tag#15 Sense Key : Medium Error [current] 
[263.851481] sd 0:0:0:0: [sda] tag#15 Add. Sense: Unrecovered read error - auto reallocate failed
[263.851486] sd 0:0:0:0: [sda] tag#15 CDB: Read(10) 28 00 00 00 08 00 00 01 00 00
[263.851493] blk_update_request: I/O error, dev sda, sector 2048 op 0x0:(READ) flags 0x0 phys_seg 5 prio class 0
[263.851527] ata1: EH complete
[267.804128] ata1.00: exception Emask 0x0 SAct 0x800000 SErr 0x40000 action 0x0

```

Je lance

```auto
fgrep -A15 exception dmesg.txt > /tmp/err_execption

```

```auto
fp2@debpacha:~ $ wc /tmp/err_execption dmesg.txt 
  1941 19573 136117 /tmp/err_execption
  1997 20114 140478 dmesg.txt
  3938 39687 276595 total
fp2@debpacha:~ $

```

On a donc 121 fois les 16 lignes

En utilisant une méthode différente

```auto
fp2@debpacha:~ $ fgrep -B 13 'ata1: EH complete' dmesg.txt > /tmp/par14
fp2@debpacha:~ $ wc /tmp/par14
  1876 17843 123501 /tmp/par14
fp2@debpacha:~ $ 

```

on arrive à un chiffre rond de 134 blocs de 14 lignes, chaque bloc se terminant par «&nbsp;ta1: EH complete&nbsp;»

Bref, on a une erreur irrécupérable dès qu’on veut lire le secteur 2048 au début de la partition sda1, pour lire le super-bloc par exemple

Je suis tenté de faire

```auto
dd if=/dev/zero of=/dev/sda1 bs=1M count=2
mkdosfs /dev/sda1
dosfslabel -i /dev/sda1
# copier le volume-id dans la ligne de fstab UUID=.. /boot/efi ...
# faire un fdisk pour le type de partition ?
mount /boot/efi

```

Qu’en pensez-vous ? Si besoin je peux écraser /dev/sda3 pour la partition EFI

Cordialement,  
Regards,  
Mit freundlichen Grüßen,  
مع تحياتي الخالصة

* * *

F. Petitjean  
Ingénieur civil du Génie Maritime.

« Je préfère le vin d’ici à l’au-delà »  
Pierre Dac

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Février 13, 2022, 6:10 UTC](https://www.debian-fr.org/t/plus-de-demarrage-uefi-casse/86129/7 "2022-02-13T18:10:34Z")

</div>

> [@zao](#):
>
> > [@PascalHambourg](#):
> >
> > L’installation du chargeur d’amorçage dans le « chemin de périphérique amovible » (qui n’est qu’un nom et ne signifie absolument pas que le disque est amovible) n’est pas spécifique à Asus mais nécessaire avec tout firmware UEFI buggé qui gère mal les variables de boot EFI.
> 
> je suis un âne : la remarque que tu fais était déjà donnée , hormis le "ne signifie pas que le disque est amovible ", par l’installateur debian et je l’avais déjà oubliée ( même pas 2 semaines !! ) .  
> merci pour la réponse .

Cela ne signifie aps que le disque est amovible, mais c’est le seul moyen, sur certaines machines de pouvoir amorcer un système sur un disque amovible (USB, DVD, etc..) autre que le système sur le disque courant de la machine.

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Février 13, 2022, 6:47 UTC](https://www.debian-fr.org/t/plus-de-demarrage-uefi-casse/86129/8 "2022-02-13T18:47:27Z")

</div>

> [@littlejohn75](#):
>
> j’ai lancé smartctl avec l’option `--test=short` sur tout le disque d’1 T

Pas besoin de ce test pour voir les erreurs déjà connues, et le test court ne suffit pas pour détecter les éventuelles erreurs pas encore découvertes. Ce qui m’intéresse, c’est le rapport complet affiché avec smartctl -a.

> [@littlejohn75](#):
>
> et j’ai été trahi par ma mauvaise vision en croyant que le fichier généré étatit vide. Voilà une sortie qui le confirme

Le contenu complet de /tmp n’a aucun intérêt. Seul le contenu du fichier d’erreurs produit par badblocks aurait été utile pour évaluer l’ampleur des dégâts. 8 octets, Je suppose qu’il s’agit des 4 premiers blocs de 1 Kio 0 à 3 (8 secteurs logiques de 512 octets) contenus dans le premier secteur physique de 4 Kio de la partition, mais autant vérifier.

> [@littlejohn75](#):
>
> Bref, on a une erreur irrécupérable dès qu’on veut lire le secteur 2048 au début de la partition sda1, pour lire le super-bloc par exemple

Voilà. Pas besoin d’en écrire des pages.  
Si c’est du FAT16, il n’y a pas de copie du secteur de boot. Si c’est du FAT32, il y a une copie mais elle risque de se trouver dans le même secteur physique illisible, donc pas gagné.

> [@littlejohn75](#):
>
> Qu’en pensez-vous ? Si besoin je peux écraser /dev/sda3 pour la partition EFI

Vu que le Windows ne marche plus et que ce n’est pas difficile de réinstaller GRUB, je pense que c’est le plus simple. Un badblocks -w (écriture destructive) sur la partition pour tenter de faire réallouer le secteur défectueux par le contrôleur intégré du disque. Si ça réussit, à contrôler avec smartctl -a, la partition pourra être reformatée, montée (ajuster l’UUID dans /etc/fstab si nécessaire), et GRUB réinstallé.

Si le secteur défectueux ne disparaît pas, il faudra recréer la partition en décalant le début dans la zone saine.

---

<div class="post-metadata">

**Author:** ![littlejohn75](https://www.debian-fr.org/user_avatar/www.debian-fr.org/littlejohn75/32/3840_2.png) [@littlejohn75](https://www.debian-fr.org/u/littlejohn75)\
**Post date:** [Février 14, 2022, 3:56 UTC](https://www.debian-fr.org/t/plus-de-demarrage-uefi-casse/86129/9 "2022-02-14T15:56:07Z")

</div>

> [@PascalHambourg](#):
>
> Seul le contenu du fichier d’erreurs produit par badblocks aurait été utile pour évaluer l’ampleur des dégâts. 8 octets, Je suppose qu’il s’agit des 4 premiers blocs de 1 Kio 0 à 3 (8 secteurs logiques de 512 octets) contenus dans le premier secteur physique de 4 Kio de la partition,

Magnifique intuition !

```auto
⏚ fp2@debpacha:~/ouaoua $ cat sda1_bblocks 
0
1
2
3
⏚ fp2@debpacha:~/ouaoua $

```

> [@PascalHambourg](#):
>
> Un badblocks -w (écriture destructive) sur la partition pour tenter de faire réallouer le secteur défectueux par le contrôleur intégré du disque.

Fait.  
Un second

```auto
badblocks /dev/sda1

```

donne une liste vide 🙂

> [@PascalHambourg](#):
>
> Si ça réussit, à contrôler avec smartctl -a,

Voici une sortie de `smartctl -a /dev/sda` avec les erreurs

```plaintext
cat smaetctl_1
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.10.0-10-amd64] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family: Toshiba 2.5" HDD MQ01ABD...
Device Model: TOSHIBA MQ01ABD100
Serial Number: 35LKPNXIT
LU WWN Device Id: 5 000039 622b0487f
Firmware Version: AX0R2J
User Capacity: 1,000,204,886,016 bytes [1.00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 5400 rpm
Form Factor: 2.5 inches
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS (minor revision not indicated)
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Mon Feb 14 14:43:17 2022 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status: (0x00)	Offline data collection activity
					was never started.
					Auto Offline Data Collection: Disabled.
Self-test execution status: ( 112)	The previous self-test completed having
					the read element of the test failed.
Total time to complete Offline 
data collection: ( 120) seconds.
Offline data collection
capabilities: (0x5b) SMART execute Offline immediate.
					Auto Offline data collection on/off support.
					Suspend Offline collection upon new
					command.
					Offline surface scan supported.
					Self-test supported.
					No Conveyance Self-test supported.
					Selective Self-test supported.
SMART capabilities: (0x0003)	Saves SMART data before entering
					power-saving mode.
					Supports SMART auto save timer.
Error logging capability: (0x01)	Error logging supported.
					General Purpose Logging supported.
Short self-test routine 
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 237) minutes.
SCT capabilities: (0x003d)	SCT Status supported.
					SCT Error Recovery Control supported.
					SCT Feature Control supported.
					SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate 0x000b 100 100 050 Pre-fail Always - 0
  2 Throughput_Performance 0x0005 100 100 050 Pre-fail Offline - 0
  3 Spin_Up_Time 0x0027 100 100 001 Pre-fail Always - 1858
  4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 4311
  5 Reallocated_Sector_Ct 0x0033 100 100 050 Pre-fail Always - 0
  7 Seek_Error_Rate 0x000b 100 100 050 Pre-fail Always - 0
  8 Seek_Time_Performance 0x0005 100 100 050 Pre-fail Offline - 0
  9 Power_On_Hours 0x0032 022 022 000 Old_age Always - 31459
 10 Spin_Retry_Count 0x0033 185 100 030 Pre-fail Always - 0
 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 4278
191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 1663
192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 158
193 Load_Cycle_Count 0x0032 067 067 000 Old_age Always - 332577
194 Temperature_Celsius 0x0022 100 100 000 Old_age Always - 30 (Min/Max 11/51)
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 100 100 000 Old_age Always - 40
198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 1
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0
220 Disk_Shift 0x0002 100 100 000 Old_age Always - 0
222 Loaded_Hours 0x0032 033 033 000 Old_age Always - 27191
223 Load_Retry_Count 0x0032 100 100 000 Old_age Always - 0
224 Load_Friction 0x0022 100 100 000 Old_age Always - 0
226 Load-in_Time 0x0026 100 100 000 Old_age Always - 273
240 Head_Flying_Hours 0x0001 100 100 001 Pre-fail Offline - 0

SMART Error Log Version: 1
ATA Error Count: 1183 (device log contains only the most recent five errors)
	CR = Command Register [HEX]
	FR = Features Register [HEX]
	SC = Sector Count Register [HEX]
	SN = Sector Number Register [HEX]
	CL = Cylinder Low Register [HEX]
	CH = Cylinder High Register [HEX]
	DH = Device/Head Register [HEX]
	DC = Device Command Register [HEX]
	ER = Error register [HEX]
	ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 1183 occurred at disk power-on lifetime: 31459 hours (1310 days + 19 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 41 d0 00 08 00 40 Error: UNC at LBA = 0x00000800 = 2048

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
  -- -- -- -- -- -- -- -- ---------------- --------------------
  60 00 00 00 18 90 40 00 00:11:48.757 READ FPDMA QUEUED
  60 00 f0 00 98 b6 40 00 00:11:48.757 READ FPDMA QUEUED
  60 00 e8 00 48 23 40 00 00:11:48.757 READ FPDMA QUEUED
  60 00 e0 00 48 1f 40 00 00:11:48.757 READ FPDMA QUEUED
  60 00 d8 00 28 03 40 00 00:11:48.757 READ FPDMA QUEUED

Error 1182 occurred at disk power-on lifetime: 31459 hours (1310 days + 19 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 41 90 00 08 00 40 Error: UNC at LBA = 0x00000800 = 2048

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
  -- -- -- -- -- -- -- -- ---------------- --------------------
  60 00 b8 00 18 90 40 00 00:11:35.301 READ FPDMA QUEUED
  60 00 b0 00 98 b6 40 00 00:11:35.301 READ FPDMA QUEUED
  60 00 a8 00 48 23 40 00 00:11:35.301 READ FPDMA QUEUED
  60 00 a0 00 48 1f 40 00 00:11:35.301 READ FPDMA QUEUED
  60 00 98 00 28 03 40 00 00:11:35.301 READ FPDMA QUEUED

Error 1181 occurred at disk power-on lifetime: 31459 hours (1310 days + 19 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 41 b0 00 08 00 40 Error: UNC at LBA = 0x00000800 = 2048

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
  -- -- -- -- -- -- -- -- ---------------- --------------------
  60 00 d8 00 18 90 40 00 00:11:31.366 READ FPDMA QUEUED
  60 00 d0 00 98 b6 40 00 00:11:31.366 READ FPDMA QUEUED
  60 00 c8 00 48 23 40 00 00:11:31.366 READ FPDMA QUEUED
  60 00 c0 00 48 1f 40 00 00:11:31.366 READ FPDMA QUEUED
  60 00 b8 00 28 03 40 00 00:11:31.366 READ FPDMA QUEUED

Error 1180 occurred at disk power-on lifetime: 31459 hours (1310 days + 19 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 41 b8 00 08 00 40 Error: UNC at LBA = 0x00000800 = 2048

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
  -- -- -- -- -- -- -- -- ---------------- --------------------
  60 00 e0 00 18 90 40 00 00:11:27.340 READ FPDMA QUEUED
  60 00 d8 00 98 b6 40 00 00:11:27.340 READ FPDMA QUEUED
  60 00 d0 00 48 23 40 00 00:11:27.340 READ FPDMA QUEUED
  60 00 c8 00 48 1f 40 00 00:11:27.340 READ FPDMA QUEUED
  60 00 c0 00 28 03 40 00 00:11:27.340 READ FPDMA QUEUED

Error 1179 occurred at disk power-on lifetime: 31459 hours (1310 days + 19 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 41 98 00 08 00 40 Error: UNC at LBA = 0x00000800 = 2048

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
  -- -- -- -- -- -- -- -- ---------------- --------------------
  60 00 98 00 08 00 40 00 00:11:23.413 READ FPDMA QUEUED
  60 00 90 00 16 90 40 00 00:11:23.403 READ FPDMA QUEUED
  60 00 88 00 17 90 40 00 00:11:23.380 READ FPDMA QUEUED
  60 00 60 00 28 03 40 00 00:11:23.290 READ FPDMA QUEUED
  60 00 58 00 48 1f 40 00 00:11:23.290 READ FPDMA QUEUED

SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed: read failure 00% 31457 2048
# 2 Selective offline Completed without error 00% 26278 -
# 3 Selective offline Completed without error 00% 26275 -
# 4 Selective offline Completed without error 00% 26275 -
# 5 Selective offline Completed without error 00% 26275 -
# 6 Extended offline Completed: read failure 00% 26271 244283912
# 7 Short offline Completed without error 00% 26268 -

SMART Selective self-test log data structure revision number 1
 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
    1 244283900 1953525167 Not_testing
    2 0 0 Not_testing
    3 0 0 Not_testing
    4 0 0 Not_testing
    5 0 0 Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

```

et la sortie différentielle après l’option `(w`

```auto
⏚ fp2@debpacha:~/ouaoua $ diff -u smaetctl_1 smaetctl_2
--- smaetctl_1 2022-02-14 14:43:17.000000000 +0100
+++ smaetctl_2 2022-02-14 14:46:18.000000000 +0100
@@ -14,7 +14,7 @@
 Device is: In smartctl database [for details use: -P show]
 ATA Version is: ATA8-ACS (minor revision not indicated)
 SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
-Local Time is: Mon Feb 14 14:43:17 2022 CET
+Local Time is: Mon Feb 14 14:46:18 2022 CET
 SMART support is: Available - device has SMART capability.
 SMART support is: Enabled

@@ -67,21 +67,21 @@
  12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 4278
 191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 1663
 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 158
-193 Load_Cycle_Count 0x0032 067 067 000 Old_age Always - 332577
+193 Load_Cycle_Count 0x0032 067 067 000 Old_age Always - 332581
 194 Temperature_Celsius 0x0022 100 100 000 Old_age Always - 30 (Min/Max 11/51)
 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0
-197 Current_Pending_Sector 0x0032 100 100 000 Old_age Always - 40
+197 Current_Pending_Sector 0x0032 100 100 000 Old_age Always - 32
 198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 1
 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0
 220 Disk_Shift 0x0002 100 100 000 Old_age Always - 0
 222 Loaded_Hours 0x0032 033 033 000 Old_age Always - 27191
 223 Load_Retry_Count 0x0032 100 100 000 Old_age Always - 0
 224 Load_Friction 0x0022 100 100 000 Old_age Always - 0
-226 Load-in_Time 0x0026 100 100 000 Old_age Always - 273
+226 Load-in_Time 0x0026 100 100 000 Old_age Always - 262
 240 Head_Flying_Hours 0x0001 100 100 001 Pre-fail Offline - 0

 SMART Error Log Version: 1
-ATA Error Count: 1183 (device log contains only the most recent five errors)
+ATA Error Count: 1189 (device log contains only the most recent five errors)
        CR = Command Register [HEX]
        FR = Features Register [HEX]
        SC = Sector Count Register [HEX]
@@ -96,90 +96,90 @@
 DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
 SS=sec, and sss=millisec. It "wraps" after 49.710 days.

-Error 1183 occurred at disk power-on lifetime: 31459 hours (1310 days + 19 hours)
+Error 1189 occurred at disk power-on lifetime: 31459 hours (1310 days + 19 hours)
   When the command that caused the error occurred, the device was active or idle.

   After command completion occurred, registers were:
   ER ST SC SN CL CH DH
   -- -- -- -- -- -- --
- 40 41 d0 00 08 00 40 Error: UNC at LBA = 0x00000800 = 2048
+ 40 41 20 00 08 00 40 Error: UNC at LBA = 0x00000800 = 2048

   Commands leading to the command that caused the error were:
   CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
   -- -- -- -- -- -- -- -- ---------------- --------------------
- 60 00 00 00 18 90 40 00 00:11:48.757 READ FPDMA QUEUED
- 60 00 f0 00 98 b6 40 00 00:11:48.757 READ FPDMA QUEUED
- 60 00 e8 00 48 23 40 00 00:11:48.757 READ FPDMA QUEUED
- 60 00 e0 00 48 1f 40 00 00:11:48.757 READ FPDMA QUEUED
- 60 00 d8 00 28 03 40 00 00:11:48.757 READ FPDMA QUEUED
+ 60 08 20 00 08 00 40 00 00:16:12.928 READ FPDMA QUEUED
+ ef 10 02 00 00 00 a0 00 00:16:12.928 SET FEATURES [Enable SATA feature]
+ 27 00 00 00 00 00 e0 00 00:16:12.927 READ NATIVE MAX ADDRESS EXT [OBS-ACS-3]
+ ec 00 00 00 00 00 a0 00 00:16:12.926 IDENTIFY DEVICE
+ ef 03 45 00 00 00 a0 00 00:16:12.926 SET FEATURES [Set transfer mode]

-Error 1182 occurred at disk power-on lifetime: 31459 hours (1310 days + 19 hours)
+Error 1188 occurred at disk power-on lifetime: 31459 hours (1310 days + 19 hours)
   When the command that caused the error occurred, the device was active or idle.

   After command completion occurred, registers were:
   ER ST SC SN CL CH DH
   -- -- -- -- -- -- --
- 40 41 90 00 08 00 40 Error: UNC at LBA = 0x00000800 = 2048
+ 40 41 40 00 08 00 40 Error: UNC at LBA = 0x00000800 = 2048

   Commands leading to the command that caused the error were:
   CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
   -- -- -- -- -- -- -- -- ---------------- --------------------
- 60 00 b8 00 18 90 40 00 00:11:35.301 READ FPDMA QUEUED
- 60 00 b0 00 98 b6 40 00 00:11:35.301 READ FPDMA QUEUED
- 60 00 a8 00 48 23 40 00 00:11:35.301 READ FPDMA QUEUED
- 60 00 a0 00 48 1f 40 00 00:11:35.301 READ FPDMA QUEUED
- 60 00 98 00 28 03 40 00 00:11:35.301 READ FPDMA QUEUED
+ 60 08 40 00 08 00 40 00 00:16:09.116 READ FPDMA QUEUED
+ ef 10 02 00 00 00 a0 00 00:16:09.115 SET FEATURES [Enable SATA feature]
+ 27 00 00 00 00 00 e0 00 00:16:09.115 READ NATIVE MAX ADDRESS EXT [OBS-ACS-3]
+ ec 00 00 00 00 00 a0 00 00:16:09.114 IDENTIFY DEVICE
+ ef 03 45 00 00 00 a0 00 00:16:09.114 SET FEATURES [Set transfer mode]

-Error 1181 occurred at disk power-on lifetime: 31459 hours (1310 days + 19 hours)
+Error 1187 occurred at disk power-on lifetime: 31459 hours (1310 days + 19 hours)
   When the command that caused the error occurred, the device was active or idle.

   After command completion occurred, registers were:
   ER ST SC SN CL CH DH
   -- -- -- -- -- -- --
- 40 41 b0 00 08 00 40 Error: UNC at LBA = 0x00000800 = 2048
+ 40 41 30 00 08 00 40 Error: UNC at LBA = 0x00000800 = 2048

   Commands leading to the command that caused the error were:
   CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
   -- -- -- -- -- -- -- -- ---------------- --------------------
- 60 00 d8 00 18 90 40 00 00:11:31.366 READ FPDMA QUEUED
- 60 00 d0 00 98 b6 40 00 00:11:31.366 READ FPDMA QUEUED
- 60 00 c8 00 48 23 40 00 00:11:31.366 READ FPDMA QUEUED
- 60 00 c0 00 48 1f 40 00 00:11:31.366 READ FPDMA QUEUED
- 60 00 b8 00 28 03 40 00 00:11:31.366 READ FPDMA QUEUED
+ 60 08 30 00 08 00 40 00 00:16:05.300 READ FPDMA QUEUED
+ ea 00 00 00 00 00 a0 00 00:16:05.300 FLUSH CACHE EXT
+ ef 10 02 00 00 00 a0 00 00:16:05.299 SET FEATURES [Enable SATA feature]
+ 27 00 00 00 00 00 e0 00 00:16:05.299 READ NATIVE MAX ADDRESS EXT [OBS-ACS-3]
+ ec 00 00 00 00 00 a0 00 00:16:05.298 IDENTIFY DEVICE

-Error 1180 occurred at disk power-on lifetime: 31459 hours (1310 days + 19 hours)
+Error 1186 occurred at disk power-on lifetime: 31459 hours (1310 days + 19 hours)
   When the command that caused the error occurred, the device was active or idle.

   After command completion occurred, registers were:
   ER ST SC SN CL CH DH
   -- -- -- -- -- -- --
- 40 41 b8 00 08 00 40 Error: UNC at LBA = 0x00000800 = 2048
+ 40 41 68 00 08 00 40 Error: WP at LBA = 0x00000800 = 2048

   Commands leading to the command that caused the error were:
   CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
   -- -- -- -- -- -- -- -- ---------------- --------------------
- 60 00 e0 00 18 90 40 00 00:11:27.340 READ FPDMA QUEUED
- 60 00 d8 00 98 b6 40 00 00:11:27.340 READ FPDMA QUEUED
- 60 00 d0 00 48 23 40 00 00:11:27.340 READ FPDMA QUEUED
- 60 00 c8 00 48 1f 40 00 00:11:27.340 READ FPDMA QUEUED
- 60 00 c0 00 28 03 40 00 00:11:27.340 READ FPDMA QUEUED
+ 61 08 70 a0 a2 3a 40 00 00:16:01.440 WRITE FPDMA QUEUED
+ 60 08 68 00 08 00 40 00 00:16:01.440 READ FPDMA QUEUED
+ ea 00 00 00 00 00 a0 00 00:16:01.440 FLUSH CACHE EXT
+ ef 10 02 00 00 00 a0 00 00:16:01.439 SET FEATURES [Enable SATA feature]
+ 27 00 00 00 00 00 e0 00 00:16:01.439 READ NATIVE MAX ADDRESS EXT [OBS-ACS-3]

-Error 1179 occurred at disk power-on lifetime: 31459 hours (1310 days + 19 hours)
+Error 1185 occurred at disk power-on lifetime: 31459 hours (1310 days + 19 hours)
   When the command that caused the error occurred, the device was active or idle.

   After command completion occurred, registers were:
   ER ST SC SN CL CH DH
   -- -- -- -- -- -- --
- 40 41 98 00 08 00 40 Error: UNC at LBA = 0x00000800 = 2048
+ 40 41 20 00 08 00 40 Error: WP at LBA = 0x00000800 = 2048

   Commands leading to the command that caused the error were:
   CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
   -- -- -- -- -- -- -- -- ---------------- --------------------
- 60 00 98 00 08 00 40 00 00:11:23.413 READ FPDMA QUEUED
- 60 00 90 00 16 90 40 00 00:11:23.403 READ FPDMA QUEUED
- 60 00 88 00 17 90 40 00 00:11:23.380 READ FPDMA QUEUED
- 60 00 60 00 28 03 40 00 00:11:23.290 READ FPDMA QUEUED
- 60 00 58 00 48 1f 40 00 00:11:23.290 READ FPDMA QUEUED
+ 61 20 50 80 a2 3a 40 00 00:15:58.915 WRITE FPDMA QUEUED
+ 60 20 20 00 08 00 40 00 00:15:57.584 READ FPDMA QUEUED
+ ef 10 02 00 00 00 a0 00 00:15:57.583 SET FEATURES [Enable SATA feature]
+ 27 00 00 00 00 00 e0 00 00:15:57.583 READ NATIVE MAX ADDRESS EXT [OBS-ACS-3]
+ ec 00 00 00 00 00 a0 00 00:15:57.582 IDENTIFY DEVICE

 SMART Self-test log structure revision number 1
 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
⏚ fp2@debpacha:~/ouaoua 1 $

```

Je recrée le système de fichier FAT et modifie le UUID= dans la ligne de /etc/fstab concernant /boot/efi : la partition peut être montée.  
Réinstallation de grub :

- warning UEFI variables are not supported on this system
- une erreur grub.prober concernant no sstème on /dev/sdb1 (partition bootable mais vide d’une clé netinst )  
Au redémarrage toujours le BIOS  
Je remets la clé, cela va nettement plus vite et je force l’installation dans le chemin amovible  
Redémarrage : Victoire. La Debian du fiston est réparée

Merci beaucoup @PascalHambourg

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Février 14, 2022, 8:18 UTC](https://www.debian-fr.org/t/plus-de-demarrage-uefi-casse/86129/10 "2022-02-14T20:18:06Z")

</div>

> [@littlejohn75](#):
>
> Magnifique intuition !

C’était plus de la déduction à partir des indices que de l’intuition.

> [@littlejohn75](#):
>
> ```auto
> -197 Current_Pending_Sector 0x0032 100 100 000 Old_age Always - 40
> +197 Current_Pending_Sector 0x0032 100 100 000 Old_age Always - 32
> 
> ```

Soit moins les 8 secteurs logiques du début de la partition EFI qui ont été rafistolés sur place en écrivant dedans (et non réalloués car l’attribut «&nbsp;5 Reallocated\_Sector\_Ct&nbsp;» est resté à 0). Mais il reste encore au moins 32 secteurs logiques (soit 4 secteurs physiques) illisibles ailleurs. Le décompte complet ne pourra être connu qu’avec badblocks en lecture seule sur tout le disque.

> [@littlejohn75](#):
>
> warning UEFI variables are not supported on this system

Cette erreur pourrait être causée par le fait que efivarfs ne soit pas monté par le mode rescue lorsqu’on lance un shell dans le système installé, contrairement à l’option «&nbsp;réinstaller GRUB&nbsp;» du menu rescue. Mais installer GRUB dans le chemin de support amovible c’est très bien aussi et plus sûr, ça rend l’amorçage indépendant de la gestion parfois défaillante des variables de boot EFI par le firmware UEFI. D’ailleurs d’autres OS le font systématiquement et ont moins de scrupules que Debian.
