Nach Migration von VMware zu PVE: SLES12SP4 Reihenfolge der Platten (Linux) undurchsichtig

[pmdk]

Moin,
ich hab die 4 vmdks einer unter vSphere laufende Maschine (SLES12SP4) mit "qm importdisk 103 xxx_[1,2,34].vmdk SSD-Pool1 -format qcow2" importiert und in eine plattenlose PVE-VM eingebunden. Anhand der Größe der Platten und der Anzahl der Partitionen kann ich erkennen, welche Platte welche ist. Die "swap+/"-Platte ist die einzige mit zwei Partitionen drauf.
Nun will die Kiste nicht booten (Grub wird noch gestartet) ... zeigt wechselweise eine UUID und sda1 an.
Ich also ein Debian11-Rescue gestartet. Das /-Filesystem wurde mir mit sdb2 angezeigt (original sda2).
Ich hab dann mit der /etc/fstab die richtige Reihenfolge der Platten vorzugeben versucht. Keine Änderung. Also hab ich in /boot mal nach "sda" gesucht und einige "resume"-Einträge dazu gefunden. Wenn ich nun die Resume-Einträge in sdb2 änder (um bei Nichtakzeptanz der UUID auf die Schreibweise zurück zu gehen) verändern sich beim nächsten Boot die Bezeichnungen der Platten und / ist wieder sda2. wtf

Kann das was SuSe-spezifisches sein?
Wie gehe ich am besten systematisch vor, um die Kiste zum booten zu bewegen?

Danke und LG

 

[Philipp Hufnagl]

Hallo

Hast du schon versucht grub zu updaten?

 

[udo]

Moin,
ich hab die 4 vmdks einer unter vSphere laufende Maschine (SLES12SP4) mit "qm importdisk 103 xxx_[1,2,34].vmdk SSD-Pool1 -format qcow2" importiert und in eine plattenlose PVE-VM eingebunden. Anhand der Größe der Platten und der Anzahl der Partitionen kann ich erkennen, welche Platte welche ist. Die "swap+/"-Platte ist die einzige mit zwei Partitionen drauf.
Nun will die Kiste nicht booten (Grub wird noch gestartet) ... zeigt wechselweise eine UUID und sda1 an.
Ich also ein Debian11-Rescue gestartet. Das /-Filesystem wurde mir mit sdb2 angezeigt (original sda2).
Ich hab dann mit der /etc/fstab die richtige Reihenfolge der Platten vorzugeben versucht. Keine Änderung. Also hab ich in /boot mal nach "sda" gesucht und einige "resume"-Einträge dazu gefunden. Wenn ich nun die Resume-Einträge in sdb2 änder (um bei Nichtakzeptanz der UUID auf die Schreibweise zurück zu gehen) verändern sich beim nächsten Boot die Bezeichnungen der Platten und / ist wieder sda2. wtf

Kann das was SuSe-spezifisches sein?
Wie gehe ich am besten systematisch vor, um die Kiste zum booten zu bewegen?

Danke und LG

Hi,
grub scheint den device-Pfad zu nutzen, der jetzt sicherlich ein anderer ist (also update grub, wie schon empfohlen).
Ist bei Dir in der VM unter options -> Boot Order die richtige Disk aktiviert? Wenn Du lvm nutzt und die root-vg über mehrere Platten geht, müssen alle Platten dafür selektiert sein. Könnte auch sein, dass die Reihnfolge da was mit der Reihenfolge in der VM zu tun hat.
In der FS-Tab würde ich nicht mit sda/sdb usw arbeiten sondern mit uuids (blkid zeigt sie dir an).

Udo

 

[Falk R.]

P.S. bei vSphere sind die VMs oft noch mit BIOS Boot, guck mal bei der alten VM ob die BIOS oder UEFI aktiviert hat.

Oder da um 11:00 Uhr zum Workshop anmelden und alles notwendige lernen: https://kielux.de/programm#Tag20230916

 

[pmdk]

Hi, ich versuch mal beide Antworten (Danke dafür!) zu beantworten.

Ein update-grub hat mal nix angezeigt. Ich finde in den grub2/grub.cfg-Einstellungen die UUID der /-Partition.
Beim Booten kommt zuerst die SuSE-Standardauswahl und danach auch der erste SuSE-Screen, den ich mit Esc ausblenden kann. Da sehe ich dann abwechselnd, dass nach einer sda1 (unter vmware die swap-Partition) und nach der UUID (...56dc) gesucht wird. Siehe scrnsht.
Ich hab mal die grub.cfg angefügt. Da gibt es noch diese Verbindung von sdA (statt B) mit der UUID. Wie bekomme ich das korrigiert?

"Bios Boot" hab ich im vSphere6 nicht gefunden.

 

[udo]

Hi, ich versuch mal beide Antworten (Danke dafür!) zu beantworten.

Ein update-grub hat mal nix angezeigt. Ich finde in den grub2/grub.cfg-Einstellungen die UUID der /-Partition.
Beim Booten kommt zuerst die SuSE-Standardauswahl und danach auch der erste SuSE-Screen, den ich mit Esc ausblenden kann. Da sehe ich dann abwechselnd, dass nach einer sda1 (unter vmware die swap-Partition) und nach der UUID (...56dc) gesucht wird. Siehe scrnsht.
Ich hab mal die grub.cfg angefügt. Da gibt es noch diese Verbindung von sdA (statt B) mit der UUID. Wie bekomme ich das korrigiert?

"Bios Boot" hab ich im vSphere6 nicht gefunden.

Liefer mal bitte folgende Info (Namen kannst Du ja ändern)

vom pve-host aus

qm config 103

Die VM 103 mittels live-CD anbooten (z.B. grml).

Aus dem Live-System

blkid

Dann den Inhalt von /etc/fstab vom Suse-system - dafür z.B. das root-filesystem nach /mnt mounten und dann

cat /mnt/etc/fstab

Udo

 

[pmdk]

Hallo Udo,
root@wkst01:~# qm config 103
boot: order=ide2;scsi3 <= ide=cdrom, scsi3=die festplatte mit /
cores: 4
cpu: host
ide2: nas10:iso/debian-11.1.0-amd64-netinst.iso,media=cdrom,size=378M
memory: 12288
meta: creation-qemu=7.2.0,ctime=1691743036
name: wurst
net0: virtio=6E:72:40:4A:19:17,bridge=vmbr0,firewall=1
numa: 0
ostype: l26
scsi0: SSD-Pool1:vm-103-disk-0,size=12G,ssd=1
scsi1: SSD-Pool1:vm-103-disk-1,size=8G,ssd=1
scsi2: SSD-Pool1:vm-103-disk-2,size=40G,ssd=1
scsi3: SSD-Pool1:vm-103-disk-3,size=40G
scsihw: virtio-scsi-pci
smbios1: uuid=06bdc401-88b3-4f20-b83d-ca1177a4b2a4
sockets: 1
vmgenid: fde65dbd-e282-48a6-9d28-3d666684030d
root@wkst01:~#

# Gut zu erkennen: nur die Platte mit "/"+"Swap" hat 2 Partitionen:
blkid:
/dev/sda1: UUID="79e0b7b9-676a-440b-a20f-9a1d6e7fe01b" SEC_TYPE="ext2" TYPE="ext3" PARTUUID="59b60826-01"
/dev/sdb1: UUID="a1483a9f-467f-4303-a732-1fa87ecd77b8" TYPE="swap" PARTUUID="0009327c-01"
/dev/sdb2: UUID="6868ce09-af0c-44c2-a4f3-c79b3c9e56dc" TYPE="ext3" PTTYPE="dos" PARTUUID="0009327c-02"
/dev/sdd1: UUID="d56e672a-c54d-4855-b377-86d35baa8958" SEC_TYPE="ext2" TYPE="ext3" PARTUUID="7a8cbf68-01"
/dev/sdc1: UUID="ac3664fc-3bd9-43c4-9edc-2eebca8cf8f1" TYPE="ext4" PARTUUID="0283c5d5-01"
/dev/sr0: UUID="2021-10-09-10-10-23-00" LABEL="Debian 11.1.0 amd64 n" TYPE="iso9660" PTUUID="603ed470" PTTYPE="dos"

fstab vom Original:
UUID=a1483a9f-467f-4303-a732-1fa87ecd77b8 swap swap defaults 0 0
UUID=6868ce09-af0c-44c2-a4f3-c79b3c9e56dc / ext3 acl,user_xattr 1 1
UUID=79e0b7b9-676a-440b-a20f-9a1d6e7fe01b /var ext3 acl,user_xattr 1 1
UUID=d56e672a-c54d-4855-b377-86d35baa8958 /opt ext3 acl,user_xattr 1 1
/dev/sdd1 /.backup ext4 acl,user_xattr 1 1
/dev/sde1 /opt/xyz btrfs acl 1 1

Auszug aus "fdisk -l":
Festplatte /dev/sda: 12 GiB, 12884901888 Bytes, 25165824 Sektoren
Festplattenbezeichnungstyp: dos
Gerät Boot Anfang Ende Sektoren Größe Kn Typ
/dev/sda1 63 25157789 25157727 12G 83 Linux

Festplatte /dev/sdb: 40 GiB, 42949672960 Bytes, 83886080 Sektoren
Festplattenbezeichnungstyp: dos
Gerät Boot Anfang Ende Sektoren Größe Kn Typ
/dev/sdb1 63 4209029 4208967 2G 82 Linux Swap / Solaris
/dev/sdb2 * 4209030 83875364 79666335 38G 83 Linux

Festplatte /dev/sdd: 8 GiB, 8589934592 Bytes, 16777216 Sektoren
Festplattenbezeichnungstyp: dos
Gerät Boot Anfang Ende Sektoren Größe Kn Typ
/dev/sdd1 63 16771859 16771797 8G 83 Linux

Festplatte /dev/sdc: 40 GiB, 42949672960 Bytes, 83886080 Sektoren
Festplattenbezeichnungstyp: dos
Gerät Boot Anfang Ende Sektoren Größe Kn Typ
/dev/sdc1 2048 83886079 83884032 40G 83 Linux

HTH

 

[udo]

Hallo Udo,
root@wkst01:~# qm config 103
boot: order=ide2;scsi3 <= ide=cdrom, scsi3=die festplatte mit /
cores: 4
cpu: host
ide2: nas10:iso/debian-11.1.0-amd64-netinst.iso,media=cdrom,size=378M
memory: 12288
meta: creation-qemu=7.2.0,ctime=1691743036
name: wurst
net0: virtio=6E:72:40:4A:19:17,bridge=vmbr0,firewall=1
numa: 0
ostype: l26
scsi0: SSD-Pool1:vm-103-disk-0,size=12G,ssd=1
scsi1: SSD-Pool1:vm-103-disk-1,size=8G,ssd=1
scsi2: SSD-Pool1:vm-103-disk-2,size=40G,ssd=1
scsi3: SSD-Pool1:vm-103-disk-3,size=40G
scsihw: virtio-scsi-pci
smbios1: uuid=06bdc401-88b3-4f20-b83d-ca1177a4b2a4
sockets: 1
vmgenid: fde65dbd-e282-48a6-9d28-3d666684030d
root@wkst01:~#

# Gut zu erkennen: nur die Platte mit "/"+"Swap" hat 2 Partitionen:
blkid:
/dev/sda1: UUID="79e0b7b9-676a-440b-a20f-9a1d6e7fe01b" SEC_TYPE="ext2" TYPE="ext3" PARTUUID="59b60826-01"
/dev/sdb1: UUID="a1483a9f-467f-4303-a732-1fa87ecd77b8" TYPE="swap" PARTUUID="0009327c-01"
/dev/sdb2: UUID="6868ce09-af0c-44c2-a4f3-c79b3c9e56dc" TYPE="ext3" PTTYPE="dos" PARTUUID="0009327c-02"
/dev/sdd1: UUID="d56e672a-c54d-4855-b377-86d35baa8958" SEC_TYPE="ext2" TYPE="ext3" PARTUUID="7a8cbf68-01"
/dev/sdc1: UUID="ac3664fc-3bd9-43c4-9edc-2eebca8cf8f1" TYPE="ext4" PARTUUID="0283c5d5-01"
/dev/sr0: UUID="2021-10-09-10-10-23-00" LABEL="Debian 11.1.0 amd64 n" TYPE="iso9660" PTUUID="603ed470" PTTYPE="dos"

fstab vom Original:
UUID=a1483a9f-467f-4303-a732-1fa87ecd77b8 swap swap defaults 0 0
UUID=6868ce09-af0c-44c2-a4f3-c79b3c9e56dc / ext3 acl,user_xattr 1 1
UUID=79e0b7b9-676a-440b-a20f-9a1d6e7fe01b /var ext3 acl,user_xattr 1 1
UUID=d56e672a-c54d-4855-b377-86d35baa8958 /opt ext3 acl,user_xattr 1 1
/dev/sdd1 /.backup ext4 acl,user_xattr 1 1
/dev/sde1 /opt/xyz btrfs acl 1 1

Auszug aus "fdisk -l":
Festplatte /dev/sda: 12 GiB, 12884901888 Bytes, 25165824 Sektoren
Festplattenbezeichnungstyp: dos
Gerät Boot Anfang Ende Sektoren Größe Kn Typ
/dev/sda1 63 25157789 25157727 12G 83 Linux

Festplatte /dev/sdb: 40 GiB, 42949672960 Bytes, 83886080 Sektoren
Festplattenbezeichnungstyp: dos
Gerät Boot Anfang Ende Sektoren Größe Kn Typ
/dev/sdb1 63 4209029 4208967 2G 82 Linux Swap / Solaris
/dev/sdb2 * 4209030 83875364 79666335 38G 83 Linux

Festplatte /dev/sdd: 8 GiB, 8589934592 Bytes, 16777216 Sektoren
Festplattenbezeichnungstyp: dos
Gerät Boot Anfang Ende Sektoren Größe Kn Typ
/dev/sdd1 63 16771859 16771797 8G 83 Linux

Festplatte /dev/sdc: 40 GiB, 42949672960 Bytes, 83886080 Sektoren
Festplattenbezeichnungstyp: dos
Gerät Boot Anfang Ende Sektoren Größe Kn Typ
/dev/sdc1 2048 83886079 83884032 40G 83 Linux

HTH

Moin,
ich würde sagen, dass Du die letzen beiden Platten vertauscht hast. Nimm mal scsi2 als Bootdisk.
Und disable in der fstab die Einträge von sdd1 + sde1 (# davor) - mindestens die btrfs scheint es nicht mehr zu geben?!

Udo

 

[pmdk]

Hi, nein, die Plattenwahl ist richtig. scsi2 bootet nix. In der aktuellen fstab ist nix aktiv außer / und /var.
Ich bin im boot-Prozess ja schon ne ganze ecke weit. Die VM macht ja erst ab Scrnsht5 den Fehler mit der falschen Adressierung. Das liegt m.E. im /boot/grub-Verzeichnis. Vielleicht noch jemand ne Idee? Die 6 Scrnshots sind in Reihenfolge nummeriert.
Scrnsht2 zeigt nur, dass ich die beiden Optionen auswählen kann. Nutzt aber nix.

 

[udo]

Bin mir nicht sicher, ob die Plattenwahl stimmt. Kann es sein, dass der Bootsektor auf die falsche Disk geschrieben wurde?
Die UID die er sucht, war ja in Deinem Beispiel die von sdb.
Wähle einfach bei Boot-Options die Disk ebenso mit aus - braucht nicht die erste Prio haben, nur ausgewählt sein, damit das Bios die Disk sieht.
Das ist auch bei LVM notwendig, wenn das Root-FS auf eine VG liegt, die über mehr als ein PV geht.

Udo

 

[pmdk]

Ok, noch keine Lösung, aber ein Schritt weiter:
a. eigentlich kein proxmox-Problem, sondern SuSE oder grub.
b. /etc/default/grub enthielt eine Zeile mit sda1, hab ich durch sdb2 ersetzt und grub2-mkconfig ausgeführt.
Jetzt sucht er (vergeblich) sdb2 + die UUID, aber zumindest nicht mehr sda1
c. Ich werd mich mal im SuSE-Forum umhören.

Danke soweit.

 

[udo]

Ok, noch keine Lösung, aber ein Schritt weiter:
a. eigentlich kein proxmox-Problem, sondern SuSE oder grub.
b. /etc/default/grub enthielt eine Zeile mit sda1, hab ich durch sdb2 ersetzt und grub2-mkconfig ausgeführt.
Jetzt sucht er (vergeblich) sdb2 + die UUID, aber zumindest nicht mehr sda1
c. Ich werd mich mal im SuSE-Forum umhören.

Danke soweit.

sda1 durch sdb2 zu ersetzen kann nicht richtig sein. Wenn dann sdb1.
Und wenn die UUID nach wie vor gesucht wird, hast Du die Platte als boot-device mit aktiviert?

Udo

 

[pmdk]

SuSE-Forum weiß auch nicht weiter.

sda1 = die swap-Partition, sda2 = slash ohne var

Ich versteh ja auch nicht, warum der Boot-Vorgang so beharrlich die UUID nicht findet.
Ich hab nur diese Platte nochmal an eine neue VM importiert, damit ich eine ursprüngliche Ausgangssituation habe. /var fehlt. Natürlich keine Änderung beim booten. Aber: Debian11-Rescue zeigt die Platte als sda1+sda2 an.
Im Prinzip ist das der originale Status der VSphere-VM, nur die fstab hab ich #aufgeräumt.
Was wäre denn nun sinnvolles zu tun?

 

[Falk R.]

Der möchte immer ein resume from hibernation machen. Das wird nicht funktionieren, da sich die Hardware geändert hat. Hast du die VM auf vSphere in Hibernate gesetzt statt runter gefahren?

 

[pmdk]

Ähm, ich weiß nicht wirklich, was Hibernate (überwintern?) sein soll. Ich nutze die Clone-Funktion im vCenter6 im laufenden Betrieb. Ich dachte, der arbeitet da mit nem Snapshot? Ist Abschalten nicht mittlerweile altmodisch.
Hast Du ne Idee, wie ich (außer abschalten) das besser machen kann?

 

[Falk R.]

Hibernate heißt im deutschen OS, Ruhezustand. Dabei wird der RAM auf Disk gesichert und beim einschalten wieder in RAM kopiert und alle Programme laufen noch.
Wie das bei Linux funktioniert weiß ich nicht, aber bei Windows wird der RAM in eine Datei geschrieben. Ist diese nicht mehr vorhanden, startet Windows auch nicht mehr. Mache ich dann einen Reset der Maschine, wechselt der Bootloader von Windows automatisch auf normalen Boot.
Eventuell steht im Bootloader irgendwo, dass ein Hibernate resume laufen soll.

Ist nur eine Idee von mir und hilft dir eventuell auf eine richtige Spur.

 

[bluesite]

schau mal ob es unter Suse auch die /etc/initramfs-tools/conf.d/resume gibt dort habe ich unter debian folgendes drin stehen
RESUME=none
dadurch wird das deaktiviert dann noch ein
update-initramfs -u machen
und ein update-grub

 

[udo]

SuSE-Forum weiß auch nicht weiter.

sda1 = die swap-Partition, sda2 = slash ohne var

Ich versteh ja auch nicht, warum der Boot-Vorgang so beharrlich die UUID nicht findet.
Ich hab nur diese Platte nochmal an eine neue VM importiert, damit ich eine ursprüngliche Ausgangssituation habe. /var fehlt. Natürlich keine Änderung beim booten. Aber: Debian11-Rescue zeigt die Platte als sda1+sda2 an.
Im Prinzip ist das der originale Status der VSphere-VM, nur die fstab hab ich #aufgeräumt.
Was wäre denn nun sinnvolles zu tun?

Auch wenn ich mich wiederhole, frage ich zum zweiten mal, ob Du die zweite Disk unter Options -> Boot Order mit selektiert hast, damit das Bios die Chance hat diese Disk beim Booten auch zu sehen? Dann könnte das mit der UUID auch klappen.

 

[pmdk]

Auch wenn ich mich wiederhole, frage ich zum zweiten mal, ob Du die zweite Disk unter Options -> Boot Order mit selektiert hast, damit das Bios die Chance hat diese Disk beim Booten auch zu sehen? Dann könnte das mit der UUID auch klappen.

Hallo Udo, ich hab zuletzt jetzt nur die eine Platte eingebunden. Keine weitere. Und ich bin 100% sicher: die einzige Platte mit den 2 Partitionen ist die richtige. Auch die UUID passt zu dieser Partition.

 

[pmdk]

schau mal ob es unter Suse auch die /etc/initramfs-tools/conf.d/resume gibt dort habe ich unter debian folgendes drin stehen
RESUME=none
dadurch wird das deaktiviert dann noch ein
update-initramfs -u machen
und ein update-grub

Hi, ich dachte zuerst, ich bin auf dem richtigen Pfad, immerhin sucht er jetzt nur noch nach seiner UUID, aber weiterhin vergeblich.
Das meiste, was ich gesucht, gefunden, angepasst habe, hab ich in dem info.txt stehen. Dazu noch /etc/default/grub als scrnsht und den unendlichen suchvorgang. Ok, es wird nicht die ganze UUID gelistet, kann sich da iwo ein Sonderzeichen eingeschlichen haben?
Das ist doch blöd.
Ich werd heute abends mal die originale VM runterfahren und kopieren und hoffen, dass sich dadurch etwas verbessert.