das folgende Problem tritt bei einer ESXI VM mit Linbo 4 auf.
Der Client wurde noch nicht aufgenommen, bei aufgenommen Clients kommt nur der Teil mit „Press [1] to …“
Es ist eine normale Festplatte als sda im System. Keine Ahnung, wie Linbo auf sr0 kommt. Ein /dev/sd0 existiert auf dem Client nicht, nur eine /dev/sda.
danke für die Rückmeldung.
Leider ist linuxmuster-linbo-gui7 in der Version 7.0.4 bereits installiert.
Unter Linbo 2.xx hat die neue Gui auch funktioniert.
… wir hatten das schon … aber was hat den Fehler behoben?
mach mal ein
linuxmuster-import-devices
Hast du die /srv/linbo/boot/grub/GRUPPE.cfg Datei verändert?
Dann stell sicher, dass die wieder vom import script neu geschrieben werden kann (der import muss ein „replaced“ in der entsprechenden Zeile melden).
Wenn es das nciht ist, dann sollten wir einmal das linbofs neu erstellen.
sag mal: sind eigentlich in /srv/linbo/ noch die alten Links auf die start.conf Dateien vorhanden?
Da sollen die start.conf.GRUPPE liegen, aber nicht mehr die links von start.conf-IP → start.conf.GRUPPE (so in etwa waren die).
Eigentlich sollte ein linuxmuster-import-devices diese entfernen.
verschiedene Netzwerkkarten wurde durchprobiert. Ohne Erfolg.
Die start.conf.GRUPPE ist vorhanden, die start.conf.IP der Clients fehlen. Passt also.
Funktioniert aber trotzdem nicht.
dhcpretry=9 hatte auch keinen Erfolg gebracht.
Inzwischen habe ich ein neues System from scratch installiert und auf Linbo4 upgedatet.
Ein neuer VM-Client lässt sich nicht hinzufügen, der Client produziert den im ersten Beitrag zu sehenden Bildschirm.
Die Netzwerkverbindung funktioniert, Linbo2 auch und Linbo4 dann nicht mehr.
dhcpretry=9 … genau: das war die Lösung, wenn das [1] … [2] steht …
Das erklärt auch, weswegen linbo-ssh funktioniert …irgend wann kommt die IP dann noch.
Bei dir scheint 9 nicht zu reichen: versuch mal 15 und arbeite dich dann runter zu 10 .
Außerdem solltest du sicher stellen, dass die Änderung auch in der /srv/linbo/boot/grub/GRUPPE.cfg ankommt.
… ich hab noch eine beobachtung gemacht.
Ich bin gerade dabei den Umstieg auf 7.1 von meiner Schule zu testen: in einer VBox VM.
Dazu hab ich meine VBox Umgebung mit rc5 wiederhergestellt und ein Client zeigte das [1] … [2] Problem (noch vor dem Umstieg auf linbo 4.0.2, also noch mit rc5).
Ich hab eine ganze Weile gesucht bis ich gefunden habe, was da los war.
dhcpretry hat auch nicht geholfen.
Ich hatte wohl beim Import der ova nicht auf „MAC Adressen behalten“ gedrückt: der Client hatte die falsche MAC: er war also noch nciht im Netz bekannt und bekam eine IP aus dem Lease.
Erst nachdem ich die MAC in der devices.csv berichtigt und den import gemacht hatte, funktionierte der Client richtig.
Also schau noch mal nach, welche MAC der Client hat und ob die in der devices.csv stimmt.
Die IP darf auch nicht aus dem lease sein.
Hallo Holger,
bei einem neu installierten LMN7, das auf Linbo 4.0.2.0 upgedatet ist, funktioniert nicht einmal die Rechneraufnahme. Der Client bekommt aber aus dem DHCP Bereich eine IP und in WebGUI7 ist er unter dem neuen Punkt DHCP mit MAC und vergebener IP zu sehen.
Vorher aufgenommene Client sind mit ihrer richtigen MAC weiter vorhanden.
Eine geänderte Start.conf wird aber nicht übernommen.
Zusammengefasst:
Auf dem Client wird der Kernel geladen, die Hardware ist komplett ansprechbar, die Netzwerkverbindung funktioniert und auf dem Server ist auch alles ok.
Die Funktionen von Linbo am Client werden aber nicht geladen.
ich nehme an, dass linbo nur die gui nicht laden kann, weil die GraKa nicht richtig läuft.
Versuch mal eine andere ein zu bauen, oder den kernelparameter nomodeset
weder dhcpretry=15 noch nomodeset haben eine Änderung gebracht.
Es werden auch keine Befehle mit linbo-remote ausgeführt. Daher betrifft es wohl nicht nur die GUI, sondern den ganzen Linbo-Bereich nach Start von ssh.
ichhab Gestern bei mir in der Schule 7.1 eingespielt mit linbo 4.0.2
Bisher hab ich keinen Client gefunden bei dem es nicht klappt.
Ich tippe auf Eigenheiten der virtuellen Hardware unter vmware.
Wir hatten sowas schon mal mit proxmox: da mußte die richtige Graka oder netzwerkkarte rein, dann klappte es (also virtuelle Netzwerkkarte).
@MachtDochNix
Die Start.conf hat mit Linbo2 ohne Probleme funktioniert. Mit Linbo4 funktioniert nicht einmal die Erstaufnahme. Da wird die entsprechende start.conf noch nicht verwendet. Bei bereits aufgenommenen Clients werden Änderungen der Gruppe übernommen, mehr nicht.
[LINBO]
Server = 10.16.0.1
Group = NT
Cache = /dev/sda4
RootTimeout = 600
AutoPartition = no
AutoFormat = no
AutoInitCache = no
DownloadType = torrent
GuiDisabled = no
UseMinimalLayout = no
Locale = de-de
SystemType = efi64
KernelOptions = quiet splash
[Partition]
Dev = /dev/sda1
Label = efi
Size = 200M
Id = ef
FSType = vfat
Bootable = yes
[Partition]
Dev = /dev/sda2
Label = msr
Size = 128M
Id = 0c01
FSType =
Bootable = no
[Partition]
Dev = /dev/sda3
Label = windows
Size = 40G
Id = 7
FSType = ntfs
Bootable = no
[Partition]
Dev = /dev/sda4
Label = cache
Size = 40G
Id = 83
FSType = ext4
Bootable = no
[Partition]
Label = data
Dev = /dev/sda5
Size =
Id = 7
FSType = ntfs
Bootable = no
[OS]
Name = Windows 10
Version =
Description = Windows 10 1903
IconName = win10.svg
Image =
BaseImage = win10.cloop
Boot = /dev/sda3
Root = /dev/sda3
Kernel = auto
Initrd =
Append =
StartEnabled = yes
SyncEnabled = yes
NewEnabled = yes
Autostart = no
AutostartTimeout = 5
DefaultAction = sync
RestoreOpsiState = no
ForceOpsiSetup =
Hidden = yes
Anstatt cloop wurde auch qcow2 bereits in die start.conf eingetragen.
@baumhof
Linbo4 muss ja mindestens auf den Systemen von Thomas und etlichen Betatestern laufen.
Bei ESXi ist das halt nicht der Fall. Da nützt auch kein Tausch der virtuellen Hardware, das ist alles durchprobiert.
Mit den Betaversionen von Linbo4 startete die GUI und der Client kann aufgenommen werden. Bei einem weiteren Start kommt die GUI und die Fehlermeldung „No Operating System configured in start.conf“ wird angezeigt. Verschiedene auch neue start.conf Versionen mit cloop und qcow2 funktionieren nicht.
Ab den Releaseversionen von Linbo4 kommt dann die Fehlermeldung mit „Press [1] to reboot …“.
Aktuelle ist Linbo4 auf ESXi nicht einsatzfähig.
Off topic:
Unter Hyper-V findet Linbo2 die Netzwerkkarte nicht und ab Linbo4 wird der Hyper-V-Client hart abgeschaltet.
