Hallo
evtl war das Schreiben des Linbo File System mit einem Fehler behaftet?
Hier die Meldungen nachdem es jetzt funktioniert:
`# update-linbofs
Processing linbofs update …
100 % 15,2 MiB / 58,4 MiB = 0,260 1,5 MiB/s 0:38
Ok!
Processing linbofs-np update …
100 % 15,1 MiB / 57,5 MiB = 0,263 1,5 MiB/s 0:39
Ok!
Processing linbofs64 update …
100 % 21,5 MiB / 94,3 MiB = 0,228 1,4 MiB/s 1:09
Ok!
0+0 records in
0+0 records out
0 bytes copied, 0,000156893 s, 0,0 kB/s
mkfs.fat 4.1 (2017-01-24)
xorriso 1.4.8 : RockRidge filesystem manipulator, libburnia project.
Drive current: -outdev 'stdio:/srv/linbo/linbo.iso'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data, 2143m free
Added to ISO image: directory '/'='/var/cache/linuxmuster/linbo/iso'
xorriso : UPDATE : 963 files added in 1 seconds
xorriso : UPDATE : 963 files added in 1 seconds
xorriso : NOTE : Copying to System Area: 432 bytes from file '/usr/lib/ISOLINUX/isohdpfx.bin'
xorriso : WARNING : Boot image load size exceeds 65535 blocks of 512 bytes. Will record 0 in El Torito to extend ESP to end-of-medium.
libisofs: NOTE : Aligned image size to cylinder size by 129 blocks
xorriso : UPDATE : 15.52% done
ISO image produced: 113152 sectors
Written to medium : 113152 sectors at LBA 0
Writing to 'stdio:/srv/linbo/linbo.iso' completed successfully.`
wenn linbo üer die Paketverwaltung aktualisiert wird, dann läuft am Ende automatisch ein update-linbofs
Das sieht man auch: es sind glaube ich drei Prozesse nacheinander:
bios linbo
uefi linbo
und ufei 32 linbo (oder so …)
Das scheint aber nicht immer zu funktionieren. Gerade gestern musste ich bei einem Telefonsupport (linuxmuster 7.0) update-linbofs händisch ausführen, da ansonsten linbo-remote und linbo-ssh nicht funktionierte (Fehlermeldung: permission denied publickey)
Ich habe folgende Theorie:
Linbo Selbst besteht aus zwei Paketen:
linuxmuster-linbo-common
linuxmuster-linbo
Das update-linbofs wird von linuxmuster-linbo im postinst script gerufen. Die linbofs Archive liegen allerdings in linuxmuster-linbo-common. Da linuxmuster-linbo wie hier
Zu sehen, bei Depends eine alte Version von linuxmuster-linbo-common drin stehen hat, kann es passieren, dass zuerst linuxmuster-linbo und dann linuxmuster-linbo-common aktualisiert wird. In dem Fall wird update-linbofs zuerst gerufen und erst danach das neue linbofs entpackt. Das führt dann unweigerlich zu Problemen.
Da sollte man halt jetzt wissen, warum es nicht funktioniert hat.
Da steht (>= 2.3.13), d.h. dass das abhängige Paket eine Versionsbedingung erfüllen muss. Hat nichts mit der Reihenfolge zu tun. Bei neuen Versionen von Linbo werden immer beide Pakete aktualisiert, sodass update-linbofs immer zum richtigen Zeitpunkt aufgerufen wird. Probleme wg. linbofs habe ich bisher nur beobachtet, wenn das Paketupgrade aus irgendeinem Grund nicht sauber durchlief (Linbo-Partition voll, Abhängigkeiten nicht erfüllt, abgrebrochene Paketdownloads etc.).
ich würde Dir gern die Frage beantworten warum es nicht getan hat, weiß es aber nicht. Ich hatte einen Anruf am Support Telefon. Das Problem war dass linbo-remote nicht funktionierte. Der Versuch per linbo-ssh auf einen Rechner zuzugreifen scheiterte mit der Antwort "permission denied (publickkey). Die Suche im Forum ergab dann das update-linbofs nicht ausgeführt war. Nach dem Ausführen von update-linbofs ging dann beides. Da habe ich nicht mehr danach geschaut, warum update-linbofs nicht ausgeführt war.
Vielleicht ist das ein Hinweis warum update-linbofs nicht immer richtig ausgeführt wird.
ich habe gerade die Updates für den 6.2er Server eingespielt.
Dabei kam diese Meldung:
Setting up unzip (6.0-4ubuntu2.6) …
Setting up linuxmuster-linbo-common (2.4.3-2) …
WARNING: Sophomorix failed to set linbo password! Probably postgres or slapd services do not run!
Processing linbofs update …
100 % 15.1 MiB / 58.4 MiB = 0.259 2.6 MiB/s 0:22
Ok!
Processing linbofs-np update …
100 % 15.1 MiB / 57.5 MiB = 0.263 2.9 MiB/s 0:20
Ok!
Processing linbofs64 update …
100 % 21.2 MiB / 94.3 MiB = 0.225 2.3 MiB/s 0:40
Ok!
0+0 records in
0+0 records out
0 bytes (0 B) copied, 2.316e-05 s, 0.0 kB/s
mkdosfs 3.0.12 (29 Oct 2011)
Irgendwann später wurde der slapd gestartet. Danach habe ich noch einmal update-linbofs ausgeführt und das Passwort wurde als richtig gesetzt gemeldet.
Vielleicht ist das ein Hinweis warum update-linbofs nicht immer richtig ausgeführt wird.
ich habe gerade die Updates für den 6.2er Server eingespielt.
Dabei kam diese Meldung:
da kam wohl ein Paket mit, das den slapd neu gestartet hat.
update-linbofs lief dann ausgerechnet zu dem Zeitpunkt, an dem der slapd
gerade nicht lief. In dem Fall update-linbofs einfach nach dem Update
nochmal ausführen.
gerade bin ich über denselben Fehler gestolpert. Bei mir war linbofs aktuell, ich hatte nur eine Partitionierung start.conf.win10-efi ausgewählt. In der Linbo GUI steht als Basis Image „none“. In der start.conf.win10-efi steht
...
[OS]
BaseImage = win10.cloop
...
Dieses Image existiert aber nicht. Erst wenn man
...
[OS]
BaseImage =
...
setzt, bootet der Laptop wieder.
Hier sollten evtl. die Templates angepasst werden?
… ich will dir ja nicht widersprechen, aber ich glaube nicht, dass es daran lag.
Wenn dem so wäre, dann würde ich ja bei jedem Wechsel des Imagenamens Probleme bekommen: ich mach das aber in meiner Testumgebung oft und hatte noch nie deswegen Probleme…
… kannst du das noch mal testen?
das Netzwerk war einfach zu lahm.
Gründe können sein: Switch stirbt (hatte ich schon) oder ein Kabel ist malad oder es herscht gerade richtig traffic … lauter so Zeug.
. Siehe oben. Ich wollte nur eine Erklärung nachliefern, warum update-linbofs manchmal nicht erfolgreich durchgeführt wurde.