Per default wurde da nix gepatcht, ich hab dann zum Testen einfach eine passende fstab in linuxmuster-client/raum/common/etc/fstab gelegt, die ist auch auf der Platte gelandet.
Haenge im initramfs fest, ich schau aber heute da nochmal nach.
Haendisch kann ich /dev/nvme0n1p1 mounten.
hast Du das Paket linuxmuster-client-servertools aus dem Testing-Repo installiert?
Damit müsste die automatische Anpassung der /etc/fstab erfolgreich durchlaufen…
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.
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.
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?
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 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
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.
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.
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?
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).
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
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.
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.