Plötzlich startet die Linux VM1 nicht mehr normal, sondern im Reparatur-Modus. Das "warum" ist nicht zu ergründen, nur, wie man das beheben könnte.

Und jetzt - zum Beispiel - spielt die Virtualisierung ihre Stärken aus. Ich kann alles aus der Ferne "remote" durchführen, denn zum Glück ist die DOM-0 (das Grundsystem) stabil und immer verfügbar.

Im Grundsystem öffne ich ein Terminal-Fenster (xterm) und rufe den Befehl "lsblk" auf
(zeige mir alle Partitionen und Subpartitionen mit Namen und Größe an)

(sda und sdb sind die einzelnen physikalischen SSds - md0 und md126 und md127 sind die gespiegelten logischen Partitionen)

Hier die Ergebnis-Ausgabe :

[KVM-Kanzlei-DOM0-root] / $ lsblk

NAME          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda             8:0    0 223.6G  0 disk
├─sda1          8:1    0    30G  0 part
│ └─md0         9:0    0    30G  0 raid1
│   ├─md0p1   259:0    0   512M  0 part  /boot/efi
│   ├─md0p2   259:1    0     2G  0 part  [SWAP]
│   └─md0p3   259:2    0  27.3G  0 part  /
├─sda2          8:2    0    80G  0 part
│ └─md127       9:127  0    80G  0 raid1
│   ├─md127p1 259:3    0     8M  0 part
│   ├─md127p2 259:4    0     2G  0 part
│   ├─md127p3 259:5    0    30G  0 part
│   └─md127p4 259:6    0    48G  0 part
└─sda3          8:3    0 113.6G  0 part
  └─md126       9:126  0 113.6G  0 raid1
    ├─md126p1 259:7    0   500M  0 part
    └─md126p2 259:8    0 113.1G  0 part
sdb             8:16   0 223.6G  0 disk
├─sdb1          8:17   0    30G  0 part
│ └─md0         9:0    0    30G  0 raid1
│   ├─md0p1   259:0    0   512M  0 part  /boot/efi
│   ├─md0p2   259:1    0     2G  0 part  [SWAP]
│   └─md0p3   259:2    0  27.3G  0 part  /
├─sdb2          8:18   0    80G  0 part
│ └─md127       9:127  0    80G  0 raid1
│   ├─md127p1 259:3    0     8M  0 part
│   ├─md127p2 259:4    0     2G  0 part
│   ├─md127p3 259:5    0    30G  0 part
│   └─md127p4 259:6    0    48G  0 part
└─sdb3          8:19   0 113.6G  0 part
  └─md126       9:126  0 113.6G  0 raid1
    ├─md126p1 259:7    0   500M  0 part
    └─md126p2 259:8    0 113.1G  0 part
sdc             8:32   0 111.8G  0 disk
├─sdc1          8:33   0    55G  0 part
└─sdc2          8:34   0  56.8G  0 part

[KVM-Kanzlei-DOM0-root] / $

Unser Problem liegt in der logischen (gespiegelten) Subpartition "md127p3".
.

[KVM-Kanzlei-DOM0-root] / $ fsck /dev/md127p3

fsck from util-linux 2.39.3
e2fsck 1.47.0 (5-Feb-2023)
/dev/md127p3 contains a file system with errors, check forced.

Pass 1: Checking inodes, blocks, and sizes
Running additional passes to resolve blocks claimed by more than one inode...
Pass 1B: Rescanning for multiply-claimed blocks
Multiply-claimed block(s) in inode 263842: 1057262
Multiply-claimed block(s) in inode 263951: 1057262
Pass 1C: Scanning directories for inodes with multiply-claimed blocks
Pass 1D: Reconciling multiply-claimed blocks
(There are 2 inodes containing multiply-claimed blocks.)

File /var/log/YaST2/control-03 (inode #263842, mod time Sun Nov  2 16:59:14 2025)
  has 1 multiply-claimed block(s), shared with 1 file(s):
        /var/opt/mssql (inode #263951, mod time Sat Nov  1 00:54:24 2025)
Clone multiply-claimed blocks<y>? yes
File /var/opt/mssql (inode #263951, mod time Sat Nov  1 00:54:24 2025)
  has 1 multiply-claimed block(s), shared with 1 file(s):
        /var/log/YaST2/control-03 (inode #263842, mod time Sun Nov  2 16:59:14 2025)
Multiply-claimed blocks already reassigned or cloned.

Pass 2: Checking directory structure
Invalid inode number for '.' in directory inode 263842.
Fix<y>? yes
Directory inode 263951, block #0: directory passes checks but fails checksum.
Fix<y>? yes

Pass 3: Checking directory connectivity
'..' in /var/log/YaST2/control-03 (263842) is /var/opt (262198), should be /var/log/YaST2 (262147).
Fix<y>? yes

Pass 4: Checking reference counts
Inode 262147 ref count is 12, should be 11.  Fix<y>? yes

Inode 262198 ref count is 2, should be 3.  Fix<y>? yes

Unattached inode 263890
Connect to /lost+found<y>? yes
Inode 263890 ref count is 2, should be 1.  Fix<y>? yes
Unattached inode 263909
Connect to /lost+found<y>? yes
Inode 263909 ref count is 2, should be 1.  Fix ('a' enables 'yes' to all) <y>? yes to all
Inode 263951 ref count is 6, should be 2.  Fix? yes

Pass 5: Checking group summary information
Block bitmap differences:  -1057277
Fix? yes

Free blocks count wrong for group #0 (23509, counted=23508).
Fix? yes

Free blocks count wrong for group #32 (24055, counted=24056).
Fix? yes

/dev/md127p3: ***** FILE SYSTEM WAS MODIFIED *****
/dev/md127p3: 68667/1966080 files (0.1% non-contiguous), 1286262/7864320 blocks

==========================================================================
und jetzt zur Kontrolle :

[KVM-Kanzlei-DOM0-root] / $ fsck /dev/md127p3
fsck from util-linux 2.39.3
e2fsck 1.47.0 (5-Feb-2023)
/dev/md127p3: clean, 68667/1966080 files, 1286262/7864320 blocks

Und endlich : md127p3 ist wieder in Ordnung

Inzwischen (5 Tage später) wurde die VM1 insgesamt über 10 Male runter gefahren (also ein shutdown und kein rebbot) und neu gestartet, teilweise mit einem Kaltstart des gesamten Servers und dieser Fehler ist nicht mehr aufgetreten ?? Wo also suchen ?
.