Ich habe bei meinen Clients das Problem, dass sich Linbo oft (aber nicht immer und auch nicht vorhersehbar und immer mal wieder auf anderen Rechnern) verschluckt, wenn es eine Partition synchronisieren soll.
Es handelt sich um die Linux-Client Partition.
Ich konnte es gerade nachstellen und hab mal die Linbo-Ausgabe mitgeschnitten:
~ # linbo_wrapper sync:2
Befehl : sync
Parameter : 2
Syncing MORZ-Bionic ...
10.16.1.1
/dev/sda6
syncr 1: »10.16.1.1« 2: »/dev/sda6« 3: »bionic.cloop« 4: »« 5: »/dev/sda2« 6: »/dev/sda2« 7: »vmlinuz« 8: »initrd.img« 9: »ro splash«
Mounte Cache-Partition /dev/sda6 ...
RSYNC Download 10.16.1.1 -> bionic.cloop.torrent...
Starte Torrent-Dienst fuer bionic.cloop.
Keine neuere Version vorhanden, ueberspringe bionic.cloop.
Veranlasse Upload von image.log.
Veranlasse Upload von linbo.log.
update 1: »10.16.1.1« 2: »/dev/sda6«
LINBO-Update wurde schon ausgefuehrt!
syncl 1: »/dev/sda6« 2: »bionic.cloop« 3: »« 4: »/dev/sda2« 5: »/dev/sda2« 6: »vmlinuz« 7: »initrd.img« 8: »ro splash«
Entpacke: bionic.cloop -> /dev/sda2 [Datei-Sync]...
## Sat Oct 5 13:02:33 UTC 2019 : Starte Synchronisation von bionic.cloop.
modprobe cloop file=/cache/bionic.cloop
(spaw[2520]: failed to execute '/usr/bin/unshare' '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/cloop6': No such file or directory
udevd[2489]: Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/cloop6' failed with exit code 2.
(spaw[2522]: failed to execute '/usr/bin/unshare' '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/cloop5': No such file or directory
udevd[2499]: Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/cloop5' failed with exit code 2.
(spaw[2523]: failed to execute '/usr/bin/unshare' '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/cloop4': No such file or directory
Fehler: /cloop kann nicht vom Image "bionic.cloop" gemountet werden.
## Sat Oct 5 13:02:34 UTC 2019 : Beende Synchronisation von bionic.cloop.
Fehler!
Kann /dev/sda2 nicht einhaengen!
Veranlasse Upload von image.log.
Veranlasse Upload von linbo.log.
plauder mal mehr von dem Client.
Was haben wir den da?
Massenspeicher?
Board?
…
Ich würde mal folgendes probieren:
mit der lmn7 bin ich wegen der anfangs noch fehlenden
„zweibetriebsysteme in der Domäne“ Problematik weggegangen vom sda6 als
Cache.
Auch im Blick auf die Zukunft, wenn es mehr UEFI Clients werden.
Ich weiß noch nciht woran es liegt, aber mitlerweile gibt es ab und zu
Probleme, wenn der cache die letzte Partition ist.
Deswegen habe ich folgende Partitionierung bei mir:
sda1-> ubuntu
sda2 -> cache
sda3 -> Swap
sda4 -> data
Probier doch mal eine solche Partitionierung, partitionier den Cleitn
neu und schau, ob das deine Probleme behebt (auch das „linbo installiert
sich nicht in den MBR“ Problem aus dem anderen Tread).
Die Clients sind alle baugleiche Fujitsu-Rechner mit Intel Core-i3 und 4GB RAM. Massenspeicher sind diese kleinen Steck-SSDs mit jeweils 120GB
Board kann ich gar nicht genau sagen.
Gebootet wird per UEFI
Partitioniert sind sie so (ich hab schon eine „Pufferpartition“ hinter dem Cache… ):
[LINBO]
SystemType = efi64
KernelOptions = quiet splash dhcpretry=15
ConsoleFontColorStderr = red
ConsoleFontColorStdout = white
BackgroundFontColor = white
Cache = /dev/sda6
Server = 10.16.1.1
Group = morz2019
RootTimeout = 3600
AutoPartition = no
AutoFormat = no
AutoInitCache = no
DownloadType = torrent
[Partition]
Dev = /dev/sda1
Size = 200M # 200MB uefi
Id = ef
FSType = vfat
Bootable = no
[Partition]
Dev = /dev/sda2 # 20GB für bionic
Size = 20G
Id = 83
fstype = ext4
bootable = yes
[Partition]
Dev = /dev/sda3
Size = 2G # 2GB Swap
Id = 82
FSType = swap
Bootable = no
[Partition]
Dev = /dev/sda4
Size = 20G # 20Gig für Xenial
Id = 83
FSType = ext4
Bootable = yes
[Partition]
Dev = /dev/sda5
Size = 30G # 30Gig für virtuelles Win
Id = 83
FSType = ext4
Bootable = yes
[Partition]
Dev = /dev/sda6
Size = 40G # 40G Cache
Id = 83
FSType = ext4
Bootable = yes
[Partition]
Dev = /dev/sda7
Size = 100M # Cache soll nicht die letzte Partition sein, deshalb noch 100MB Puffer hintendran...
Id = 83
FSType = ext4
Bootable = no
Frisch partitioniert sind sie alle kürzlich mit linbo-remote -p partition,format,initcache:torrent,sync:1,sync:2
wobei mir beim Beobachten aufgefallen ist, dass partition und format doppelt gemoppelt ist… er hat bei partition schon formatiert und dann halt nochmal.
ich beobachte ein „gleiches“ Verhalten, habe das aber bisher ignoriert, weil andere Probleme Im Vordergrund standen.
Am Client muss ich auch teilweise 2-mal auf Sync-Start klicken damit Linbo Linux startet. Genau wie Jesko finde ich keine Regelmäßigkeit.
Das ist unabhängig von der Hardware. Kommt bei unseren 2 Hardwareklassen und einem virt. Client vor.
Wir haben nur ein Linux-Image, kein Windows. Gebootet mit normalem Bios und 3 Partitionen (System, Swap, linbo-cache)
Ich habe um das Problem einzukreisen den Autostart der Clients mit „automatischem Partionieren“ versehen und wollte das beobachten …
Der Workaround von Jesko „linbo-remote -p sync:2,sync:2,start:2“ ist nett. Geht das auch irgendwie für den Autostart eines Clients beim booten?
du kannst das grafische grub-menü verwenden und die Datei anpassen: /var/linbo/boot/grub/<deine_startkonfiguration>.cfg
dort ist irgendwo der Eintrag für sync+start
Beispiel:
menuentry 'MORZ-Linux (Sync+Start)' --class linux_syncstart {
if [ -e "$linbo_kernel" -a -e "$linbo_initrd" ]; then
set bootflag=localboot
elif [ -n "$pxe_default_server" ]; then
set root="(tftp)"
set bootflag=netboot
fi
if [ -n "$bootflag" ]; then
echo LINBO $bootflag for group morz
echo
echo -n "Loading $linbo_kernel ..."
linux $linbo_kernel linbocmd=sync:1,start:1 $bootflag
echo
echo -n "Loading $linbo_initrd ..."
initrd $linbo_initrd
boot
fi
wenn du hier in der Zeile linux $linbo_kernel linbocmd=sync:1,start:1 $bootflag
ein zusätzliches sync:1 (oder welches System auch immer) einfügst und diesen Eintrag als Standard definierst, dann ist das von dir gewünschte* Verhalten erreicht.
„gewünscht“ wäre ja eigentlich, dass das nicht nötig ist…