Linuxclient: No root device specified

Clientpflege linbo
,
1

Hallo,

ich hatte das Problem schonmal in einem anderen Thread beschrieben, das eigentliche Problem dort wurde allerdings gelöst, deswegen eröffne ich mit dem neuen Problem auch einen neuen Thread.

Wir nutzen auf dem Server die LMNv7 und auf den Clients den Linuxclient. Außerdem haben wir Grub bei uns über die GRUPPE.cfg so eingestellt, dass standardmäßig nicht ins LINBO gebootet wird, sondern direkt das System:

set default=1
set timeout=2
set fallback=1

Damit startet unser Linuxclient problemlos direkt aus Grub heraus. Bootet man allerdings LINBO und versucht daraus das System zu starten erscheint der Fehler

No root device specified.

d.h. meiner Ansicht nach wird da von LINBO wohl was falsch in den Bootsektor geschrieben.

Die start.conf.GRUPPE sieht so aus:

[LINBO]
Cache = /dev/sda2
Server = 10.16.1.1
Group = dhgneu
SystemType = bios64
RootTimeout = 600
AutoPartition = no
AutoFormat = no
AutoInitCache = no
DownloadType = rsync
BackgroundFontColor = white
ConsoleFontColorStdout = lightGreen
ConsoleFontColorStderr = orange
KernelOptions = quiet splash nomodeset i915.alpha_support=1

[Partition]
Dev = /dev/sda1
Size = 40G
Id = 83
FSType = ext3
Bootable = yes
Label = Mint

[Partition]
Dev = /dev/sda2
Size =
Id = 83
FSType = ext3
Bootable = no
Label = cache

[OS]
Name = Mint
Version =
Description =
IconName = mint.png
Image =
BaseImage = amgdhgmint.cloop
Boot = /dev/sda1
Root = /dev/sda1
Kernel = vmlinuz
Initrd = initrd.img
Append = ro splash net.ifnames=0 biosdevname=0
StartEnabled = yes
SyncEnabled = yes
NewEnabled = yes
Hidden = no
Autostart = yes
AutostartTimeout = 10
DefaultAction = start

Also Boot- und Root-Device sind im [OS]-Abschnitt hinterlegt, werden aber irgendwie von LINBO nicht richtig geschrieben…

Das ist insbesondere dann problematisch, wenn wir ein neues Image verteilen, weil dann wird automatisch aus LINBO heraus auch das System gestartet wird und dann entsprechend hängen bleibt.

Hat da jemand einen Tipp, woran das liegen könnte?

Schonmal Danke im Voraus
Alex

2

Hallo Alex,

gib für die Cache-Partition mal einen Wert für „Size“ an. Hinterher import_workstations, oder linuxmuster_import_devices (da bin ich nicht ganz sicher ob der Befehl richtig geschrieben ist) nicht vergessen.

Die Cache-Partition als „Bootable“ setzen schadet auch nichts.

Warum überträgst Du die Images per rsync und nicht per torrent oder multicast.

Gruß

Alois

3

Hallo Alex,

Probiere mal bitte für Kernel und Initrd folgendes aus:

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

VG, Dorian

4

Hallo Dorian,

sehr cool, das funktioniert! Vielen Dank!

Hallo Alois,

Wir haben halt unterschiedlich große Festplatten in den Rechner drin, und wenn keine Größe angegeben wird, wird ja automatisch der restliche Speicherplatz verwendet. Oder hätte das sonst noch Vorteile, eine fixe Größe anzugeben?

Gibt’s da Vorteile?

Unter der v6.2 hatten wir torrent verwendet, als wir in den letzten Sommerferien auf v7 umgestellt hatten, hat das nicht funktioniert, es wurde einfach gar nichts geladen. Deshalb hatten wir damals einfach auf rsync umgestellt und seither so belassen.

Grade aber nochmal getestet, torrent funktioniert wieder :sweat_smile: Keine Ahnung, was damals los war…

Was ist empfehlenswerter: torrent oder multicast? (Wir haben bis zu den Geräten 1GBit-Verkabelung, zwischen den Switchen teilweise auch 10GBit.)

Danke und Grüße
Alex

5

Hallo Alex,

torrent ist die Voreinstellung bei LMN. Ich habe jahrelang wo immer möglich multicast genommen, weil es viel schneller ist. Allerdings bedarf multicast einer gründlichen Einstellung der Switches.

Ich habs mal so und mal so. Beides funktioniert.

Es gibt Fälle da gibt es Probleme, wenn keine Größe angegeben ist.

Gruß

Alois

6

Hallo Alois,

Wir haben hier ein komplettes UniFi-Netzwerk, da wäre die Einstellung wohl recht schnell erledigt. Da aber die Übertragung von dem 8GB-Image sowieso zügig geht und das eigentliche Schreiben des Images auf die Festplatte länger dauert, spielt das wohl keine so große Rolle mehr. Ich lass das mal bei Torrent, danke aber für den Hinweis.

Okay, hab’s jetzt mal auf die kleinste Festplatte (120GB) angepasst (also 80GB Cache-Partition). Schadet ja eigentlich auch nicht, weil das System ja sowieso festgelegt ist und ob die Cache-Partition jetzt noch größer ist, spielt ja keine Rolle.

Dankeschön für die Hinweise!
Alex

7

Hallo Alex,

8G dauern mit Multicast bei einem Gigabit-Netzwerk und SSD-Festplatten schätzungsweise weniger als zwei Minuten.

Mit SSD’s sollte das Schreiben auf die Festplatte ähnlich schnell gehen.

Gruß

Alois

8

Hallo Alois,

Mit Torrent sind das bei uns ca. 3 bis max. 4 Minuten.

Und das ist auch äußerst seltsam bei uns: das Synchronisieren des Images auf die Festplatte dauert meistens ca. 20 Minuten :grimacing: Und wir haben überall SSDs in den PCs/Laptops.

Ebenfalls etwas komisch: ich habe inzwischen das neue linuxmuster-linbo-gui7 installiert, bis gestern habe ich davon aber noch nichts gesehen, es wurde mir immer das alte GUI angezeigt. Als ich gestern auf 10 Laptops (alle identische Hardware, selbe Gerätegruppe, selbes Image, selbe Konfiguration) das neue Image installiert habe wurde auf einem einzigen Laptop das neue GUI angezeigt, auf allen anderen das alte…
Interessant war auch, dass auf diesem einen Rechner, das Synchronisieren des Images wirklich nur wenige Minuten (um genau zu sein 6 Minuten) gedauert hat, also so wie man es bei einer SSD erwarten würde. Ob das allerdings zusammenhängt, glaube ich eher nicht.

Aber vielleicht hat dazu ja auch noch jemand einen Tipp.

Grüße
Alex

9

Hallo Alex,

SSD nicht gleich SSD: die einen sind per SATA Angebunden die andern per PCIe (auch NVME genannt).
Zweitere haben deutlich höhere IO Raten, was man beim Syncen merkt.

Dass die neue GUI auf den alten Client nicht ankommt ist seltsam: das war bei mir nirgendwo so.
Haben die Cleints beim Booten schon Verbindung zum Server?
Kommen Meldungen beim linbo boot?
Schau auch mal in die logs.
Wurde die grub.cfg der alten Cleints neu erstellt oder ist die managed by linuxmusterzeile manipuliert?

LG

Holger

10

Hallo Holger,

ja, das ist schon klar, das sind alles SATA-SSDs und auch da gibt’s große Unterschiede. Hab die Platten auch mal mit gemessen (ohne Cache), da wird mir eine Lesegeschwindigkeit von knapp 300MB/s und eine Schreibgeschwindigkeit von ca. 250MB angezeigt. Das Image hat entpackt ca. 25GB Größe, damit sollte das Image eigentlich in grob 2 Minuten auch auf der Platte sein. Klar, netto-Geschwindigkeit ist nochmal etwas drunter, aber Faktor 10 (da es 20Minuten dauert) ist dann doch etwas viel.

Interessanterweise ist das auch nach einer Formatierung über LINBO noch so…

Davon gehe ich aus, da ja auch die jeweils aktuelle grub-Konfiguration geladen wird.

Worauf müsste ich hier achten? Ich habe gerade mal die Logdaten verglichen, so auf Anhieb ist mir da kein Unterschied aufgefallen…

Wurde durch linuxmuster-import-devices neu erstellt (davor auch ein update-linbofs)

Grüße
Alex

11

Hallo Alex,

Vorsicht: IO ungleich SChreibgeschwindigkeit bei großen Dateien.
So eine Betriebsysteminstallation besteht aus tausenden kleinen Dateien: da wird die IO Leistung wichtig, nicht das „am Stück schreiben“ was du gemessen hast.

LG

Holger

12

Hallo Holger,

ah, ich dachte, das Image würde blockweise nicht dateiweise auf die Festplatte geschrieben, und nur durch die anschließende Synchronisation dann Dateien verändert?

Das würde es zumindest zum Teil erklären, wobei es ja auch Geräte gibt, die für die Synchronisation wirklich nur ~6 Minuten brauchen (SSDs eigentlich identisch, wurden alle gleichzeitig ausgetauscht)

Grüße
Alex

13

Hallo Alex,

ich weiß es nciht wie das bei ntfsclone (also Windows mit Neu und start) läuft: also wie ntfscloen genau arbeitet.
Aber beim normalen sync ist das ein rsync aus dem Hauptspeicher.
Im Hauptspeicher wird nach und nach das cloop eingeblendet und rsync synct das auf die Platte.
Dabei sind die kleinen Dateien relevant.

LG

Holger

14

Hallo Holger,

schon wieder was gelernt :+1: Windows haben wir seit 3 Jahren nicht mehr im Einsatz. Wenn das natürlich mittels rsync geschieht, dann ist das klar dass es länger geht.

Technisch gesehen: bietet rsync hier irgendwelche wesentliche Vorteile gegenüber dd? Wenn das System schon auf der Festplatte ist und nur zurückgesetzt werden soll, könnte es ja prinzipiell schneller gehen, da nur die geänderten Daten kopiert werden müssen. Aber bei einer Neuinstallation, wäre da nicht dd besser?

Grüße
Alex

15

Hallo Alex,

nimmst du dd dann kann das zu Problemen führen, wenn die Partition größer/kleiner ist als die von der das Abbild erstellt wurde.
Es ist ja so ganz praktisch, dass das bei ext4 egal ist.

LG

Holger

16

Hallo Holger,

stimmt, daran habe ich nicht gedacht. Das Problem hatten wir tatsächlich damals unter Windows tweilweise noch :sweat_smile:

Was ist bei ext4 egal? Wir haben noch ext3 bei uns in der start.conf stehen (warum weiß ich aktuell aber auch nicht mehr) könnte die Geschwindigkeit damit zusammenhängen?

Aber da die Synchronisierung ja per rsync geschieht sollte es ja möglich sein, jetzt einfach die start.conf auf ext4 zu ändern und die Geräte neu formatieren und synchronisieren zu lassen um auf ext4 umzustellen, oder?

Grüße
Alex

17

Hallo Alex,

vielleicht ist ext4 schneller: ich weiß es nicht.
Vielelicht kannst du das einfach umstellen: probier es an einem Client aus.
Schau aber auch mal in die fstab ob da ext3 steht.

LG

Holger

18

Hallo Holger,

/ ext4 errors=remount-ro 0 1
/dev/sda1 / ext3 defaults 1 1

das ist interessant, in der ersten Zeile steht ext4, allerdings ohne Gerätepfad. In der zweiten Zeile dann ext3 :face_with_raised_eyebrow: Die erste Zeile verursacht bei einem mount -a auch die Fehlermeldung „mount: ext4: der Einhängepunkt ist nicht vorhanden.“

Also der Linuxclient läuft auf ext3. Ich versuche mal die Umstellung auf ext4, vielleicht bringt das geschwindigkeitsmäßig etwas…

Grüße
Alex

19

Hallo Alex,

die erste Zeile ist ja auch falsch: es fehlt nicht der Einhängpunkt sondern der Devicxepfad, also: /dev/sda1

LG

Holger