UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Peoples]

HI,

ich habe heute meinen IOB zerschossen, deswegen musst ich einen Snapshot meiner Virtuellen Maschine (Synology) zurückspielen. Iob läuft wieder bestens, Zugriff über Putty bekomme ich auch wie gewohnt, aber wenn ich mich über die Oberfläche des Virtual-Machine-Managers verbinde steht da folgende Meldung:
/dev/sda1: clean, 258035/9773056 files, 6099519/39071232 blocks.

Ich verstehe das so, dass da irgendwas "gereinigt" wird, vermutlich auf Grund der Wiederherstellung..

Die Frage die ich habe ist nun, soll ich einfach warten bis das irgendwann durchgelaufen ist, denn ein sauberer reboot hat nichts gebracht oder kann ich das irgendwie abbrechen bzw. unterbinden sofern das überhaupt Sinn macht?

Über Hilfe wäre ich Dankbar

[OliverIO]

@peoples

warten, linux geht die logische struktur der festplatte (also verzeichnis und datei einträge) durch und repariert bzw meldet zumindest das was zum reparieren ist oder nicht

[Peoples]

@oliverio
Ich danke dir!

[Thomas Braun]

@peoples

Solche Aktionen NIE ab- oder unterbrechen.
Das macht es nur schlimmer.

[Peoples]

@thomas-braun @OliverIO

ich habe jetzt noch ein wenig recherchiert (wie gesagt habe wenig Ahnung).
Wie ich es verstanden habe steht unter etc/fstab ob fsck beim jeweiligen Laufwerk durchgeführt wird oder nicht und man könnte dort die Prüfung auch für das jeweilige Laufwerk deaktivieren. Das betroffene Laufwerk ist dort aber gar nicht gelistet.

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# systemd generates mount units based on this file, see systemd.mount(5).
# Please run 'systemctl daemon-reload' after making changes here.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=4fb3f17c-1096-438e-b7d8-5c4b26b0b8fb /               ext4    errors=remount-ro 0       0
# swap was on /dev/sda5 during installation
UUID=4136a5c3-5031-4273-8787-a0b090e7abe0 none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0
/dev/sr1        /media/cdrom1   udf,iso9660 user,noauto     0       0

wenn ich lsblk -f ausführe kommt

sda
├─sda1 ext4   1.0         4fb3f17c-1096-438e-b7d8-5c4b26b0b8fb  118,5G    14% /
├─sda2
└─sda5 swap   1           4136a5c3-5031-4273-8787-a0b090e7abe0                [SWAP]
sr0
sr1

Da ich nur aus Zufall über den VMM meine Synology auf die Virtuelle Maschine zugegriffen habe, kann ich auch nicht sagen wie lange die Meldung schon da ist und ob die vor dem damaligen Festplattendefekt bzw. den letzten Updates da war.

Ist dann hier im Mount was falsch, weil wie gesagt die fsck - Prüfmeldung verändert sich nicht.

[Thomas Braun]

@peoples

Zu Installationen auf Synology kann ich nix sagen.
Keine Ahnung wie das da genau aufgesetzt wird.

Das betroffene Laufwerk ist dort aber gar nicht gelistet.

Doch, die UUID des Laufwerks ist drin.

[Peoples]

@thomas-braun
Das habe ich gesehen, aber wenn ich dort den Check durch setzen der 0 eintragen, hat das beim Neustart keinen Effekt

[Thomas Braun]

@peoples sagte in Frage an Linux Profis /dev/sda1::

aber wenn ich dort

Wo ist 'dort'? In der sechsten Spalte sollte für das Wurzelsystem eine 1 gesetzt sein, für andere Partitionen z. B. eine 2 (oder entsprechend weitere Nummern). Bei gesetzer 0 wird kein Check beim mounten vorgenommen.
Soweit ich weiß kann diese Voreinstellung aber auch bei aktuem Bedarf vom System 'eigenmächtig' übergangen werden.

[Peoples]

@thomas-braun
UUID=4fb3f17c-1096-438e-b7d8-5c4b26b0b8fb / ext4 errors=remount-ro 0 0
die letzte Null

Das mit dem eigenmächtig übergehen würde erklären warum der Check dennoch läuft.
Ich werde jetzt mal eine Woche warten um zu sehen ob sich da was getan hat. Im dümmsten Fall muss ich IOB halt neu aufsetzen

[Thomas Braun]

@peoples

Was ist denn genau dein Problem? Läuft der Check nicht durch? Mit welchen Meldungen?
Grundsätzlich würde ich so einem angezählten Filesystem auch nicht mehr über den Weg trauen. Hardwaretauschen, Backup einspielen.

[Peoples]

@thomas-braun sagte in Frage an Linux Profis /dev/sda1::

@peoples

Was ist denn genau dein Problem? Läuft der Check nicht durch? Mit welchen Meldungen?
Grundsätzlich würde ich so einem angezählten Filesystem auch nicht mehr über den Weg trauen. Hardwaretauschen, Backup einspielen.

Das "Problem" ist nur dass der Check nicht wirklich weiter läuft.
Sonst funktioniert alles bestens.

Ich hatte hatte vor ca. 8 Wochen einen Festplattendefekt, da die aber im Raid laufen war das nicht weiter schlimm. Habe dann die defekte ausgetauscht und anscheinend ist seit dem der Fehler vorhanden.

Äußern tut sich das so nirgends. Zumindest ist es mir noch nicht aufgefallen.

[Peoples]

Es scheint als hätte ich das Problem gefunden.

Anscheinend lag es an der Virtuellen Grafikkarte die Synology als default für Linux vorgibt.
Debian ab Version 12.9 scheint da Probleme zu haben. Da auch eine neue Installation von Debian 12.10 den Fehler ausspuckte habe ich von "vmvga" auf "vga" umgestellt und dann läuft das neu installierte Linux ohne clean.

Gleiches bei meiner Bestands-Installation

Danke euch trotzdem für eure Mühen

[duffy6]

@Peoples
Grandios! Danke für den Tipp! MAde my day today!