Linuxclient from Scratch: Notwendige und hilfreiche Anpassungen

Clientpflege Linuxclient
5

In der fstab kannst Du das so eintragen, das ist nicht das Problem. Ob es mit Linbo geht, wollte ich wissen!

6

Eine Sache, die ich bisher noch nicht verstanden habe ist, wie ihr das mit den UUIDs hinbekommt. Diese Schritte

  • /etc/default/grub → GRUB_DISABLE_LINUX_UUID=true
  • /etc/fstab → UUIDs ersetzen mit /dev/sdaX

reichen irgendwie nicht aus oder ich mache es falsch :frowning: In der grub-config sind immer noch UUIDs drin, z.B. so:

search --no-floppy --fs-uuid --set=root 7a6386b4-f84b-4953-9985-67ebee82876d

Ich bekomme die nur weg, wenn ich manuell die grub Dateien editiere (siehe hier).

Sind bei euch auch noch solche Zeilen in der grub-config oder wie habt ihr dieses Problem gelöst? Wenn ich ein solches Image klonen möchte, gehen immer einige Sekunden beim Booten verloren, weil er auf ein Gerät wartet, das nicht da ist.

Oder liegt es daran, dass ich nur die root und swap partition in der /etc/fstab habe? Müssen da zwingend alle Partition (also cache, daten evtl. efi) mit rein?

Danke für eure Hilfe!
Stephan

7

Ja, geht.

VG, Thomas

8

Hallo Stephan,

  • |/etc/default/grub| → |GRUB_DISABLE_LINUX_UUID=true|

hiernach noch ein
update-grub

dann sollte das auch die grubdateien entsprechend anpassen.

LG

Holger

9

Das ist schon klar, macht es aber nicht :slight_smile:

10

Hallo,

um ein UUID-freies Image zubekommen, sind folgende Schritte nötig:

  • /etc/default/grub → GRUB_DISABLE_LINUX_UUID=true

  • /etc/fstab → UUIDs ersetzen mit /dev/sdaX

  • sudo update-grub→ damit sind immer noch UUIDs im Image, die beim Booten auf anderen Rechner zu Fehlermeldungen führen (können).

  • Wenn man wirklich alle UUIDs weghaben möchte, muss man die Datei /usr/share/grub/grub-mkconfig_lib editieren (man sollte wissen, was man macht!) und nach dieser Anleitung anpassen.

  • bei mir kam es zu einer ca. 30s Bootzeitverzögerung, weil der Kernel auf ein Gerät gewartet hat, was nicht da war. Das kann man folgendermaßen abschalten: Die Datei /etc/initramfs-tools/conf.d/resume erstellen und RESUME=none einfügen.

  • danach sudo update-initramfs -u

Jetzt sollten alle UUIDs verschwunden sein und die Bootzeit „kurzmöglichst“.

vG Stephan

11

Hallo Stephan,

Das bitte nicht ausführen. Die Info ist veraltet.:

Die Reihenfolge machts, dann sind die UUIDs aus dem Bootvorgang raus. Vor einem update-grub die /etc/fstab anpassen. Also:

  • /etc/default/grub → GRUB_DISABLE_LINUX_UUID=true
  • /etc/fstab → UUIDs ersetzen mit /dev/sdaX
  • sudo update-grub
  • Die Datei /etc/initramfs-tools/conf.d/resume erstellen und RESUME=none oder wenn man Suspend-To-Disk haben möchte RESUME=/dev/sdaX die SWAP Partition eintragen
  • danach sudo update-initramfs -u

Viele Grüße
Klaus

1 „Gefällt mir“
12

Danke, Klaus!

13

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

14

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

15

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

16

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

17

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

18

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

19

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

20

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

21

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“
22

@juergen hatte hier auch etwas dazu geschrieben:

23

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

vG Stephan

24

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“