Gleiches Image für SATA und NVMe Festplatten

Clientpflege linbo
1

Hallo,
wir haben ein LMN 7.1-Setup mit Pop_OS! 22.04 LTS-Image. Die Clients sind ThinkCentres, alte und neuere Generation gemischt. Das Problem: Die einen haben SATA-Festplatten, die anderen NVMe M.2. Ein Image funktioniert nur auf einem Festplattentyp, für das andere braucht es ein neues Image. Meine Theorie ist, dass das Problem nur die Namensgebung für die Festplatten nur die Namensgebung ist: sdaX vs nvme0n1pX.
Gibt es da vielleicht einen Workaround für? Ich habe zwar wenig Hoffnung, aber fragen kann man ja mal. Vielleicht gibt es ein Script, das die Festplatten vor dem Start im Script umbenennt? Oder gibt es einen Weg, Änderungen am Image auf beide Images zu laden?

Danke schonmal für eure Hilfe, auch wenn ihr mir sagt, dass es nicht geht.

Gruß,
Jakob

2

Hallo Jakob

Wir verwenden das gleiche Image für NVME und SATA, und dafür habe ich einfach zwei Linbo-Gruppen erstellt.
Wie du sagst, Unterschiede liegen nur bei Namensgebung der Festplatte:

$ diff /srv/linbo/start.conf.leh*
4c4
< Cache = /dev/sda4
---
> Cache = /dev/nvme0n1p4
6c6
< Group = leh
---
> Group = leh_nvme
17c17
< Dev = /dev/sda1
---
> Dev = /dev/nvme0n1p1
25c25
< Dev = /dev/sda2
---
> Dev = /dev/nvme0n1p2
33c33
< Dev = /dev/sda3
---
> Dev = /dev/nvme0n1p3
41c41
< Dev = /dev/sda4
---
> Dev = /dev/nvme0n1p4
55,56c55,56
< Boot = /dev/sda2
< Root = /dev/sda2
---
> Boot = /dev/nvme0n1p2
> Root = /dev/nvme0n1p2
75,76c75,76
< Boot = /dev/sda3/srv/linbo
< Root = /dev/sda3
---
> Boot = /dev/nvme0n1p3
> Root = /dev/nvme0n1p3

Gruß

Arnaud

3

Hallo Jakob!
So wie Arnaud das beschreibt, müsste es funktionieren, da Linux beim Starten den falschen Eintrag in der Datei /etc/fstab für die root-Partition (-> /) korrigiert.
Wir haben in der Linux-Installation noch weitere Partitionen verbunden (Datenpartition, Partition für virtuelle Maschinen), deren Einträge werden nicht korrigiert. Daher ersetzen wir in linbo im post-sync-Script die Datei /etc/fstab durch die zur Installation passende Version der Datei (mit den Einträgen /dev/sda… oder /dev/nvme…).
Gruß - Rainer

4

Hallo,

ich hab das im Semianr seit vielen Jahren so: und betreibe es eben so lange mit einem Image.
Da muss man eigentlich nur einmal ein neues Image machen, mit einer fstab, in der statt Devicenamen Label stehen.
Auszug der fstab der entsprechenden Gruppe:

#/dev/sda2 / ext4 errors=remount-ro 0 0
#/dev/sda3       none            swap    sw              0       0
#/dev/sda5 /virtual ext4   rw,nodev,noexec,nosuid,acl              0       0
LABEL=ubuntu  / ext4 errors=remount-ro 0 0
LABEL=swap       none            swap    sw              0       0
LABEL=vbox /virtual ext4   rw,nodev,noexec,nosuid,acl              0       0

Die Label entsprechen den Einträgen in der start.conf.ALLEGRUPPENMITDEMIMAGE
(beispiel der Cache Partition einer SATA SSD Gruppe. Bei nvme steht da eben das nvme Device, also /dev/nvme0n1p6)

[Partition]          # partition section (data)
Label = cache         # partition label
Dev = /dev/sda6      # device name of the partition
Size =               # partition size (no value = remaining space of the disk)
Id = 83               # partition id (7 = ntfs)
FSType = ext4        # filesystem ntfs
Bootable = yes        # set bootable flag no

Label werden erst vergeben, wenn neu partitioniert wird: eintragen in der start.conf alleine reicht nicht.
Label sollten immer klein geschrieben werden, um Probleme zu verhindern.
LG

Holger

5

Hallo zusammen,

wir haben das hier auch so gemacht. Bisher hatten wir LMN 7.1
Nach dem Update auf LMN 7.2 machen die PCs mit nvme0 Probleme und booten nicht mehr.

error: no such device : UUID der Partition

In der /etc/fstab stehen nur Label
Ich bin zwar auf ein paar Artikel gestoßen, wo es um die UUIDs geht, bin aber insofern nicht schlau draus geworden, weil es ja bisher ging und mir da nie etwas auffiehl.
Was hat sich denn in linbo zwischen 7.1 und 7.2 geändert?
Es war doch bisher auch linbo 4, oder sehe ich das falsch?

Viele Grüße
Johannes

6

Hallo Johannes,

in der 7.1 war das linbo 4.0 in der 7.2 ist es linbo 4.2
Das sind sehr sehr große Unterschiede (4 Jahre Entwicklung dazwischen …).

Beschreib mal genauer, was das Problem ist und poste auch die start.conf.GRUPPE
(also beide, denn du hast ja eine für die SATA und eine für die nvme).

Ich hab damals (2019) das upgrade von 7.1 auf 7.2 gemacht und bei mir hat sich bei den „mischgruppen“ die nvme und sata vereinigen, nichts getan: die haben genau so weiter funktioniert.

LG
Holger

7

Hallo Holger,
das ist die startconf für SATA und Legacy Bios

start.conf.mate22
[LINBO]
Server = 10.0.0.1
Group = mate22
Cache = /dev/sda3
RootTimeout = 600
AutoPartition = no
AutoFormat = no
AutoInitCache = no
DownloadType = torrent
GuiDisabled = no
UseMinimalLayout = no
Locale = de-DE
SystemType = bios64
KernelOptions = nosplash noplymouth nomodeset dhcpretry=10  warmstart=no
clientDetailsVisibleByDefault = yes

[Partition]
Bootable = yes
FSType = vfat
Id = ef
Size = 204800
Label = 
Dev = /dev/sda1

[Partition]
Dev = /dev/sda2
Label = ubuntu
Size = 40G
Id = 83
FSType = ext4
Bootable = yes

[Partition]
Bootable = yes
FSType = ext4
Id = 83
Size = 40G
Label = 
Dev = /dev/sda3

[Partition]
Bootable = no
FSType = swap
Id = 82
Size = 16G
Label = 
Dev = /dev/sda4

[OS]
Name = Mate
Version = 22.04
Description = Mate 22.04
IconName = mate.svg
Image = 
BaseImage = mate22.qcow2
Boot = /dev/sda2
Root = /dev/sda2
Kernel = boot/vmlinuz
Initrd = boot/initrd.img
Append = ro splash
StartEnabled = yes
SyncEnabled = yes
NewEnabled = yes
Autostart = yes
AutostartTimeout = 9
DefaultAction = sync
Hidden = yes

Und das für UEFI mit nvme:

start.conf.mate22efi 
[LINBO]
Server = 10.0.0.1
Group = mate22efi
Cache = /dev/nvme0n1p3
RootTimeout = 480
AutoPartition = no
AutoFormat = no
AutoInitCache = no
DownloadType = torrent
GuiDisabled = no
UseMinimalLayout = no
Locale = de-DE
SystemType = efi64
KernelOptions = nosplash noplymouth nomodeset dhcpretry=10  warmstart=no
clientDetailsVisibleByDefault = yes

[Partition]
Bootable = yes
FSType = vfat
Id = ef
Size = 204800
Label = 
Dev = /dev/nvme0n1p1

[Partition]
Dev = /dev/nvme0n1p2
Label = ubuntu
Size = 60G
Id = 83
FSType = ext4
Bootable = yes

[Partition]
Bootable = yes
FSType = ext4
Id = 83
Size = 40G
Label = 
Dev = /dev/nvme0n1p3

[Partition]
Bootable = no
FSType = swap
Id = 82
Size = 16G
Label = swap
Dev = /dev/nvme0n1p4

[OS]
Name = Mate22
Version = 22.04
Description = Mate 22.04
IconName = mate.svg
Image = 
BaseImage = mate22.qcow2
Boot = /dev/nvme0n1p2
Root = /dev/nvme0n1p2
Kernel = /boot/vmlinuz
Initrd = /boot/initrd.img
Append = ro nosplash noplymouth
StartEnabled = yes
SyncEnabled = yes
NewEnabled = yes
Autostart = yes
AutostartTimeout = 10
DefaultAction = start
Hidden = yes

Bei DefaultAction steht hier momentan nur start drin, so bleiben die PCs, die noch nicht synchronisiert haben, startbar. Die mit Sync sind gestorben, also es wird alles runtergeladen und synchronisiert.
Dann kommt vermutlich das lokale Grub und dann die oben genannte Fehlermeldung.
Die UUID ist aber auch die richtige.

Wo kann ich denn die Unterschiede zwischen Linbo 4 und 4.2 nachlesen, aufgefallen war mir bisher nur, das es jetzt wohl differenzielle Images gibt.
Muss eigentlich bei

Kernel = /boot/vmlinuz
Initrd = /boot/initrd.img

/ vor boot stehen, oder nicht (habe beides probiert, gleiche Wirkung)?
Viele Grüße
Johannes

8

Bei uns steht kein führender Slash vor dem boot und ich meine, das wäre auch so Vorgabe.
Also

Kernel = boot/vmlinuz

Gruß
Sascha

9

Hallo,

Kann es sein, dass dein Problem nicht SATA vs NVMe ist, sondern BIOS vs UEFI? Dann wäre Allgemeines Windows Image für UEFI und BIOS ein hilfreicher Ort.

VG
Buster

10

Hallo Buster,
Bios vs Uefi, kann schon sein.
In LMN7.1/Linbo4 ging es mit dieser Startconf, in LMN7.2/Linbo4.2 nicht mehr.
Die Frage für mich ist, was muss in der Startconf anders sein. Oder was ist falsch, fiel aber bei Linbo4 nicht auf. Wir verwenden momentan ausschließlich Ubuntu-Clients, da ist der genannte Artikel leider nicht so hilfreich.

Viele Grüße
Johannes

11

Hallo,

ich dachte auch sofort an BIOS/UEFI und dass die Probleme daherkommen könnten.

Wenn ich das richtig erinnere, dann werden beim upgrade auf linbo 4.2 in den start.confs Dinge geändert…
Wurde den ein linuxmuster_import_devices nach dem upgrade durchgeführt?
Wurden dabei auch die grub.cfg Dateien in /srv/linbo/boot/grub/ neu geschrieben?
Manch einer hat dort ja die „Schutzzeile“ manipuliert (so wie ich …).

Ich würde auch mal nachschauen, wie es den mit den Unterschieden zwischen den start.conf.GRUPPE Dateien, die in Verwendung sind und denen in /srv/linbo/examples/ aussieht. Ist da was auffällig?

Man könnte auch mal schauen, ob den die Label richtig auf der PLatte stehen.
Also mal ein linux booten und mit blkid die Labels anschauen.

Und wie ist das? die Clients laufen mit linbo 4.2, aber nicht mehr, wenn sie einmal mit 4.2 gesynct wurden?
Hat man schon verscuht mal einen (gerne auch „defekten“ ) Client mit linbo 4.2 neu zu partitionieren und dann zu syncen? Geht es dann?
Und wurde schon mal mit linbo 4.2 ein neues Image von einem funktionierenden Client erstellt und das dann versucht auf einen anderen zu syncen? Hat das geklappt?

Übrigens: warum besitzen den die Cachpartitionen kein Label?
Bei mir besitzen alle Partitionen ein Label: auch die EFI und die swappartition …
Soe sieht es auch in den Vorlagendateien aus.
Dort sind „root“ und „boot“ übrigens beide ohne führende Slashes eingetragen, wie Sascha es auch angemerkt hat.

LG
Holger

12

Hallo Holger,
Fragen über Fragen :thinking:

Wurde den ein linuxmuster_import_devices nach dem upgrade durchgeführt?

Ja, ich habe auch noch Geräte eingefügt. Das war alles in Ordnung.

Wurden dabei auch die grub.cfg Dateien in /srv/linbo/boot/grub/ neu geschrieben?
Manch einer hat dort ja die „Schutzzeile“ manipuliert (so wie ich …).

Diese Dateien sind alle automatisch erstellt (Richtiges Datum), da habe ich bisher nix reingefingert.

Ich würde auch mal nachschauen, wie es den mit den Unterschieden zwischen den start.conf.GRUPPE Dateien, die in Verwendung sind und denen in /srv/linbo/examples/ aussieht. Ist da was auffällig?

Die einzige Aufälligkeit ist, dass cache, swap und efi keine Labels haben, das werde ich ändern.

Man könnte auch mal schauen, ob den die Label richtig auf der PLatte stehen.
Also mal ein linux booten und mit blkid die Labels anschauen.

Schaue ich morgen, wenn ich physisch vor den Dingern sitze.

Und wie ist das? die Clients laufen mit linbo 4.2, aber nicht mehr, wenn sie einmal mit 4.2 gesynct wurden?

Das war ganz seltsam. Die Rechner liefen eigentlich alle gut. Mir ist nur im Webui aufgefallen, dass die gar nicht synchronisiert haben, der letzte Start mit Sync war vor den Ferien noch mit 7.1
Dann habe ich mir nix Böses gedacht, und mal über das Bios das Netzwerkbooten erzwungen, damit ich überhaupt linbo zu Sehen bekomme und dann mal neu schreiben gewählt, genau so ein PC lief dann ins Leere. Vorher war linbo überhaupt nicht zu sehen, die starteten einfach durch (kommt mir jetzt auch beim Schreiben seltsam vor)
Dann habe ich mal ein Image neu geschrieben, nach der fstab mit Label usw. geschaut (auf einem PC der SATA/BIOS Gruppe) Die aus der SATA Gruppe laufen alle brav mit dem neuen Image.
Jetzt haben dann ein paar von den laufenden UEFI-PCs beim Booten auch dieses Image geholt, waren dann auch tot.
Während der linbo-Synchronisation sah auch alles ganz normal aus.
Jetzt habe ich in der startconf deshalb die Standardaction auf nur Starten gestellt. Die PCs, die noch nicht synchronisiert hatten, funktionieren jetzt noch weiterhin.

Viele Grüße
Johannes

13

Hallo,

also mach mal die führenden slashes in den boot und root Zeilen der efi start.conf weg und mach danach ein import (wichtig).

und wenn du die Label hinzufügst, dann denk dran: die werden auf der PLatte im Client erst realität, wenn sie durch linbo neu partitioniert werden.

LG

Holger

14

Hallo Johannes,
bei mir hat es bei einer Hardwareklasse geholfen, mit der WebUI eine komplett neue Hardwareklasse zu erstellen. Erst dann wollte diese mit Linbo 4.2.
Probier einfach mal das.
LG
Max

15

Hallo Max,
also das Neuerstellen einer Hardwareklasse hat erst mal geholfen. :+1:
Warum das so ist, ist mir aber unklar.
Morgen schaue ich mal noch genauer nach.
Welcher Prozess erstellt eigentlich die UUID ? Linbo beim partitionieren?
Die Fehlermeldung der PCs beim booten ist dann ja vermutlich UUID des PCs, an dem das Image gemacht wurde. Da ich immer mal woanders sitze, steht irgendwo im Log von linbo, an welchem PC das Image geschrieben wurde?

Viele Grüße und vielen Dank
Johannes

16

Hallo Johannes,
eigentlich ist das egal. Ich patche halt mit postsync die /etc/fstab mit den Labels und dann läuft es.
LG
Max

17

Hallo Holger,

wir haben es jetzt erst ausprobiert. Deine Lösung mit den Labels hat geholfen, vielen Dank.

Gruß, Jakob

18

Hallo zusammen,

nach dem Schreiben eines neuen Images (von einem nicht UEFI/nvme-PC aus) und dem Neustart der UEFI PCs ist das Problem wieder da. Nach dem erfolgreichen Sync erscheint nach dem Neustart ein blaues Grub-Fenster, dann geht es nicht weiter, weil hier wieder eine uuid drin steht.
Dieses Grub-Fenster sehe ich sonst nicht.
In der fstab ist keine uuid und die Partitionen haben alle Labels
Deshalb die Frage, wann wird dieses Grub geschrieben, es muss ja wohl vom linbo sein.
Wieso steht dann da eine UUID drin. Oder steht das irgendwo im Image?
Die PCs kann ich leider nicht auf legacy stellen, das Problem wird ja zunehmen, deswegen würde ich gerne dann Ablauf beim booten mit UEFI und linbo verstehen. Gibt es da was zum Lesen dazu?
Eine neue Hardwaregruppe machen hat jetzt auch nicht geholfen.

Viele Grüße
Johannes

19

Hallo zusammen,
beim letzten Image-Schreiben war leider wieder eine fstab drin, in der die Efi-Partition ohne Label drin stand (ist mir ein Rätsel, wie das reinkommt)
Außerdem habe ich warstart=yes aktiviert, das scheint ja im neuen Linbo empfehlenswert zu sein
(Das entnehme ich diesem Artikel , da ist ja genau unser Problem.

Wenn Warmstart aktiviert ist, dann booten auch Images, wo keine Labels fürs efi drin sind.

Viele Grüße
Johannes

20

Hallo Johannes,

warmstart=yes ist veraltet: funktioniert zwar noch, aber sollte nicht mehr verwendet werden.
Außerdem ist das der Default von linbo: wenn nix drin steht, dann macht linbo bei Windows einen Kaltstart und bei linux einen Warmstart.

Was derzeit, bei neuer Hardware und neueren linbo und Linuxkerneln empfohlen wird ist die Option
warmstart=no (auch veraltet).
Der aktuelle Switch heißt

nowarmstart

Einen
yeswarmstart
oder so, gibt es nicht: ist ja das Defaultverhalten.

LG

Holger