Hallo Harry,
hast Du das Paket linuxmuster-client-servertools aus dem Testing-Repo installiert?
Damit müsste die automatische Anpassung der /etc/fstab erfolgreich durchlaufen…
Viele Grüße
Jürgen
testing und stable auf einem angehenden Produktivsystem zu mischen war bisher eigentlich immer der Anfang vom Niedergang - ist das mittlerweile anders?
Ich will nach den Ferien die 7er mit einem neuen Client ausrollen, bis dahin ist noch viel zu tun. Parallel laeuft die 6er dann so langsam aus.
Gruss Harry
Hallo Harry,
testing und stable auf einem angehenden Produktivsystem zu mischen war
bisher eigentlich immer der Anfang vom Niedergang - ist das mittlerweile
anders?
ich misch das seit vielen Jahren. „Niedergang“ hatte ich nioch nicht 
Du kannst ja das testing repo rein nehmen, dann apt update
apt install linuxmuster-client-servertools
und dann testing wieder auskommentieren: dann wird nur das servertools
Paket auf testing gehoben.
LG
Holger
Ich hatte da regelmaessig bei Debian Probleme mit den testing-PHP-Paketen, die sind mir alle irgendwann auf die Fuesse gefallen, die Katastrophe hat ja bekanntlich alle Zeit der Welt.
Ja so sollte das tun, sonst schiebt ja (wenn testing zu stable wird) der testing-Pfad gleich wieder testing-Pakete hinterher und man kommt da nie raus.
Die Fehlersuche wird aber schwieriger, da wir hier bei Problemen verschiedene Versionsnummern benutzen, man vergisst ja auch leicht, dass da was aus einem anderen Ast Probleme bereitet.
Eigentlich will ich ein neues System auch nicht wirklich gleich mit testing-Paketen infiltrieren, vor allem fuer ein einziges Cloop, welches ja, wenn ich den Thread richtig verstanden habe, demnaechst offiziell hier aufschlaegt?
Gruss Harry
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 
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 ! 
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
Ich probiere nun mal verschiedene Kernel-Parameter aus.
VG
Chris