Das bedeutet: man bekommst ubuntu server 26.04 drunter.
Ich weiß von mindestens 4 Installationen wo das Update schon durchgeführt wurde: eine davon ist Produktiv (aber Vorsicht: wurde letzte Woche upgedatet, und noch sind Ferien in BW..).
Ich selbst habe virtuelle Umgebungen mit moodle/Nextcloud Anbindung und auch Edulution, upgedatet. Dabei traf ich auf einen Fehler, den wir direkt behooben konnten: so konnte ich das upgrade durch laufen lassen, ohne auf ein Backup zurück greifen zu müssen.
Es wäre Hilfreich, wenn ein paar Leute das Upgrade mal durchführen würden. Eher noch nicht auf Produktiven Umgebungen: es sei denn, man ist vom eigenen Backupkonzept überzeugt
Ok, dann legen wir mal los. Es handelt sich i.W. um ein Upgrade auf Ubuntu 26.04. Die Anleitung findet ihr hier: upgrade-26.04.de.md
Die Vorgehensweise ist im Prinzip diesselbe wie beim vorigen Upgrade.
Für linuxmuster-linbo-gui gibt es noch kein 7.4er Paket im Repo. Die 7.3er-Version funktioniert aber weiter. Aus diesem Grund ist auch noch keine Installation „from scratch“ möglich.
Linbo-Client Hardwareunterstützung: Falls auf dem Client unter Linbo Hardwareprobleme auftauchen, benötige ich neben der Info welche Hardware nicht funktioniert, die Ausgabe von lsmod unter Ubuntu 26.04 und - falls möglich - die Ausgabe von dmesg auf der Linbokonsole.
Client hat beim ersten Aufruf ein linbo-update gemacht und dann in Linbo „gestanden“
Dann ausgeschaltet und beim 2. Aufruf war ein neuer torrent-client am Laufen - hat aber bei 19% nicht weiter geladen…
Dann habe ich abgebrochen und dank proxmox-snapshot in einer Minute wieder den alten Server am Laufen gehabt.
Sorry, dass ich keine detailierteren Fehlermeldung liefern kann..
danke für die Rückmeldung. Hier hatten wir einen Bug in der Ausgabe der Bootmeldungen mit plymouth in Zusammenhang mit linbo-remote. Ist gefixt mit den folgenden Paketen:
Hi @thomas ,
ich kann nach Update des Servers auch erstmal kein Image neu verteilen:
Der Initcache auf einem (in 7.3 schon funktionierenden) Client sagt:
r006-testclient: ~ # linbo_wrapper initcache
### 20260606-112858 linbo_wrapper initcache ###
Command : initcache
### 20260606-112858 linbo_initcache ###
Killed seeder session: debian12_qcow2_torrent
### 20260606-112858 linbo_download_image debian12.qcow2 torrent ###
### linbo_download_image debian12.qcow2 torrent
Trying to download debian12.qcow2.postsync ... not available.
Trying to download debian12.postsync ... Ok.
Trying to download debian12.qcow2.driverpostsync ... not available.
Trying to download debian12.driverpostsync ... not available.
Trying to download debian12.qcow2.reg ... not available.
Trying to download debian12.reg ... not available.
debian12.qcow2 has not changed, nothing to do.
### 20260606-112900 linbo_seeder ###
no server running on /tmp/tmux-0/default
Started seeder for debian12.qcow2.torrent.
### 20260606-112900 linbo_download_image debian12.qdiff torrent ###
### linbo_download_image debian12.qdiff torrent
Trying to download debian12.qdiff.postsync ... not available.
Trying to download debian12.postsync ... Ok.
Trying to download debian12.qdiff.driverpostsync ... not available.
Trying to download debian12.driverpostsync ... not available.
Trying to download debian12.qdiff.reg ... not available.
Trying to download debian12.reg ... not available.
Trying to download debian12.qdiff.desc ... not available.
Trying to download debian12.qdiff.info ... not available.
Ich schätze, ich muss die torrents für den neuen client neu generieren, oder? Und wie geht das jetzt?
LG Jesko
*** Download Progress Summary as of Sat Jun 6 11:39:01 2026 ***
===============================================================================
[#f024e2 0B/7.3GiB(0%) CN:0 SD:0 DL:0B]
FILE: /cache/debian12.qcow2
-------------------------------------------------------------------------------
*** Download Progress Summary as of Sat Jun 6 11:40:01 2026 ***
===============================================================================================================================================================================================================================
[#f024e2 0B/7.3GiB(0%) CN:0 SD:0 DL:0B]
FILE: /cache/debian12.qcow2
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[#f024e2 0B/7.3GiB(0%) CN:0 SD:0 DL:0B]
[#f024e2 0B/7.3GiB(0%) CN:0 SD:0 DL:0B]
aber auf dem Server sehe ich:
06/06 11:42:07 [NOTICE] Downloading 1 item(s)
06/06 11:42:07 [ERROR] Ausnahme aufgetreten
Exception: [AbstractDiskWriter.cc:221] errNum=13 errorCode=15 Öffnen der Datei /srv/linbo/images/debian12/debian12.qcow2 ist fehlgeschlagen, Ursache: Keine Berechtigung
06/06 11:42:07 [NOTICE] Übertragung GID#5169d291d78d1860 nicht vollständig: /srv/linbo/images/debian12/debian12.qcow2
Übertragungsergebnisse:
gid |stat|avg speed |path/URI
======+====+===========+=======================================================
5169d2|ERR | n/a|/srv/linbo/images/debian12/debian12.qcow2
Statuserläuterung:
(ERR):ein Fehler ist unterlaufen.
aria2 wird das Herunterladen wieder aufnehmen, wenn die Übertragung neu gestartet wird.
Sollten Fehler aufgetreten sein, bitte die Protokolldatei beachten. Für Details hierzu bitte die Option »help/man -l« in der Hilfe- und Bedienungsanleitung beachten.
das lässt sich vermutlich nicht mehr so genau sagen. „Ich hab nix gemacht“…
ich hab -inspiriert durch bertholds post- versucht den linbo-client-cache neu zu initialisieren und bin damit gescheitert. Ich kann aber nicht mal mehr mit größter Sicherheit sagen, ob es unter 7.3 geklappt hatte oder ob der letzte funktionierende Stand die 7.2 war, weil ich von 7.2 über 7.3 dirket auf 7.4 upgedated habe.
Es war auf jeden Fall ein kaputter Torrent. im Nachhinein fällt mir auch auf, dass der torrent auf dem Server versucht hatte Teile downzuloaden statt zu seeden, was ja auf fehlende / kaputte torrent-teile schließen lässt.
vielleicht wäre beim Updgrade als „post upgrade hook“ ein überprüfen der benutzten Torrents und ggf neu erstellen derselben keine schlechte Idee.
Was mir jetzt noch auffällt:
Im virtuellen Linbo-Client wird gerade beim Druck auf „sync+start“ das image erneut herungergeladen, obwohl es sicher schon da war.
es ist sehr langsam: Der Server ist neu, hat Tonnen Speicher, der virtuelle (proxmox) Linbo-Client liegt auf einem SSD-RAID und die Images auf dem Server auf einem HDD-Raid.
Im Schulnetz ist gerade niemand, außer dem einen Client und der Server seedet ihm mit 12-20MiB/s Da geht doch eigentlich deutlich mehr, oder? Wo muss man tunen?
Ich vermute mal, du bist in denselben Fehler wie @baltaner reingelaufen. Mit dem aktuellen Linbo 7.4.2 klappt Image erstellen und verteilen per linbo-remote sehr gut.
habe gerade das Update auf 7.4 gemacht und bin in exakt den selben Fehler wie Jesko gelaufen. Habe die .hash/.torrent gelöscht und die Torrent-Datei neu erzeugt und dann hat Linbo funktioniert. Allerdings mit den Problemen/Glitches, die Jesko geschrieben hat:
Das Image wurde beim ersten Start eines Clients neu heruntergeladen obwohl sich nichts geändert hat. Das ist produktiv uncool, weil ich in meinem Fall dann 60 Wlan-Sync-Laptops an die Dose hängen muss…wäre schön, wenn das nicht so wäre. Das ist auch der Grund, warum ich erst mal wieder auf die 7.3 zurück bin…kann aber per Snapshot gleich wieder zur 7.4 wenn ich was testen soll.
Der Download ist extrem langsam…im Schnitt 10-20MBit/s. Das waren bei 7.3 ca. 180-220 Mbis/s. Wo kann man das was tunen?
Diese komische gestrichelte Linie in der Linbo-Gui beim Download des Images ist bei mir ebenfalls…das sieht aus, als wenn der Client hängt.
ich kann das leider nicht nachvollziehen. Ich gehe so vor:
Serverupdate und Reboot.
Auf dem Server ist installiert:
linuxmuster-api7 7.4.1
linuxmuster-base7 7.4.3-0
linuxmuster-cli7 7.4.1
linuxmuster-common 7.4.3-0
linuxmuster-linbo-gui7 7.3.3
linuxmuster-linbo7 7.4.2-0
linuxmuster-prepare 7.3.1-0
linuxmuster-tools7 7.4.2
linuxmuster-webui7 7.4.1
Client, der noch mit dem 7.3er-Server eingerichtet wurde, wird gestartet.
Client holt sich beim Bootvorgang das neue Linbo 7.4.2, macht einen Warmstart und bootet in Linbo 7.4.2.
In Linbogui Sync+Start geklickt, Linbo synct ohne das Image nochmal zu holen und startet ins OS.
Ich sehe keine gestrichelte Linie, auch nicht wenn ich den 7.3er-Client beim ersten Start nach dem Upgrade mit linbo-remote -p format,initcache alle Images neu holen lasse. Die Downloadgeschwindigkeit ist dabei gewohnt schnell.
meine Ausgangslage war exakt so wie du sie beschrieben hast. Ich habe das Update gerade nochmal ganz neu angestoßen und lande halt genau wieder bei den selben Problemen/Unschönheiten wie vorher. Jesko hat ja genau das selbe beobachtet. Hat das vielleicht was damit zu tun, dass du virtuell testest und wir in einer produktiven Umgebung? Das spielte bei einem früheren Update von Linbo auch schon mal eine Rolle…
Wie können wir denn vorwärts kommen? Also mit dem Problem, dass sich alle Clients beim ersten Boot nach dem Update nochmal das Image holen kann man ja leben aber nicht mit der miesen Downloadrate und nur bedingt mit dieser seltsamen, nichtssagenden gestrichelten Linie in der gui wenn das Image geholt wird. Gibt es denn irgendeine Konfiguration an der man schrauben kann? Die alte linbo-torrent.conf liegt ja noch da ist aber wohl nonfunktional…
ich teste hier auch mit einem Thinkpad X380 als Client, läuft mit nomodeset nowarmstart ohne Probleme, Download 11G-Image in 1m40s. Ich brauche einfach mehr Infos:
Ausgabe von linbo-torrent attach ubuntu_qcow2_torrent (Torrentname anpassen) auf dem Server
Serverseitiges linbo.log des Clients (/srv/linbo/log/<client>_linbo.log) nachdem Image gesynct wurde.
Ausgabe von dmesg auf der Linbokonsole
ggf. bei nicht erkannter Hardware die Ausgabe von lsmod idealerweise unter Ubuntu 26.04
