Ubuntu auf dem Raspberry Pi: flash-kernel exited with return code 1

Während des Updates meiner Ubuntu Installation auf einem Raspberry Pi 4 bin ich zum wiederholten Male auf ein Problem gestoßen. Bei einem Update trat folgender Fehler auf:

mv: cannot move '/boot/firmware/overlays/rpi-sense-v2.dtbo' to '/boot/firmware/overlays/rpi-sense-v2.dtbo.bak': No such file or directory
run-parts: /etc/initramfs/post-update.d//flash-kernel exited with return code 1
dpkg: error processing package initramfs-tools (--configure):
 installed initramfs-tools package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 initramfs-tools
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)

Auch wenn der Fehler nicht das erste Mal auftrat, so trat der Fehler nicht immer auf. Wenn der Fehler auftrat, dann während des Updates des initramfs-tools Pakets und das Verschieben von Dateien, um eine Sicherung davon zu machen. Jedes Mal habe versucht die Ursache zu finden. Die Datei, die den Fehler verursacht, war auch immer eine andere und entgegen der Fehlermeldung existiert(e) die Datei jedes Mal. Auch touch funktionierte wie gewohnt auf dem Dateisystem. Meistens konnte ich das Problem lösen, indem ich die Datei verschoben oder gelöscht habe und eine leere neue erstellt habe. In meinen Fall war es nie etwas was ich genutzt habe. Da der Fehler nicht zum ersten Mal auftrat und ich immer wieder davon genervt war, habe ich etwas mehr Zeit zur Untersuchung aufgewendet.

user:~$ which flash-kernel
/usr/sbin/flash-kernel
user:~$ file $(which flash-kernel)
/usr/sbin/flash-kernel: POSIX shell script, Unicode text, UTF-8 text executable

Bei flash-kernel handelt es sich glücklicherweise um ein Shellskript, welches sich somit leicht untersuchen lässt. Es lädt eine weitere Datei /usr/share/flash-kernel/functions und der interessante Teil ist:

687
backup_and_install() {
688
        local source="$1"
689
        local dest="$2"
690
        local do_dot_bak=$(get_dot_bak_preference)
691
        local mtd_backup_dir=$(get_mtd_backup_dir)
692
        if [ -e "$dest" ]; then
693
                if [ -n "$do_dot_bak" ]; then
694
                        echo "Taking backup of $(basename "$dest")." >&2
695
                        mv "$dest" "$dest.bak"
696
                else
697
                        echo "Skipping backup of $(basename "$dest")." >&2
698
                fi
699
        fi
700
        # If we are installing to a filesystem which is not normally mounted
701
        # then take a second copy in /var/backups, where they can e.g. be
702
        # backed up.
703
        if [ -n "$boot_mnt_dir" ] && [ -n "$mtd_backup_dir" ] ; then
704
                local bak="$mtd_backup_dir/"$(basename "$dest")
705
                #echo "Saving $boot_device:"$(basename "$source")" in $bak"
706
                mkdir -p "$mtd_backup_dir"
707
                cp "$source" "$bak"
708
        fi
709
        echo "Installing new $(basename "$dest")." >&2
710
        mv "$source" "$dest"
711
        maybe_defrag "$dest"
712
}

Nichts Aufregendes. Wenn eine Datei existiert wird davon eine Sicherung mit der Endung .bak erstellt, bevor sie ersetzt wird. Mal schauen was passiert, wenn man einige Befehle manuell ausführt:

root:~# mv /boot/firmware/overlays/rpi-sense-v2.dtbo /boot/firmware/overlays/rpi-sense-v2.dtbo.bak
mv: cannot move '/boot/firmware/overlays/rpi-sense-v2.dtbo' to '/boot/firmware/overlays/rpi-sense-v2.dtbo.bak': No such file or directory
root:~# rm /boot/firmware/overlays/rpi-sense-v2.dtbo
rm: cannot remove '/boot/firmware/overlays/rpi-sense-v2.dtbo': No such file or directory

Interessant 🤔 In dem Moment als ich die Fehlermeldung vom rm Befehl gelesen habe, kommt mir eine Idee. Ich sollte das Dateisystem auf Fehler prüfen!

root:~# lsblk -e7
NAME                                   MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda                                      8:0    0 931.5G  0 disk
├─sda1                                   8:1    0   256M  0 part  /boot/firmware
...

Das Dateisystem aushängen (umount), eine Dateisystemüberprüfung durchführen, das Dateisystem wieder einhängen (mount) und die fehlerhaften Paketinstallationen beheben:

root:~# umount /boot/firmware
root:~# fsck.vfat -av /dev/sda1
fsck.fat 4.2 (2021-01-31)
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "mkfs.fat"
Media byte 0xf8 (hard disk)
       512 bytes per logical sector
       512 bytes per cluster
        32 reserved sectors
First FAT starts at byte 16384 (sector 32)
         2 FATs, 32 bit entries
   2064896 bytes per FAT (= 4033 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 4146176 (sector 8098)
    516190 data clusters (264289280 bytes)
32 sectors/track, 16 heads
         0 hidden sectors
    524288 sectors total
Long filename fragment "spi3-2cs.dtbo" found outside a LFN sequence.
  (Maybe the start bit is missing on the last fragment)
  Not auto-correcting this.
Orphaned long file name part ".bak"
  Auto-deleting.
Long filename fragment "midi-uart2.dt" found outside a LFN sequence.
  (Maybe the start bit is missing on the last fragment)
  Not auto-correcting this.
Orphaned long file name part ".bak"
  Auto-deleting.
Long filename fragment "spi4-1cs.dtbo" found outside a LFN sequence.
  (Maybe the start bit is missing on the last fragment)
  Not auto-correcting this.
Orphaned long file name part "pi4.dtbo.bak"
  Auto-deleting.
Long filename fragment "-pcm512x-audi" found outside a LFN sequence.
  (Maybe the start bit is missing on the last fragment)
  Not auto-correcting this.
Long filename fragment "allo-boss-dac" found outside a LFN sequence.
  (Maybe the start bit is missing on the last fragment)
  Not auto-correcting this.
A new long file name starts within an old one.
  Not auto-correcting this.
Orphaned long file name part "midi-uart1-pi5.dtbo"
  Auto-deleting.
Reclaiming unconnected clusters.
Reclaimed 34 unused clusters (17408 bytes) in 11 chains.
Checking free cluster summary.
*** Filesystem was changed ***
Writing changes.
/dev/sda1: 1169 files, 340372/516190 clusters
root:~# mount /boot/firmware
root:~# apt --fix-broken install

Endlich! Es war tatsächlich nur ein korruptes Dateisystem. Das kann auch darauf hindeuten, dass das Laufwerk so langsam ihren Geist aufgibt. Ein guter Zeitpunkt um mittels S.M.A.R.T. unter der Verwendung der smartmontools den Zustand des Laufwerks zu überprüfen. Die erste Abfrage scheiterte direkt mit einer Fehlermeldung. Das spiegelt sich mit meiner Erfahrung externen via USB angebundenen Laufwerken wider. An dem Punkt hatte ich nicht mehr so viel Hoffnung die S.M.A.R.T. Werte auszulesen. Ich suchte nach einer Lösung und fand sie!¹ update-smart-drivedb einmal ausgeführt und das Laufwerk wird erkannt!

root:~# apt install smartmontools
root:~# update-smart-drivedb
root:~# smartctl -c /dev/sda
...
Short self-test routine
recommended polling time:        (   2) minutes.
Extended self-test routine
recommended polling time:        ( 182) minutes.
...

root:~# smartctl -t short /dev/sda
root:~# sleep 2m && smartctl -l selftest /dev/sda
...

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error

# 1  Short offline       Completed without error       00%     31445         -
root:~# smartctl -H /dev/sda
...
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

Das sieht gut aus. Ich hoffe, dass Laufwerk hält noch lange durch. Vielleicht sollte ich die smartmontools auch vernünftig einrichten, so dass mir eine E-Mail geschickt wird, sollten die S.M.A.R.T. Werte auf einen baldigen Ausfall hindeuten.