Ubuntu 20.04 File system check failed

[kgb545]

Ik heb een Ubuntu machine draaien met Ubuntu 20.04. Deze fungeert als server, waar diverse applicaties op draaien (PlexMedia Server, Sonarr/Radarr en diverse docker containers).

Het systeem deed wat vreemd, dus ik heb een reboot gedaan.Bij het afsluiten kreeg ik al een melding over een read-only file system. Ik kwam na de reboot in een busybox omgeving waar (initramfs) stond vermeld, Na een exit commando kreeg ik een foutmedling: "Failure: File system check of the root filesystem faild. The root filesystem on /dev/nvme0n1p2 requires a manual fsck".

Na het uitvoeren van de fsck op /dev/nvme0n1p2 (met -y optie) kreeg ik wat meldingen als:
- Inode xxxxx was part of the orphaned inode list. FIXED (meerdere)
- Free blocks count wrong (meerdere)
- free inode count wrong for group xxx

Na een reboot draait alles voorlopig weer.

Moet ik me zorgen maken ? Gaat mijn Samsung 970 EVO 1TB M.2 SSD het begeven ? Of is het een kwestie van wat bad sectors, is nu gerepareerd, en klaar?

Zijn er nog zaken die ik kan doen/checken/fixen ?

[TommieW]

Ik denk beginnen bij de SMART van de SSD uit te lezen. (Dus "smartctl -a /dev/nvme0n1")

[ Voor 23% gewijzigd door TommieW op 09-03-2022 12:58 ]

[DiedX]

Smart uitlezen. Ik maak me nu nog geen zorgen: die meldingen heb je typisch bij een harde reboot.

[kgb545]

Een sudo nvme smart-log /dev/nvme0 geeft het volgende resultaat:

code:

Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning                    : 0
temperature                         : 45 C
available_spare                     : 100%
available_spare_threshold           : 10%
percentage_used                     : 0%
data_units_read                     : 4.305.055
data_units_written                  : 15.204.639
host_read_commands                  : 28.871.038
host_write_commands                 : 138.507.243
controller_busy_time                : 1.112
power_cycles                        : 17
power_on_hours                      : 1.757
unsafe_shutdowns                    : 6
media_errors                        : 14
num_err_log_entries                 : 110
Warning Temperature Time            : 0
Critical Composite Temperature Time : 0
Temperature Sensor 1                : 45 C
Temperature Sensor 2                : 50 C
Thermal Management T1 Trans Count   : 0
Thermal Management T2 Trans Count   : 0
Thermal Management T1 Total Time    : 0
Thermal Management T2 Total Time    : 0

en SmartCTL:

code:

smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.13.0-35-generic] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Number:                       Samsung SSD 970 EVO 1TB
Serial Number:                      S5H9NS0R106356A
Firmware Version:                   2B2QEXE7
PCI Vendor/Subsystem ID:            0x144d
IEEE OUI Identifier:                0x002538
Total NVM Capacity:                 1.000.204.886.016 [1,00 TB]
Unallocated NVM Capacity:           0
Controller ID:                      4
Number of Namespaces:               1
Namespace 1 Size/Capacity:          1.000.204.886.016 [1,00 TB]
Namespace 1 Utilization:            279.075.069.952 [279 GB]
Namespace 1 Formatted LBA Size:     512
Namespace 1 IEEE EUI-64:            002538 5111405e15
Local Time is:                      Wed Mar  9 13:09:00 2022 CET
Firmware Updates (0x16):            3 Slots, no Reset required
Optional Admin Commands (0x0017):   Security Format Frmw_DL Self_Test
Optional NVM Commands (0x005f):     Comp Wr_Unc DS_Mngmt Wr_Zero Sav/Sel_Feat Timestmp
Maximum Data Transfer Size:         512 Pages
Warning  Comp. Temp. Threshold:     85 CelsiusCritical Comp. Temp. Threshold:     85 Celsius
Supported Power States
St Op     Max   Active     Idle   RL RT WL WT  Ent_Lat  Ex_Lat
 0 +     6.20W       -        -    0  0  0  0        0       0
 1 +     4.30W       -        -    1  1  1  1        0       0
 2 +     2.10W       -        -    2  2  2  2        0       0
 3 -   0.0400W       -        -    3  3  3  3      210    1200
 4 -   0.0050W       -        -    4  4  4  4     2000    8000

Supported LBA Sizes (NSID 0x1)
Id Fmt  Data  Metadt  Rel_Perf
 0 +     512       0         0

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

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        45 CelsiusAvailable Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    0%
Data Units Read:                    4.305.199 [2,20 TB]
Data Units Written:                 15.204.813 [7,78 TB]
Host Read Commands:                 28.871.721Host Write Commands:                138.510.229
Controller Busy Time:               1.112
Power Cycles:                       17
Power On Hours:                     1.757
Unsafe Shutdowns:                   6
Media and Data Integrity Errors:    14
Error Information Log Entries:      110
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0
Temperature Sensor 1:               45 CelsiusTemperature Sensor 2:               50 Celsius
Error Information (NVMe Log 0x01, max 64 entries)
Num   ErrCount  SQId   CmdId  Status  PELoc          LBA  NSID    VS
  0        110     0  0x1012  0x4004      -            0     0     -

[ Voor 56% gewijzigd door kgb545 op 09-03-2022 13:11 ]

[nelizmastr]

DiedX schreef op woensdag 9 maart 2022 @ 12:59:
Smart uitlezen. Ik maak me nu nog geen zorgen: die meldingen heb je typisch bij een harde reboot.

Dit idd. Harde reset heeft altijd een fsck tot gevolg. Meestal automagisch, maar soms moet je 't met het handje doen. Betekent niet per definitie dat er wat stuk is of gaat. Gewoon een straf voor lomp omgaan met je spul

[kgb545]

Vreemd, hij blijft in "read only" mode schieten. Kom dan weer in "busybox", doe de fsck op /dev/nvme0n1p2, reboot, en dan doet ie het weer een paar uur.

Hoe kan ik er achter komen door wat dit wordt veroorzaakt?

[Hero of Time]

Daar moet een reden voor zijn. Tijd om in logs te kijken en een paar actief te volgen om te zien wat er zoal gebeurt rond de tijd dat het onderuit klapt. Een 'journalctl --follow' zou al wat inzicht moeten geven.

[Soldaatje]

Heb je toevallig fast_commit aangezet op een ext4 filesystem? Hier heb ik ook problemen mee gehad.
https://wiki.archlinux.or...t_in_existing_filesystems

[kgb545]

Hero of Time schreef op woensdag 9 maart 2022 @ 22:26:
Daar moet een reden voor zijn. Tijd om in logs te kijken en een paar actief te volgen om te zien wat er zoal gebeurt rond de tijd dat het onderuit klapt. Een 'journalctl --follow' zou al wat inzicht moeten geven.

is er een mogelijkheid dit naar een file te schrijven? En daarmee de ssh sessie te sluiten?

Soldaatje schreef op woensdag 9 maart 2022 @ 22:38:
Heb je toevallig fast_commit aangezet op een ext4 filesystem? Hier heb ik ook problemen mee gehad.
https://wiki.archlinux.or...t_in_existing_filesystems

Nee, ik heb niks aangezet. laatste 2 zaken die ik heb gewijzigd zijn het toevoegen van 2 docker containers (pihole en delugevpn), maar die draaien beide al een paar weken zonder problemen.

[Thralas]

DiedX schreef op woensdag 9 maart 2022 @ 12:59:
Smart uitlezen. Ik maak me nu nog geen zorgen: die meldingen heb je typisch bij een harde reboot.

Dat was met ext2 misschien zo, maar een journaled filesystem is daar in principe juist tegen bestand.

Als een journal replay niet volstaat en fsck corruptie (!) detecteert dan is er wel degelijk reden tot zorgen. Het feit dat TS aangeeft dat z'n filesystem tijdens gebruik readonly wordt is ook een aanwijzing: dat gebeurt alleen als er runtime corruptie optreedt.

kgb545 schreef op woensdag 9 maart 2022 @ 13:04:
Een sudo nvme smart-log /dev/nvme0 geeft het volgende resultaat:

Die media errors lijken me zorgelijk.

Kun je de NVMe error log eens verbose printen met nvme error-log /dev/nvme0n1?

is er een mogelijkheid dit naar een file te schrijven? En daarmee de ssh sessie te sluiten?

Als dit niet je root filesystem is dan gebeurt dat vanzelf. Dan hoef je ook niet te wachten tot het nog een keer gebeurt, maar staat er nu ook al genoeg interessante informatie in je journal (met name de kernel logging op het moment van optreden is interessant).

Als dit wél je root filesystem is dan kan dat natuurlijk niet. Want zodra je filesystem corruptie detecteert remount 'ie readonly, en kun je je logs dus ook niet meer wegschrijven.

Aangezien je kennelijk nog kunt inloggen als het probleem optreedt kun je ook dán de output van dmesg en/of journalctl bekijken. Alleen wel kopiëren voor je opnieuw opstart.

[kgb545]

De NVME error-log:

code:

Error Log Entries for device:nvme0n1 entries:64
.................
 Entry[ 0]   
.................
error_count  : 129
sqid         : 0
cmdid        : 0x100e
status_field : 0x4004(INVALID_FIELD: A reserved coded value or an unsupported value in a defined field)
parm_err_loc : 0xffff
lba          : 0
nsid         : 0
vs           : 0
cs           : 0
.................
 Entry[ 1]   
.................
error_count  : 0
sqid         : 0
cmdid        : 0
status_field : 0(SUCCESS: The command completed successfully)
parm_err_loc : 0
lba          : 0
nsid         : 0
vs           : 0
cs           : 0

Overige entries zijn als entry 1, dus leeg / success

Helaas is het de root-schijf, dus maar eens kijken als het weer optreedt in dmesg en journal.

Heb wel de oude journals van 2 dagen bekeken (via journalctl), maar dat is veel, en zie in eerste instantie geen rare dingen. Maar helaas weet ik ook niet goed waarop ik zou moeten zoeken. Zou in ieder geval de kernel meldingen eens bekijken.

Vooralsnog draait het systeem weer stabiel. Heb wel wat oude torrents verwijderd (helaas werden die in een home directy op de root schijf geplaatst, dat ga ik sowieso verhuizen naar een andere SSD die ook in het systeem zit)

[DiedX]

Kan het zijn dat een van de partities volgelopen is?