Linuxclient from Scratch: Notwendige und hilfreiche Anpassungen

Danke, Klaus!

Hallo @Tobias,

bezüglich unserer Diskussion auf github zum Thema „Label“. Meintest Du diesen Thread hier?

Für grub braucht man die Label ja nicht, weil es ausreicht, wenn GRUB_DISABLE_LINUX_UUID=true in /etc/default/grub gesetzt ist. Ein update-grub liest ja dann die /etc/fstab aus. Wenn dort das Rootdevice statt UUIDs stehen, dann passt ja alles. So wie ich es sehe, gibt es für die Änderung von /etc/default/grub und update-grub noch kein Postsync Skript?

Für suspend/resume wäre ein postsync praktisch welcher folgendes macht:
Setze /etc/initramfs-tools/conf.d/resume auf RESUME=LABEL=swap und führe update-initramfs -u aus. Gibt es im Moment auch noch nicht als Postsync Skript.

Viele Grüße
Klaus

Hi @garblixa,

Nein, allgemeiner die Diskussion um labels, die irgendwann im letzten JAhr in Linbo eingebaut wurden. Ich habe selbst mich nicht wirklich drum geschert, warum und wie die Labels gesetzt werden. daher kann ich auch nicht viel dazu sagen.

Das finde ich auch nicht nötig: Jemand, der ein neues Image von Grund auf macht, wird die Anpassungen von hand machen wollen - einmalig. Das ist ja overkill, im Postsync zu machen. Das ist wie wenn du alle Ideen, die @zefanja hier postet und die es zu HAuf für ältere Cloops im Anwenderwiki gibt per postsync machen wolltest: kann man schon (bedingt), aber was bringt das?

Je länger ich mit postsync vs. Skripten im laufenden CLient arbeite, desto mehr verwende ich postsync für den m.M. nach falschen Zweck: z.B. zur Dokumentation, was ich gemacht habe.

Meines Erachtens sind LINBO + postsync dafür da, ein vollständiges Cloop in ein auf den host, raum, tageszeit, lebensumstände, etc. angepasstes Cloop zu verwandeln.
Änderungen, die alle betreffen: updates, installationen, deinstallationen, konfigurationen,… könnte man auch „von“ außen über postsync in ein cloop bringen, aber sobald man mal ein neues Image macht, sind die Änderungen ja drin, man hat ein neues vollständiges Cloop, welches die „von außen“ eingebrachten Änderungen ja nicht mehr braucht.

Das ist was anderes. Es könnte mit einem Cloop zwei oder mehr WÜnsche geben, was in RESUME= stehen sollte. Das update-initramfs -u wird wohl nicht so ohne weiteres in LINBO gehen… LINBO würde damit nicht nur das root-Filesystem des Clients patchen wollen, sondern auch das gezippte „Filesystem“ initrd.img.
Das würde ich erst mal abwarten. Es hat m.Wissens noch niemand den Anwendungsfall gehabt…

VG, Tobias

Hallo Tobias,

Das ist vollkommen richtig und ich hatte das so noch nicht betrachtet. Man merkt wohl doch, daß ich hier noch recht „neu“ bin :slight_smile:

Ein paar Posts gibt es dazu schon. Aber wenn ich Deinen Gedanken oben auch hier anwende, dann ist das auch eine individuelle Sache. z.B. für einen Raum mit (Lehrer) Laptops. Also auch nicht generell für alle Images. Es könnte evtl. aber dokumentiert werden, daß man hier mit dem Label „swap“ arbeiten kann, wenn man das in LINBO so gesetzt hat.

Danke für die Klärung!

Viele Grüße
Klaus

Hallo Klaus,

Das funktioniert bei mir nicht. Ich habe mich genau an die Schritte gehalten, aber in der /boot/grub/grub.cfg steht immernoch an vielen Stellen die UUID drin! Der friscxh gesyncte Client startet aber spannernderweise trotzdem, nur mit einer Fehlermeldung am Anfang, die ich gerne weghätte.

@zefanja: Hast du die Zeilen von JustPaste.it - Share Text & Images the Easy Way in der grub-mkconfig_lib ab Zeile 169 einfach hinzugefügt oder etwas ersetzt? Und danach dann ein update-grub?

Grüße,
Stefan

Ich habe diesen Block gesucht:

  if fs_uuid="`"${grub_probe}" --device $@ --target=fs_uuid 2> /dev/null`" ; th>
    hints="`"${grub_probe}" --device $@ --target=hints_string 2> /dev/null`" ||>
    echo "if [ x\$feature_platform_search_hint = xy ]; then"
    echo "  search --no-floppy --fs-uuid --set=root ${hints} ${fs_uuid}"
    echo "else"
    echo "  search --no-floppy --fs-uuid --set=root ${fs_uuid}"
    echo "fi"
  fi

und darüber diese Zeile eingefügt:

if [ "x${GRUB_DISABLE_LINUX_UUID}" != "xtrue" ] ; then

und nach dem Block

fi

Das blöde ist, dass man das im Prinzip nach jedem Grub-Update und vor jeder Imageerstellung kontrollieren muss.

vG Stephan

Hallo Stephan,

ok, danke, hab’s auch geblickt. Und so häufig passe ich die Images nicht an. 5 Fundstellen gibt es jetzt noch in der grub.cfg für die UUID, aber keine Fehlermeldungen mehr beim Booten.

Grüße,
Stefan

Hallo Stephan,

[quote=„lessi, post:16, topic:5735, full:true“]

Welche Fehlermeldung?
Ich habe erst gestern einen Linux Mint 20 Client mit den linuxmuster-client-servertools installiert. Der Client konnte bei mir nicht booten, weil es keine korrekte grub Konfiguration gab. Aber ich habe genau die Schritte oben ausgeführt und da gibt es bei mir keine Fehlermeldungen mehr.

Das ist nicht notwendig.

Viele Grüße
Klaus

Was gibt bei dir sudo grub-mkconfig | grep -i uuid aus? Im Standard-Ubuntu gibt es da einige Einträge mit search.... Wegen dieser Einträge gibt es eine Fehlermeldung beim Booten wegen nicht gefundener UUID.

vG Stephan

Hallo Stephan,

ja, stimmt da hast Du doch Recht. Auch bei mir sind die uuid Einträge vorhanden. Bei mir ist hier nur kein Fehler aufgetaucht, da die Client grub Konfiguration bei mir nicht ausgewertet wurde.

Grund:
In meiner start.conf habe ich die Einträge:

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

Heißt, linbo bootet direkt den Kernel/Initrd des Clients und es kommt nicht zu dem Fehler. Lasse ich die Einträge weg, dann bootet Linbo den grub des Clients und ich bekomme denselben Fehler bzw. Verzögerung wie ihr auch. Ich hoffe ich interpretiere das richtig.

@lessi
Ich nehme also alles aus meinem Post oben zurück und kann bestätigen, daß es die Verzögerung gibt.

Viele Grüße
Klaus

1 „Gefällt mir“

@juergen hatte hier auch etwas dazu geschrieben:

Dann sollte das ja eigentlich fast Standard sein, denn es erleichtert diesen Hickhack mit den UUIDs ungemein.

vG Stephan

Hallo Stephan,

heute nochmal vor Ort mit einem Terra 1516 ausprobiert. Der kann nur noch UEFI Boot und da klappt das auch so.
Hier die start.conf meiner Linux Mint 20 Installation:

[LINBO]
Server = 10.0.0.1
Group = linuxmint20
Cache = /dev/sda3
RootTimeout = 600
AutoPartition = no
AutoFormat = no
AutoInitCache = no
DownloadType = torrent
BackgroundFontColor = white
ConsoleFontColorStdout = lightgreen
ConsoleFontColorStderr = orange
SystemType = efi64
KernelOptions = quiet splash

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

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

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

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

[OS]
Name = Linux Mint
Version = 20
Description = Ubuntu 18.04
IconName = mint.png
Image = 
BaseImage = mint20t.cloop
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 = 5
DefaultAction = start
RestoreOpsiState = no
ForceOpsiSetup = 
Hidden = yes

Viele Grüße
Klaus

1 „Gefällt mir“

Hi zusammen,

Entschuldigt bitte, dass ich diesen alten Thread nochmal hoch hole. Ich habe allerdings das gleiche Problem wie hier beschrieben:

Und auch das hier:

Ließe sich das nicht in das offizielle Paket einbauen, dann muss das nicht jeder selbst machen?

VG, Dorian

Hallo Dorian,

ja, das ließe sich machen.
Derzeit hängt die Entwicklung des linuxmuster-client-adsso aber etwas in der Luft: wir haben nicht wirklich jemand, der das so richtig weiter entwickelt.
Suche nach einer Zuständigen Person laufen schon lange, sind aber bisher wenig fruchtbar :frowning:
LG

Holger

Hi Holger,

Das hab ich mir schon fast gedacht :confused:
Schade eigentlich, zumal das ja schon ein recht essentieller Teil von lmn ist.

Ich hab leider von dem ganzen Domänenjoin und was dazu gehört nicht wirklich viel Ahnung, aber wer hat das denn früher gemacht? Von ironiemix hab ich das ein oder Andere gelesen, aber der ist wohl raus…

VG, Dorian

Hallo Dorian,

Ich habe nicht richtig verstanden, was du brauchst : nur die Bookmarks leeren ?
Adsso ist so gebaut, dass es ermöglicht, Skripte als USER sowohl als Root bei der Anmeldung ausführen zu lassen. Man muss nur entsprechende Skripte in /etc/linuxmuster-client/login.d/ oder in /etc/linuxmuster-client/login-as-root.d/ stellen.

Da es verschiedene Desktop mit verschiedene Konfigdateien in Linux gibt, glaube ich nicht dass es gut wäre die Bookmarksteuerung in dem offiziellen Paket reinzuschreiben. Es wäre besser, dass jeder alle diese eigene Skripte in einem CommunityWiki organisiert zu stellen.

Im offiziellen Paket würde ich lieber ein Quotaskript sehen. Ich habe es schon irgendwo geschrieben, ich muss suchen.

Wegen die „-entfernt“ Ordner, wenn ich die Problematik richtig verstanden habe, muss man nur die entsprechende Pfade in /etc/linuxmuster-client/links.conf auskommentieren ( kommentieren ? mensch, ich habe es schon 1000 mal Holger gefragt welcher Wort ich soll nutzen … ich weiß nie … ).

Gruß

Arnaud

Das ist ein guter Punkt, aber man könnte ja auch einfach automatisch erkennen, dass es Ubuntu ist. Auf jeden Fall wäre bessere Dokumentation an der Stelle gut.

Das stimmt, aber das ist keine saubere Lösung, da das beim nächsten Update wieder überschrieben wird.

Und es gibt ja noch genug andere Probleme, siehe die GitHun Issues.
Es braucht auf kurz oder lang einfach wieder jemanden, der sich darum kümmert…

VG, Dorian

Ich spreche nicht von dem Betriebsystem, sondern von dem Desktop ( KDE, Mate, Cinnamon, XFCE, … ). Viele verwenden schon die Datei .config/gtk-3.0/bookmarks.

Beim Update sollte apt fragen, ob diese Konfigurationsdatei überschreiben sein soll ( habe ich in diesem Repo nicht überprüft, ob es der Fall ist ). Dass der setup es überschreibt hatte ich nicht gesehen.

Gruß

Arnaud

Hallo Arnaud,

„auskommentieren“ war genau richtig.
Das bezeichnet den Vorgang, dass man einen Hashtag an den Zeilenanfang macht, damit der Rest der Zeile nicht mehr beachtet wird.

LG

Holger