Hallo zusammen,

ich habe gerade ein großes Problem. Mein Rechner startet nur noch
in den Singleuser Modus, weil er /home nicht einbinden kann ("cant't
read superblock...").
Installiert ist Debian bullseye über 2 Festplatten mit crypted lvm.
Meine Versuche das Dateisystem mit alternativem Superblock zu prüfen
(e2fsck -c -p -t -v -b 1605632 /dev/terravm/home) lieferte leider auch
nur "The superblock could not be read or ..." Hab alle alternativen Superblöcke durch probiert.

Zum Aufbau der 2 Platten: Warum heißt das hier terravm-home-missing?
(siehe unten). Wobei sich in /dev/mapper/ sowohl terravm-home als auch terravm-home-mising_0_0 befindet.
Physisch befindet sich /home auf sda4.
Wie kann ich die Partitione /home wiederherstellen? Backup existiert.
Aber ich kann die Partition auch nicht formatieren.

Wenn ich noch weitere Infos angeben soll, gerne. Ich wollte mal jetzt
nicht zu viel evtl. unnötiges hier rein packen.

Danke schon mal!
Ulrich


# lsblk
sda
|--sda1
|--sda2
|--sda3
|--sda4
|--sda4_crypt

sr0

terravm-home-missing_0_0
|--terravm-home

nvme0n1
|--nvme0n1p1 /boot/efi
[...]
|--nvme0n1p7 /boot
|--nvme0n1p8
|--nvme0n1p8_crypt
|--terrayvm-root
|--terrayvm-usr
|--terrayvm-tmp
|--terrayvm-var
|--terrayvm-swap


--
Zufallssignatur:
Many dead animals of the past changed to fossils
while others preferred to be oil

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

Hallo zusammen,

hat tatsächlich keiner einer Idee? Ich muss also das ganze LVM neu
aufsetzen, weil eine Partition eine Macke hat?

Ulrich

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

On 14.10.21 15:46, Ulrich Fürst wrote:

hat tatsächlich keiner einer Idee? Ich muss also das ganze LVM neu aufsetzen, weil eine Partition eine Macke hat?

Wenn Deine VG sich über mehrere PVs erstreckt, sind in der Tat die LVs verloren, die auf dem ausgefallenen PV liegen.

Viele Grüße
Ulf

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

On 14.10.21 17:18, Ulrich Fürst wrote:

Ulf Volmer wrote:

On 14.10.21 15:46, Ulrich Fürst wrote:

hat tatsächlich keiner einer Idee? Ich muss also das ganze LVM neu
aufsetzen, weil eine Partition eine Macke hat?

Wenn Deine VG sich über mehrere PVs erstreckt, sind in der Tat die
LVs verloren, die auf dem ausgefallenen PV liegen.

D.h. ich müsste nur dieses eine PV neu machen?
Sprich PV aus dem LVM herausnehmen.
Neu Partitionieren und wieder in die LVM hinein nehmen?

Ja. Ein 'vgreduce --remove-missing' sollte das vermutlich tun.

Viele Grüße
Ulf

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

Ulf Volmer wrote:

On 14.10.21 15:46, Ulrich Fürst wrote:

hat tatsächlich keiner einer Idee? Ich muss also das ganze LVM neu aufsetzen, weil eine Partition eine Macke hat?

Wenn Deine VG sich über mehrere PVs erstreckt, sind in der Tat die
LVs verloren, die auf dem ausgefallenen PV liegen.

D.h. ich müsste nur dieses eine PV neu machen?
Sprich PV aus dem LVM herausnehmen.
Neu Partitionieren und wieder in die LVM hinein nehmen?

Viele Grüße
ULrich

--
Zufallssignatur:
Moral ist das zu tun was richtig ist, egal was einem gesagt wird.
Religion ist das zu tun was einem gesagt wird, egal was richtig
ist. H.L. Mencken

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

Am 14.10.2021 um 17:18 schrieb Ulrich Fürst:

Ulf Volmer wrote:

On 14.10.21 15:46, Ulrich Fürst wrote:

hat tatsächlich keiner einer Idee? Ich muss also das ganze LVM neu
aufsetzen, weil eine Partition eine Macke hat?

Wenn Deine VG sich über mehrere PVs erstreckt, sind in der Tat die
LVs verloren, die auf dem ausgefallenen PV liegen.

D.h. ich müsste nur dieses eine PV neu machen?
Sprich PV aus dem LVM herausnehmen.
Neu Partitionieren und wieder in die LVM hinein nehmen?

Das kommt darauf an, was dem phys. Datenträger /dev/sda, der Partition /dev/sda4 oder dem Crypt-Volume /dev/sda4_crypt denn zugestoßen ist,
warum es also dem LVM nicht mehr als PV zur Verfügung steht.

Was ist denn passiert oder auf der Maschine getan worden, bevor gebootet
und das Volume nicht mehr gefunden wurde?


mfG Paul

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

Hallo Ulrich,

mir ist aus Deiner Problembeschreibung nicht klargeworden, wie Deine Konfiguration tatsächlich aussieht und funktioneren sollte.

Am Samstag, 9. Oktober 2021 schrieb Ulrich Fürst:

Hallo zusammen,

ich habe gerade ein großes Problem. Mein Rechner startet nur noch
in den Singleuser Modus, weil er /home nicht einbinden kann ("cant't
read superblock...").

Das könnte verschiedene Ursachen haben, denke ich.

Installiert ist Debian bullseye über 2 Festplatten mit crypted lvm.

Wie genau ist das konfiguriert? Ein logisches Volume über zwei verschlüsselte physikalische Partitionen? Oder umgekehrt? Die Ausgabe
der Befehle pvs und lvs (als root) könnten hier weiterhelfen.

Meine Versuche das Dateisystem mit alternativem Superblock zu prüfen
(e2fsck -c -p -t -v -b 1605632 /dev/terravm/home) lieferte leider
auch nur "The superblock could not be read or ..." Hab alle
alternativen Superblöcke durch probiert.

Hast Du die Systemlogs durchgesehen, ob es Hinweise gibt? Vielleicht Hardwarefehler?

Zum Aufbau der 2 Platten: Warum heißt das hier terravm-home-missing?
(siehe unten). Wobei sich in /dev/mapper/ sowohl terravm-home als
auch terravm-home-mising_0_0 befindet.
Physisch befindet sich /home auf sda4.

/dev/sda4 ist als sda4_crypt verschlüsselt. Wie ist dann die
verschlüsselte Partitione in LVM eingebunden?

Wie kann ich die Partitione /home wiederherstellen? Backup existiert.
Aber ich kann die Partition auch nicht formatieren.

Wenn ich noch weitere Infos angeben soll, gerne. Ich wollte mal jetzt
nicht zu viel evtl. unnötiges hier rein packen.

Das Nötige wäre gut, um das Problem verstehen zu können. ;-)
Die vollständige Ausgabe von lsblk wäre auch nicht schlecht.

Danke schon mal!
Ulrich

# lsblk
sda

|--sda1
|--sda2
|--sda3
|--sda4
|
|--sda4_crypt

sr0

terravm-home-missing_0_0

|--terravm-home

nvme0n1

|--nvme0n1p1 /boot/efi

[...]

|--nvme0n1p7 /boot
|--nvme0n1p8
|
|--nvme0n1p8_crypt
|
|--terrayvm-root
|--terrayvm-usr
|--terrayvm-tmp
|--terrayvm-var
|--terrayvm-swap

Herzlichen Gruß, Stefan

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

Guten Abend!

Starten kann ich den Rechner mittlerweile. Es lag
wohl am nvidia-Treiber. Denn die lvm.conf hatte
ich bereits wieder auf activationmode="degraded" zurück geändert.
Mit "partial" habe ich aber wieder ein nicht mountbares /home
Im Prinzip war es also wohl beides(?): nvidia-Grafik-Treiber und
lvm.conf

Leider bleibt dadurch weiterhin die Fehlermeldung beim booten: (die
Ausgaben von pvs usw. sind weiter hinten)
aus dem boot.log:
Volume group "terravm" not found^M
Cannot process volume group terravm^M
Volume group "terravm" not found^M
Cannot process volume group terravm^M
No key available with this passphrase.^M

# Was "normal" ist. Kenn ich vom Laptop seit Jahren nicht anders und es
# kommt auch jetzt erst die Passwortabfrage.

WARNING: Couldn't find device with uuid
bFT801-AIMi-xebB-CeuQ-DU60-er8N-jr5D6c.
WARNING: VG terravm is missing PV
bFT801-AIMi-xebB-CeuQ-DU60-er8N-jr5D6c (last written to /dev/mapper/sda4_crypt).
WARNING: Couldn't find device with uuid
bFT801-AIMi-xebB-CeuQ-DU60-er8N-jr5D6c.
WARNING: VG terravm is missing PV
bFT801-AIMi-xebB-CeuQ-DU60-er8N-jr5D6c (last written to /dev/mapper/sda4_crypt).
Refusing activation of partial LV
terravm/home. Use '--activationmode partial' to override. /dev/mapper/terravm-root: clean, 4127/183264 files, 365249/732160
blocks
/dev/mapper/terravm-usr: clean, 275807/1525920 files,
2183380/6103040 blocks


Frage: Ist das überhaupt ein Fehler? /home ist da und von der Größe her
auch vollständig.

Am Thu, 14 Oct 2021 18:02:39 +0200
schrieb Stefan Krusche <linux@stefan-krusche.de>:

Hallo Ulrich,

mir ist aus Deiner Problembeschreibung nicht klargeworden, wie Deine Konfiguration tatsächlich aussieht und funktioneren sollte.

Danke, dass Du es versuchst :-)

Am Samstag, 9. Oktober 2021 schrieb Ulrich Fürst:

Installiert ist Debian bullseye über 2 Festplatten mit crypted lvm.

Wie genau ist das konfiguriert? Ein logisches Volume über zwei verschlüsselte physikalische Partitionen? Oder umgekehrt? Die Ausgabe
der Befehle pvs und lvs (als root) könnten hier weiterhelfen.

root@terra:~# pvs
PV VG Fmt Attr PSize PFree
/dev/mapper/nvme0n1p8_crypt terravm lvm2 a-- <46.86g 0
/dev/mapper/sda4_crypt terravm lvm2 a-- <1.71t 0

root@terra:~# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log
Cpy%Sync Convert home terravm -wi-ao---- <1.71t root terravm
-wi-ao---- 2.79g swap terravm -wi-ao---- <10.54g tmp terravm
-wi-ao---- <5.59g usr terravm -wi-ao---- 23.28g var terravm
-wi-ao---- <4.66g root@terra:~#

root@terra:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 1.8T 0 disk
├─sda1 8:1 0 16M 0 part
├─sda2 8:2 0 105.2G 0 part
├─sda3 8:3 0 9.8G 0 part
└─sda4 8:4 0 1.7T 0 part
└─sda4_crypt 254:6 0 1.7T 0 crypt
└─terravm-home 254:7 0 1.7T 0 lvm /home
sr0 11:0 1 1024M 0 rom
nvme0n1 259:0 0 238.5G 0 disk
├─nvme0n1p1 259:1 0 260M 0 part /boot/efi
├─nvme0n1p2 259:2 0 128M 0 part
├─nvme0n1p3 259:3 0 188.3G 0 part
├─nvme0n1p4 259:4 0 1G 0 part
├─nvme0n1p5 259:5 0 954M 0 part
├─nvme0n1p6 259:6 0 572M 0 part
├─nvme0n1p7 259:7 0 477M 0 part /boot
└─nvme0n1p8 259:8 0 46.9G 0 part
└─nvme0n1p8_crypt 254:0 0 46.9G 0 crypt
├─terravm-root 254:1 0 2.8G 0 lvm /
├─terravm-usr 254:2 0 23.3G 0 lvm /usr
├─terravm-tmp 254:3 0 5.6G 0 lvm /tmp
├─terravm-var 254:4 0 4.7G 0 lvm /var
└─terravm-swap 254:5 0 10.5G 0 lvm [SWAP]

Schönen Abend und Danke für die Hilfe!
Ulrich

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

Guten Abend!

Paul Muster wrote:

Was ist denn passiert oder auf der Maschine getan worden, bevor
gebootet und das Volume nicht mehr gefunden wurde?

abgesehen davon, dass ich mit den nvidia-Treiber herumprobiert habe
(was vermutlich nicht relevant ist?) - Doch ist es.

Da ich aber gerade auch am LVM herum gedocktert habe, dachte ich das
das ja logischerweise schuld sein muss. Ist nicht gut mehrere
Änderungen gleichzeitig zu machen :-(

Ich habe auf der Suche vorhin gesehen, dass beim
Booten die Meldung "Failed to start Load kernel modules" kam.
Ich glaube es war die Ausgabe von
# systemctl status systemd-modules-load
die mich dazu gebracht hat erst mal die nvidia-Treiber auf zu
räumen.

Das Problem lag also daran, dass systemd-modules-load sich an nvidia verschluckt und dann nicht mehr weiter geladen hat?
Und gleichzeitig am activation_mode=partial in der lvm.conf

Schönen Abend und Danke für die Hilfe!
Ulrich


Sorry, das krame ich gerade aus meinem Gedächtnis; ist schon Anfang
Oktober war (3.10. vermutlich).

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

On 14.10.21 21:28, Ulrich Fürst wrote:

Das Problem lag also daran, dass systemd-modules-load sich an nvidia verschluckt und dann nicht mehr weiter geladen hat?
Und gleichzeitig am activation_mode=partial in der lvm.conf

Schönen Abend und Danke für die Hilfe!

Dir auch einen schönen Abend. Gerne.

Was mir allerdings nicht klar wird aus deinem - etwas unstrukturieren - Posting: Ist das Problem behoben, d.h. sieht dein LVM nun wieder alle PV
und somit auch das, in dem dein /home-LV liegt?


mfG Paul

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

Am Donnerstag, 14. Oktober 2021 schrieb Ulrich Fürst:

Leider bleibt dadurch weiterhin die Fehlermeldung beim booten: (die
Ausgaben von pvs usw. sind weiter hinten)
aus dem boot.log:
Volume group "terravm" not found^M
  Cannot process volume group terravm^M
  Volume group "terravm" not found^M
  Cannot process volume group terravm^M
No key available with this passphrase.^M

Das ist eine Fehlermeldung, die ich schon oft gesehen habe, wenn ich zum Entschlüsseln eine falsche Passphrase eingegeben habe. Wenn die verschlüsselte Partition sda4_crypt nicht entschlüsselt werden kann,
dann findet LVM nicht den Teil der Volume Group terravm, der auf dem
Physical Volume sda4_crypt liegt, das Logical Volume terravm-home.

Das sieht danach aus, als würde sda4_crypt nicht entschlüsselt werden.

WARNING: Couldn't find device with uuid bFT801-AIMi-xebB-CeuQ-DU60-er8N-jr5D6c.
WARNING: VG terravm is missing PV
bFT801-AIMi-xebB-CeuQ-DU60-er8N-jr5D6c (last written to /dev/mapper/sda4_crypt).

LVM kann Physical Volume sda4_crypt
(bFT801-AIMi-xebB-CeuQ-DU60-er8N-jr5D6c) nicht finden… Warum nicht?

WARNING: Couldn't find device with uuid bFT801-AIMi-xebB-CeuQ-DU60-er8N-jr5D6c.
WARNING: VG terravm is missing PV
bFT801-AIMi-xebB-CeuQ-DU60-er8N-jr5D6c (last written to /dev/mapper/sda4_crypt).
Refusing activation of partial LV
terravm/home.  Use '--activationmode partial' to override.

Diese Fehlermeldung (insbesondere "partial") verstehe ich auch nicht. Möglicherweise eine Folge davon, daß Physical Volume sda4_crypt nicht entschlüsselt wird…?

/dev/mapper/terravm-root: clean, 4127/183264 files, 365249/732160
blocks
/dev/mapper/terravm-usr: clean, 275807/1525920 files,
2183380/6103040 blocks

Die Logical Volumes terravm-root und terravm-usr werden offenbar
gefunden und das Dateisystem geprüft. Wo sind die anderen: terravm-tmp, terravm-var? Oder ist das Log gekürzt?

Frage: Ist das überhaupt ein Fehler? /home ist da und von der Größe
her auch vollständig.

Bist Du sicher? Wenn es "da" ist und "von der Größe her vollständig",
warum ist es dann nicht eingehängt?

Wir brauchen noch mehr Infos, um weiter analysieren zu können.

Was das alles mit dem Kernelmodul für die Grafikkarte zu tun haben
könnte, kann ich mir aufgrund der von Dir geposteten Infos überhaupt
nicht vorstellen. Die Partitionen werden früher als die grafische
Oberfläche beim Hochfahren geladen, soweit ich weiß.

Vielleicht helfen Dir diese Hinweise zum Weiterforschen. Du könntest nachsehen, was eigentlich tatsächlich entschlüsselt und eingehängt ist:

$ mount

zeigt alle eingehängten Paritionen…

$ ls -l /dev/mapper

zeigt die Partitionen, die entschlüsselt wurden sowie die aktivierten
Logical Volumes…

Viel Erfolg!

Tschüß, Stefan

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

Paul Muster wrote:

Was mir allerdings nicht klar wird aus deinem - etwas unstrukturieren
- Posting: Ist das Problem behoben, d.h. sieht dein LVM nun wieder
alle PV und somit auch das, in dem dein /home-LV liegt?

Ja, tut es. Ich schreib mal bei der Antwort an Stefan weiter, weil ich
da eh schon mehr Infos hinein gepackt habe.

VG
Ulrich

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