verzeiht die Anfängerfrage, aber ich finde in der Dokumentation einfach keine Anleitung, wie ich einen neuen PC mit einem fertigen Image bespiele?
Ich habe der Anleitung folgend ein ubuntu-image mithilfe von VirtualBox erstellt (wie kann ich eigentlich die fertigen clpkg importieren?) und würde es nun gerne auf einen Rechner bringen.
Was ich mir gedacht habe:
Recher mittels MAC und ausgedachter IP in der Geräteverwaltung/Geräte anlegen.
IP-Adresse in OPNsense als Alias „freischalten“ (warum geht das nicht automatisch?)
in PXE booten
Partition formatieren
neustarten (alles andere ist ausgegraut)
Ubuntu neu installieren / Ubuntu synchronisiert starten → habe beides ausprobiert
es beginnt die Formatierung und dann noch ein paar weitere Vorgänge, bevor der Rechner plötzlich rebootet - aber in einen ungültigen grub :-(…
Was mache ich falsch bzw. gibt es irgendwo eine Anleitung zum korrekten Vorgehen?
wir sind Spezialisten für Anfängerfragen: die haben wir am liebsten
Also: bei uns werden Rechner in Gruppen sortiert: wir nennen sie „Hardwareklasse“.
Jede Hardwareklasse hat eine eigene start.conf.GRUPPE Datei in der definiert ist, wie die Partitionen zu sein haben und wie der Image name ist.
Du willst einen neuen Rechner mit einem bestehenden Image bespielen?
Dann nimmst du ihn auf (der Vorgang ist in der Doku beschrieben): du machst ihn also dem Server bekannt: dabei wird er auch einer Hardwareklasse zugeordnet.
Das war es schon: den aufgenommenen Rechner booten, partitionieren und Image zurückspielen.
genau: oder Rechner am Netzwerk per PXE booten und dann direkt in linbo die Eintragungen machen.
? … wiso neu installieren? Du wolltest doch ein vorhandenes Image verwenden?
… wenn du noch nie ein Image hochgeladen hast, dann hat er auch nichts zu syncen: die Partition ist leer und grub kann das Betriebsystem dann natürlich nicht finden.
Booten = PXE in linboot?
Welche Option muss ich dann dort wählen, damit das Image aufgespielt wird?
Zum Verständnis: Image wurde in VirtualBox erzeugt, der Rechner ist quasi leer. Deswegen ging ich vom neu installieren und nicht einfach Ubuntu starten aus?
wenn du in vbox ein Image erstellt hast, dann mußt du das Image auch hochladen, nicht nur erstellen. Dann liegt es auf dem server (in vbox?)
Dann mußst du den Rechner, der das Image bekommen soll, an diesen server anschließen und ihn in ide Gruppe aufnehmen, in der der Rechner war, von dem aus du das Image erstellt hast.
Ist der Rechner aufgenommen, dann reboote ihn und partitioniere ihn mit linbo: dann Image zurückspielen (roter Knopf).
Image in VirtualBox erstellt, gemäß Anleitung auf den Server (extra Hardware) hochgeladen
im Server ist unter LINBO eine Gruppe „musterClientUbuntu“ angelegt, darin unter Partitionen u.a. die ubuntu-Partition, wo besagtes Image als OS hinterlegt ist
Image zurückspielen finde ich dort nicht und wenn ich Ubuntu starte (woraufhin wohl eine Installation beginnt), stürzt er auf zwei verschiedenen (baugleichen) Rechnern nach ein paar Minuten klanglos ab und beim Reboot ergibt sich ein kaputter grub…
das Image ist also auf dem Server und der Hardware Gruppe „musterClientUbunt“ zugeordnet. Der Client den Du mit dem Image bespielen willst ist auch der Gruppe zugeordnet. Sieht man ja auf Deinem Screenshot.
Wie Holger also schon gesagt hatte:
Wie auf Deinem 2. Screenshot, den PC mit dem Button „Partitionieren“ die Partitionen die in der start.conf der Gruppe angegeben sind partitionieren
Dann zurück zum 1. Screenshot - den PC „Neu“ mit dem Image bespielen, also der rote Button (zweiter von rechts).
danke für die Antwort.
Das ist genau das, was ich bisher gemacht habe. Leider stürzt der Install offenbar ab (habe noch nicht herausgefunden wie/wieso)…
Wo könnte ich am besten schauen, was da schief läuft? Hardware-Probleme hätte ich erst einmal ausgeschlossen, da der Rechner mit Linux vom Stick läuft und ich einen zweiten (baugleichen) Rechner mit dem selben Problem habe…
Ich habe es noch einmal probiert, um zu sehen wann es zum Absturz kommt.
Die letzten Meldungen waren:
[...]
Partition /dev/sda2 ---> Label cache .... OK!
Setting up swapspace [....]
Partition /dev/sda3 ---> Label swap ... OK!
Partition /dev/sda4 ---> Label data .... OK!
[...]
Veranlasse Upload von image.log
Veranlasse Upload von linbo.log
start 1: [Codierungsprobleme bei der Anzeige - aber irgendwas mit Kernelparametern]
Kernel vmlinuz auf Partition /dev/sda1 nicht vorhanden. Setze auf "auto".
Schreibe reboot-Informationen nach /cache/boot/grub/grubenv
[...noch eine kurze Zeile...]
… ich meinte die start.conf.GRUPPE
Das hatten wir Gestern oder Vorgestern schon diskutiert.
Welche lmn Version hast du den?
Welche linbo Version?
cat /etc/issue
und
dpkg -l | grep linbo
Und dann erzähl mal ein wenig zu deinem Setting: du hast eine vbox Umgebung auf einem Rechner laufen: Server ist in vbox.
Bisher hast du das Image an einem ebenfalls virtualisierten Client erstellt und jetzt willst du es auf die echte Möhre haben?
Hast du das Netzwerk dann rausgebridged?
Geht PXE am externen Client?
Bitte poste auch die komplette /etc/linuxmuster/sophomorix/default-school/devices.csv
@Rechner2: Virtualbox Netzwerkadapter angeschlossen an Netzwerkbrücke, dort dann den Identifier des Kabelanschlusses, welcher zu GREEN am Server (Recher1) führt.
@Rechner3: Ich habe inzwischen ein Abbild direkt auf dem Client erzeugt (musterClient02), um Fehler durch Hardwareinkompatibilitäten auszuschließen.
Das geschah auf Rechner 3a.
Ich habe noch einen baugleichen Rechner 3b. Auf diesen habe ich jetzt das (zumindest für linuxadmin funktionierende) Image von Rechner 3a spielen wollen und wieder auf das Problem des nicht funktionierenden Grubs gestoßen:
Offensichtlich gibt es ein Problem mit Laufwerkszuordnung via UUID?
Falls es bei der Fehlersuche hilft: wenn ich versuche, mich mit einem Lehreraccount auf den Clients anzumelden (egal auf welchem Rechner), erschient diese Fehlermeldung:
Hier noch die start.conf für Rechner3 und das diff zu Rechner2 - wobei nur beabsichtigte Änderungen vorhanden sind (wollte sicher gehen, das richtige Image erwischt zu haben):
Etwas, was mir jetzt auffällt ist, dass die start.conf-Vorlage von Ubuntu 18.04 spricht, während ich Ubuntu 20.04 installiert habe. Ist das ggf. das Problem?
wenn du in der Gruppe
musterClientUbuntu
ein Image erstellst, so heißt es:
ubuntu01.cloop
Wenn du an einem Client in der Gruppe:
LenovoIdeapad300
ein Image zurückspielst, so wird das Image lenovo01.cloop
genommen: welche ja leer ist, wenn du da noch kein Image erstellt hast.
Du darfst ohne weiteres das selbe Image in mehreren GRUPPEN verwenden: aber dann mußt du das in der start.conf.GRUPPE auch jeweils reinschreiben.
Also schreib mal in die lenovogruppenstart.conf statt lenovo01.cloop einfach ubutu01.cloop und versuch es dann nochmal mit einem frisch gebooteten Client. Beachte aber, dass die Partition bei lenovo 50GB groß ist und die auf dem Musterclient 30GB. Bei linuximages normalerweise kein Problem.
Dass da noch 18.04 in der start.conf steht kannst du ignorieren
Was noch auffällt: dein linbo ist sehr alt: du hast 2.3.?? Aktuell ist aber für die lmn7 linbo 2.4.??
Du solltest updaten.
Ich habe aber inzwischen auch ein Image von Rechner 3a aus erstellt.
Ich ging natürlich ebenso davon aus, dass die images austauschbar wären - deswegen ja meine umso stärkere Verwunderung und Vermutung, dass auf meiner Seite noch ein Fehler vorliegt…
@Update: das führt zu dem Problem aus dem anderen Thread mit dem nicht korrekt signierten Repository. Weil ich das nicht gelöst bekommen habe, habe ich noch nie geupdated.
Hole das gerade für 210 Pakete nach …
Es ergeben sich zwei Fragen:
1.) brauche ich das archiv.linuxmuster.net Repo?
2.) ab welcher Stelle sollte ich meine Installation noch einmal starten, wenn das Update durchgelaufen ist? Client Erstellung noch einmal komplett von vorne?
2.b) Wie könnte ich - es geht im Augenblick ja vor allem darum, unserem IT-Dienstleister lmn zu demonstieren - die fertigen cloop-Packages nutzen?
Das Update hat mir wohl mehr vom Server zerschossen als geholfen. Ich werde dann doch noch einmal die server-VM neu aufsetzen.
Was mir immer noch nicht klar ist: brauche ich jetzt lmn7-appliance bzw. das prepare Skript, wenn ich mit default-Vorgaben arbeite? Die setzen ja nach wie vor auf das nicht korrekt signierte Repository und laufen entsprechend nicht richtig durch :-(…
beschreib mal genauer: das hab ich nämich noch nicht erlebt, dass ein update den Server „zerschießt“
wir haben keinen „nicht korrekt signierten“ Repo Server.
Wir haben einen Repo Server dessen signatur von neueren ubuntus nicht akzeptiert wird und wo bei einem ubuntu 18.04 server erst die ssl Chain aktualisiert werden muss, bevor er als korrekt gekennzeichnet wird.
Das Vorgehen beim Aufsetzen sollte immer sein: zuerst aktualisieren, dann prepair und dann setup machen.
Und wegen deiner Frage zum Vorgehen nach dem linbo update: linbo Images sind immer kompatibel zu neueren Versionen.
Nach dem update mußt du keien neuen Images machen (das wird erst beim Umstieg auf linbo 4 empfehlenswert).
Also: nach linbo update, einfach weiter machen.
Wenn ich das probiere, lande ich nach PXE in einer initramfs-Konsole oder so ähnlich…(habe es leider aus Frust nicht dokumentiert).
Und genau dies scheitert, weil ja das lmn7-appliance-Skript die /etc/sources.d/lmn.list ohne [trusted=yes] einträgt!
Habe es in diesem Skript noch reparieren können - aber prepare scheint das dann wieder zu zerstören :-(…
Wie hier ja ausreichend beschrieben (V7 Repo not signed), geht kein Update ohne entsprechende trust oder ähnliche Konfiguration…
Ich kann es hier gerne konkret dokumentieren. Bin gerade beim Importieren der vzdumps.
Welche Befehle soll ich jetzt ausführen, damit genügend Sicherheit bzw. Debugging gewährleistet ist?
Mein Vorschlag:
Frage wäre jetzt noch, ob das vor oder nach dem Tauschen der Interfaces (also RED vs. GREEN) gemacht werden soll?
Und ob die VMs gestartet (aber nicht eingerichtet) sein sollen oder nicht?
Okay. Ich habe also entsprechende Zeilen oben ausgeführt.
Zuvor green/red getauscht (also red=extern, green=intern) und die VMs gestartet.
root@hv01:~# apt update
Hit:1 http://security.debian.org bullseye-security InRelease
Hit:2 http://ftp.de.debian.org/debian bullseye InRelease
Get:3 http://ftp.de.debian.org/debian bullseye-updates InRelease [39.4 kB]
Hit:4 http://download.proxmox.com/debian buster InRelease
Fetched 39.4 kB in 2s (16.0 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
1 package can be upgraded. Run 'apt list --upgradable' to see it.
root@hv01:~# apt upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
root@hv01:~# wget https://archive.linuxmuster.net/lmn7/lmn7-appliance
--2022-01-05 17:47:50-- https://archive.linuxmuster.net/lmn7/lmn7-appliance
Resolving archive.linuxmuster.net (archive.linuxmuster.net)... 95.217.39.156
Connecting to archive.linuxmuster.net (archive.linuxmuster.net)|95.217.39.156|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 4332 (4.2K)
Saving to: ‘lmn7-appliance’
lmn7-appliance 100%[================================================================================================================>] 4.23K --.-KB/s in 0s
2022-01-05 17:47:52 (288 MB/s) - ‘lmn7-appliance’ saved [4332/4332]
root@hv01:~# chmod +x lmn7-appliance
root@hv01:~# ./lmn7-appliance -p server -u
### lmn7-prepare
## install lmn7 repo
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
OK
## install software updates
Hit:1 http://ftp.de.debian.org/debian bullseye InRelease
Hit:2 http://ftp.de.debian.org/debian bullseye-updates InRelease
Hit:3 http://security.debian.org bullseye-security InRelease
Ign:4 https://archive.linuxmuster.net lmn7/ InRelease
Get:5 https://archive.linuxmuster.net lmn7/ Release [999 B]
Get:6 https://archive.linuxmuster.net lmn7/ Release.gpg [591 B]
Ign:6 https://archive.linuxmuster.net lmn7/ Release.gpg
Hit:7 http://download.proxmox.com/debian buster InRelease
Reading package lists... Done
W: GPG error: https://archive.linuxmuster.net lmn7/ Release: Detached signature file '/var/lib/apt/lists/partial/archive.linuxmuster.net_lmn7_Release.gpg' is in unsupported binary format
E: The repository 'https://archive.linuxmuster.net lmn7/ Release' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package 'lxd' is not installed, so not removed
E: Unable to locate package lxd-client
E: Unable to locate package lxc-common
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
## install linuxmuster-prepare package
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package linuxmuster-prepare
## invoke linuxmuster-prepare
sh: 1: linuxmuster-prepare: not found
Was habe ich vergessen?
PS: das nicht aktualisierende Paket ist:
root@hv01:~# apt list --upgradable
Listing... Done
libpve-u2f-server-perl/stable 1.1-1 amd64 [upgradable from: 1.1-1]
N: There is 1 additional version. Please use the '-a' switch to see it