Hallo Leute,

ich hab so meine Probleme mit Debian 11 auf einem Hyper-V Windows Server
2016.
Möchte natürlich auch die Vorteile der Hyper-V Replikation nutzen und
hab diese eingerichtet.

Bei einem Testfailover bootet der Server aber nicht:

Viele Meldungen wie folgt:
/dev/mapper/mail1--vg-root: Clearing orphaned inode 26....... (uid=118, gid=126, mode=0100600, size=0)
...
...
...

gefolgt von:

Leider ist ein Problem aufgetreten.
Ein Problem ist aufgetreten, welches vom System nicht behoben werden
kann. Bitte kontaktieren Sie den Systemverwalter.

Was kann ich tun?

VG, Andi

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Andreas Wass - Glas Gasperlmair <a.wass@glas-gasperlmair.at> wrote:

Leider ist ein Problem aufgetreten.
Ein Problem ist aufgetreten, welches vom System nicht behoben werden
kann. Bitte kontaktieren Sie den Systemverwalter.

Was kann ich tun?

GRUB_CMDLINE_LINUX_DEFAULT="fsck.repair=yes" in /etc/default/grub
setzen, damit der fsck beim Booten nicht bei jeder kleinen Sache aus der
Kurve fliegt und nach einem Admin schreit.

Wenn das nicht hilft: Mehr infos zur kompletten Fehlermeldung liefern.

S°

--
Sigmentation fault. Core dumped.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hallo Sven,
erstmal vielen Dank für deine Antwort. Ich würde lieber saubere
Neustarts vorziehen und möchte mich nicht auf das verlassen müssen.

Abgesehen davon scheint Debian 11 noch gar nicht in der "Supported
Debian virtual machines on Hyper-V" auf.
Dort geht's derzeit nur bis Version 10

https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/supported-debian-virtual-machines-on-hyper-v

Ich glaub, da warte ich vorerst noch ab und installiere den Mailserver
als physische Maschine.

vg, Andi

Am 11.11.2021 um 09:55 schrieb Sven Hartge:

Andreas Wass - Glas Gasperlmair <a.wass@glas-gasperlmair.at> wrote:

Leider ist ein Problem aufgetreten.
Ein Problem ist aufgetreten, welches vom System nicht behoben werden
kann. Bitte kontaktieren Sie den Systemverwalter.
Was kann ich tun?

GRUB_CMDLINE_LINUX_DEFAULT="fsck.repair=yes" in /etc/default/grub
setzen, damit der fsck beim Booten nicht bei jeder kleinen Sache aus der Kurve fliegt und nach einem Admin schreit.

Wenn das nicht hilft: Mehr infos zur kompletten Fehlermeldung liefern.

S°

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Andreas Wass - Glas Gasperlmair <a.wass@glas-gasperlmair.at> wrote:

erstmal vielen Dank für deine Antwort. Ich würde lieber saubere
Neustarts vorziehen und möchte mich nicht auf das verlassen müssen.

Deine Aussage ist mir unterverständlich.

Gerade das Setzen der Option sorgt dafür, dass das System sauber
startet und nicht beim kleinsten Problem darauf wartet, dass der Admin
"fsck /dev/sdXY" eintippt und dann eine Stunde auf "Y" hämmert, weil er vergessen hat die Option "-y" mit anzugeben.

Oder weißt du bei den Fragen von fsck, ob er ein Änderung wirklich
machen soll, ob du jeweils "N" oder "Y" drücken musst in den
spezifischen Moment?

Ich jedenfalls nicht. Daher kann das System fsck ruhig mit "-y" starten
und alle Reperatur-Versuche unternehmen, das ist nämlich das, was "fsck.repair=yes" bzw. "FSCKFIX=yes" macht.

Und wenn das Dateisystem so kaputt ist, dass selbst diese Option nichts wiederbelebt, dann wäre das auch bei manuellem Aufruf nicht anders. Dann
ist nämlich Restore angesagt.

Abgesehen davon scheint Debian 11 noch gar nicht in der "Supported
Debian virtual machines on Hyper-V" auf.

Wer redet von Debian 11? Das Setzen von fsck.repair=yes funktioniert
schon seit Debian 9 mit systemd. Für SysV musst du FSCKFIX=yes in /etc/defaults/rcS setzen.

S°

--
Sigmentation fault. Core dumped.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 12.11.2021 um 16:32 schrieb Sven Hartge:

Andreas Wass - Glas Gasperlmair <a.wass@glas-gasperlmair.at> wrote:

erstmal vielen Dank für deine Antwort. Ich würde lieber saubere
Neustarts vorziehen und möchte mich nicht auf das verlassen müssen.

Deine Aussage ist mir unterverständlich.

Gerade das Setzen der Option sorgt dafür, dass das System sauber
startet und nicht beim kleinsten Problem darauf wartet, dass der Admin
"fsck /dev/sdXY" eintippt und dann eine Stunde auf "Y" hämmert, weil er vergessen hat die Option "-y" mit anzugeben.

Oder weißt du bei den Fragen von fsck, ob er ein Änderung wirklich
machen soll, ob du jeweils "N" oder "Y" drücken musst in den
spezifischen Moment?

Ich jedenfalls nicht. Daher kann das System fsck ruhig mit "-y" starten
und alle Reperatur-Versuche unternehmen, das ist nämlich das, was "fsck.repair=yes" bzw. "FSCKFIX=yes" macht.

Ja, vielleicht eine gute Idee.

Und wenn das Dateisystem so kaputt ist, dass selbst diese Option nichts wiederbelebt, dann wäre das auch bei manuellem Aufruf nicht anders. Dann
ist nämlich Restore angesagt.

Abgesehen davon scheint Debian 11 noch gar nicht in der "Supported
Debian virtual machines on Hyper-V" auf.

Wer redet von Debian 11? Das Setzen von fsck.repair=yes funktioniert
schon seit Debian 9 mit systemd. Für SysV musst du FSCKFIX=yes in /etc/defaults/rcS setzen.

Ich meinte nicht das setzen von fsck.repair= yes, sondern vielmehr, ob
es vielleicht besser ist, einen produktiven Linux-Server erst dann als virtuelle Maschine unter Windows Hyper-V zu betreiben, wenn die Version
von Debian 11 auch bei Microsoft in den unterstützten Linux Systemen auf
einem Hyper-V  gelistet ist, was zur Zeit ja noch nicht zutrifft. docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/supported-debian-virtual-machines-on-hyper-v

S°

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)