Linux Mint 20 Musterclient (vanilla): Cloop Package für linuxmuster-client-servertools

Hallo Harry,

das Paket ist nur in testing, weil noch ich noch nicht genug Rückmeldung bekommen habe, außerdem müssen wir (@garblixa und ich) dann noch was am fstab + swap Konzept schrauben, weil das nicht in den LInbo-core soll.

außerdem sollten wir noch festerzurren, was hier in die meta-Datei rein soll.

Wenn du nicht tester sein willst, einfach noch warten :slight_smile:

p.s. hat jemand jetzt probleme mit dem momentanen servertools paket v0.9e gesehen?

Hallo Tobias,
nein keine Probleme, nur ein paar Hinweise - siehe hier:
Lmn7-testing: linuxmuster-client-servertools v0.9e
VG
Chris

Hallo Jürgen,
ich habe das cloop nun via servertools heruntergealden, den Client eingebunden und auf einem echten Client (Ĺaptop x60) ausgerollt.
Nach der Synchronisation tritt das Problem auf, dass mint20 nicht startet mit dem Hinweis:
error no such device: d8cff476-6e4a-4a3a-a0b6-ba4bb308ac78

Ideen? Bei Linbo nur an den Kerneloptionen mal drehen ?
VG
Chris

Hallo Chris,

in habe das Problem lindern können, indem ich in der Datei /etc/default/grub die Zeile

GRUB_DISABLE_LINUX_UUID=true

hinzugefügt und anschließend ein

update-grub

ausgeführt haben. Leider habe ich aber immer noch ein Problem, es kommt in grub die Fehlermeldung „Press any key to continue“. drückt man eine Taste, bootet er tatsächlich auch.

Grüße,
Sven

Hallo Sven,
danke für den Hinweis.
Ich habe GRUB_DISABLE … und update-grub in der start.conf in der Append-Zeile für den Start des Mint OS eingetragen und nochmals import-devices ausgeführt.
Auf dem Server finden sich unter /srv/linbo/boot/grub nun die cfg für die HWK. IN DER SICH O.G Werte wiederfinden.

Beim Sync sehe ich nun auch, dass diese Option aufgerufen wird, allerdings ohne Erfolg.
Im linbo.log des Laptops sehe ich, dass die Labels korrekt geschrieben werden und dann eine UUID angegeben wird.

Vermutlich meintest Du das aber anders?
VG
Chris

Hallo Chris,

error no such device: d8cff476-6e4a-4a3a-a0b6-ba4bb308ac78 |

und/oder die fstab kontrollieren.

LG

Holger

Hallo Sven,

ausgeführt haben. Leider habe ich aber immer noch ein Problem, es kommt
in grub die Fehlermeldung „Press any key to continue“. drückt man eine
Taste, bootet er tatsächlich auch.

ist möglicherweise der Eintrg der swappartition auch noch in der fstab
falsch?

LG

Holger

Hallo Holger,
meinst Du die /etc/fstab im postsync ?
Was genau sollte dort stehen ?
VG
Chris

Hallo Chris,

meinst Du die /etc/fstab im postsync ?

wenn es da eine gibt, dann ja.

Was genau sollte dort stehen ?

das kommt darauf an, wie das gepatched wird.
Das sit gerade „im Fluss“ deswegen kann ich das nciht so genau sagen.
Aber du kannst, unabhängig vom Patchen, das richtige rein schreiben:
also z.B.

/dev/sda1 für root
und
/dev/sda4 für swap
je nach dem wo das bei dir liegt.

oder mit Labeln.

Da bei mir root und swap bei allen HWKs immer an der gleichen Stelle
liegen (warum auch nciht) steht da bei mir immer das gleiche drin.
Einzige Abweichung: die nvme Clients haben eine eigene fstab (natürlich).

LG

Holger

Hallo Holger,
ich habe im postsync der HWK die Datei /etc/fstab so angepasst, dass die korrekten Partitionen eingehangen werden.
Leider bleibt der Fehler gleich und mint startet nicht.
VG
Chris

Hallo,
ich habe nun mal eine VM unter Proxmox erstellt und das Muster-Cloop für Mint via Linbo angewendet, keinerlei Änderungen der fstab, oder von grub.
Siehe da, Mint 20 bootet nach dem Sync ohne Probleme ! :rofl:
VG
Chris

Hallo Jürgen,

ist dieses Script im Paket, das auf dem Download Server liegt bereits angepasst ?
Wie sollte dieses aussehen ?
VG
Chris

Hallo Chris,

mit dem Skript 03-lcst-fix-fstab aus dem Paket linuxmuster-client-servertools in Version 0.9e wird die /etc/fstab korrekt angepasst. Das habe ich auf verschiedenen Systemen und unterschiedlicher Partitionierung geprüft.

Das Problem muss an anderer Stelle liegen. Irgendwie scheint linbo die /boot/grub/grub.cfg von der Installation zu laden. Dort steht auch die originale UUID von der Partition bei der Installation.

Vielleicht muss ja doch dieser Patch angewandt werden. Das hat jedenfalls bei meinem ursprünglichen Mint 20 Vanilla Client ganz gut geklappt.

Viele Grüße
Jürgen

Hallo @Sven,

vor der Erstellung des cloop packages habe ich das Kommentarzeichen vor dem Eintrag GRUB_DISABLE_LINUX_UUID=true in der /etc/default/grub entfernt und anschließend update-grub ausgeführt.

Bei Dir müssten jetzt zwei gleiche Einträge in der /etc/default/grub stehen.

Viele Grüße
Jürgen

Hallo Chris, hallo Sven,

ich habs!

Linbo versucht, den Linux-Kernel (vmlinuz) unter / zu finden, allerdings befindet der sich im Verzeichnis /boot. Das schlägt fehl und deshalb sucht Linbo dann die grub.cfg von der OS-Installation und lässt dann grub das Betriebssystem mit dieser Konfiguration laden.
Weil dort aber noch die Einträge von der Installation drin stehen inkl. der UUID der root-Partition, kann grub damit nichts anfangen und bricht dann mit der Fehlermeldung

das Starten des Betriebssystems ab.

Lösung:
Man muss in der start.conf den Speicherort von vmlinuz und initrd.img korrekt angeben:
WebUI -> 20200721_mint20_base (oder eigene start.conf) -> Reiter Partitionen -> Stiftsymbol in Partition Linux Mint -> Reiter OS -> Button ERWEITERT

Nach dem Speichern noch einmal linuxmuster-import-devices ausführen, und Client neu starten.

Viele Grüße
Jürgen

Hallo Jürgen,
vielen Dank für Deine Antwort.
Ich habe dies nun so umgesetzt.
Der Client, der als VM unter Proxmox läuft mit identischer start.conf bootet weiterhin korrekt.
Der „echte“ Client (Laptop x60) startet nach der Synchronisation von Mint 20 leider nicht, sondern friert im Bildschirm ein, aber die bisherige Fehlermeldung habe ich auch nicht mehr.
Ich habe in der VM den Client mal aktualisiert, so dass nun der Kernel 5.4.0.42 installiert ist. Das ändert am Boot-Verhalten des Laptop aber leider bislang auch nichts.
OK, dann kann ich jetzt aber nach einem anderen Fehler suchen :slight_smile:
Ich probiere nun mal verschiedene Kernel-Parameter aus.
VG
Chris

Hallo Jürgen,
vorläufiger Zwischenstand bei den Test mit verschiedenen Einstellungen und unterschiedlicher echter Hardware:

a) Ein weiterer Laptop (lenovo sl510) funktionierte sofort, wenn ich die o.g. Anpassungen beim OS in der start.conf eintrage (/boot/vmlinuz & /boot/initrd.img).

b) Ein ThinkCentre M15q mit NVMe und Radon Grafik, hatte mit Mint Probleme. Einstellungen wie unter a) - nach dem Sync versucht Linbo Mint 20 zu starten und landete dann aber immer wieder im Linbo Menü.

c) Ein Fujitsi P758 mit SSD: Hier startete Mint ohne Probleme.

Auf dem funktionierenden Laptop habe ich die Pakete aktualisiert und erhalte bei der Aktualisierung der Quellen folgende Fehlermeldung:
GPG-Fehler: https://archive.linuxmuster.net … is in unsupported formate
Ich gehe mal davon aus, dass dies bekannt ist, oder ?
Entspricht das dieser Beobachtung: V7 Repo not signed - dort ist ja auch ein vorübergehender Fix erläutert.

Allerdings steht in Deinem Cloop bereits dieser Fix in der Datei /etc/apt/apt.conf.d/99-linuxmuster - die Fehlermeldung kommt dennoch.
Will ich dann mit linuxmuster-cloop.turnkey der Domäne beitreten, erhalte ich hierbei zusätzlich die Rückfrage für sshd, ob die Version des Systembetreuers … Belasse ich die alte oder ersetze ich diese durch die neue Version erhalte ich in beiden Fällen die Fehlermeldung, dass /var/lib/samba/sysvol/ nicht eingehangen werden kann und die Datei cacert.pem auch nicht gefunden wird.

Mmh, mal sehen …

VG
Chris

Hallo Chris,

Ist das ein Rechner mit aktiviertem UEFI-Bios? Wenn ja, könnte es daran liegen, dass das UEFI-Bios den Eintrag für Linux Mint in der EFI-Partition ignoriert. Ein Bios-Update kann in diesem Fall helfen (muss es aber nicht). Wenn das nicht hilft, auf Legacy-Bios umstellen.

Ja, das ist bekannt, der Workaround aus diesem Post steht in der Datei /etc/apt/apt.conf.d/99-linuxmuster. Schau Die Fehlermeldung mal genauer an. Ich meine, davor steht ein gelbes W: für Warning, deshalb bricht apt update auch nicht ab.

Bitte die alte belassen, sonst kann es sein, dass der Remote-Zugriff auf den Client per ssh vom Server aus nicht mehr funktioniert!

Das hört sich ganz danach an, als ob der Postsync nicht durchgelaufen ist.
Prüfe mal, ob auf dem Server im Verzeichnis /srv/linbo für Deine Hardwareklasse das generische Postsync-Skript existiert (HWK.cloop.postsync). Wenn nicht, kopiere entsprechend das Postsync-Skript, das in meinem Cloop Package dabei war (HWK bitte durch den Namen der Hardwareklasse ersetzen):

cp /srv/linbo/20200721_mint20_base.cloop.postsync /srv/linbo/HWK.cloop.postsync

Wenn der Rechner- und Servername sowie IP-Adressen in der Datei /etc/hosts nicht stimmen, schlägt der Domänenbeitritt fehl.

Viele Grüße
Jürgen

Hallo Jürgen,
danke für die Hinweise. Der PC mit UEFI und NVME: Hier habe ich zwar UEFI only im BIOS eingestellt. Linbo bootet einwandfrei, es ergeben sich nur nach dem Sync die Startprobleme. Legacy probiere ich mit diesem noch.
Mit dem Fujitsu PC ist es so, dass ich ein postsync für die HWK habe und ich sehe, dass beim Sync das ### postsync ende ### erreicht wird. Dieser wird also angewendet.
Im linbo.log des PC finde ich den Hinweis, dass sda3 und sda4 ein identisches Label aufweisen, was in der start.conf definitiv nicht so ist. Dort findet sich zudem der Hinweis: efibootmgr Boot 0003 same label grub. sda3 ist bei mir der cache.

Der Domänenbeitritt scheitert dennoch. Ich habe dann die Zeiten Server / Client verglichen. Hier gibt es 1 Minute Abweichung - deutlich zu viel :grinning: Welche Vorgehen hast Du auf dem Client genutzt, um die Zeiten anzugleichen ?

Ich habe mal auf Client und Server timedatectl status geprüft und es ergibt der Unterschied von einer Minute. In der Konfigurationsdatei /etc/systemd/timesyncd.conf ist der Server 10.0.0.1 korrekt angegeben. Allerdings besagt o.g. Status, dass kein Sync der Zeit auf dem Client ausgeführt wurde.
Ich habe dann mit
timedatectl set-ntp 0 #deaktivieren
timedatectl set-ntp 1 #aktivieren

Die Zeitsynchronisation initiiert, danach stimmten beide Zeiten.
Allerdings scheitert danach immer noch der Domänenbeitritt
VG
Chris

VG
Chris

Hallo Chris,

ist. Dort findet sich zudem der Hinweis: efibootmgr Boot 0003 same label
grub. sda3 ist bei mir der cache.

bitte mach mal folgendes um das smae label Problem zu beheben:

  1. auf der Festplatte alle Partitionen löschen (entweder über
    linbo-remote oder per Live USB Stick)
  2. reboot!
  3. linbo booten und erneut partitionieren

LG

Holger