Hallo zusammen,
is f-win10.cloop.torrent really a metainfo file ??
error inital metainfo faild
ich bekomme die obige Meldung beim Versuch ein bestimmtes Image über Torrent herunterzuladen.
Bei anderen Images tritt der fehler nicht auf.
Das Image wurde neu erstellt.
Den Tracker habe ich schon mit “force” neu gestartet.
Die Torrents wurden dann neu aufgebaut.
gibt es noch irgendwo ein log ? Ich habe nichts aussagekräftiges gefunden.
gruß
Peter
Hallo Peter,
is f-win10.cloop.torrent really a metainfo file ??
error inital metainfo faild
ich bekomme die obige Meldung beim Versuch ein bestimmtes Image über
Torrent herunterzuladen.
Bei anderen Images tritt der fehler nicht auf.
Das Image wurde neu erstellt.
Den Tracker habe ich schon mit „force“ neu gestartet.
Die Torrents wurden dann neu aufgebaut.gibt es noch irgendwo ein log ? Ich habe nichts ausagekräftiges gefunden.
die logs liegen unter /var/linbo/log/
und heißen
_linbo.log
_image.log
_patch.log
die image.log wäre interessant.
Außerdem wäre die Ausgabe von
ls -al /var/linbo/.cloop*
interessant und der INhalt der /var/linbo/start.conf.
Viele Grüße
Holger
Hallo Holger,
das ist das was ich gefunden habe:
15:15/2 castor ~ # ls -al /var/linbo/F-win10.cloop*
-rw-rw-r-- 1 root root 70727056140 Feb 7 09:38 /var/linbo/F-win10.cloop
-rw-rw-r-- 1 root root 22 Feb 7 09:05 /var/linbo/F-win10.cloop.desc
-rw-rw-r-- 1 root root 135 Feb 7 09:38 /var/linbo/F-win10.cloop.info
-rw------- 1 root root 147 Feb 7 09:12 /var/linbo/F-win10.cloop.macct
-rw-rw-r-- 1 root root 853 Jul 18 2016 /var/linbo/F-win10.cloop.reg
-rw-rw-r-- 1 root root 5396223 Feb 7 10:17 /var/linbo/F-win10.cloop.torrent
Die Image .log ist zu groß
und die Start.conf
# LINBO start.conf Beispiel mit
# Windows 7 auf Partition 1 (NTFS)
# Ubuntu auf Partition 2
# Swap auf Partition 3
# Daten auf Partition 5 (NTFS)
# Cache auf Partition 6
# Festplatte 160G
[LINBO] # globale Konfiguration
Cache = /dev/sda2 # lokale Cache Partition
#Cache = /dev/sda2 # lokale Cache Partition
Server = 10.16.1.1
Group = f2016
# Achtung: Server und Group werden beim Workstationsimport automatisch gesetzt!
SystemType = bios # moeglich ist bios|bios64|efi32|efi64 (Standard: bios fuer bios 32bit)
RootTimeout = 600 # automatischer Rootlogout nach 600 Sek.
AutoPartition = no # automatische Partitionsreparatur beim LINBO-Start
AutoFormat = no # kein automatisches Formatieren aller Partitionen beim LINBO-Start
AutoInitCache = no # kein automatisches Befüllen des Caches beim LINBO-Start
DownloadType = torrent # Image-Download per torrent|multicast|rsync, default ist rsync
BackgroundFontColor = white # Bildschirmschriftfarbe (default: white)
ConsoleFontColorStdout = white # Konsolenschriftfarbe (default: white)
ConsoleFontColorStderr = red # Konsolenschriftfarbe für Fehler-/Warnmeldungen (default: red)
KernelOptions = quiet splash # Beispiele:
#KernelOptions = acpi=noirq irqpoll # LINBO Kerneloptionen (z. B. acpi=off), m. Leerz. getrennt
#KernelOptions = server=10.16.1.5 # Abweichende Linbo-Server-IP als Kerneloption gesetzt
# falls gesetzt wird diese IP beim Workstationsimport verwendet
[Partition] # Start einer Partitionsdefinition, Windows 7 auf NTFS
Dev = /dev/sda1 # Device-Name der Partition (sda1 = erste Partition auf erster Platte)
Size = 121G # Partitionsgroesse 30G, ist keine Einheit (M, G oder T) angegeben, wird kiB angenommen
Id = 7 # Partitionstyp (83 = Linux, 82 = swap, c = FAT32, 7 = NTFS, ...)
FSType = ntfs # Dateisystem auf der Partition (NTFS)
Bootable = yes # Bootable-Flag
Label = windows # Partitionslabel
[Partition]
Dev = /dev/sda2
Size =
Id = 83
FSType = ext4
Bootable = no
Label = cache
[OS]
Name = Windows 10
Version =
Description = Windows 10
IconName = win10.png
Image =
BaseImage = F-win10.cloop
Boot = /dev/sda1
Root = /dev/sda1
Kernel = grub.exe
Initrd =
StartEnabled = yes
SyncEnabled = no
NewEnabled = yes
Hidden = yes
Autostart = no
AutostartTimeout = 5
DefaultAction = start
Ob folgendes damit etwas zu tun hat weis ich nicht, ich habe es auch erst vorher bemerkt:
Nach einem Upgrade von Win10 wurde eine Sicherheitspartition angelegt. Diese hat die Partitionstabelle verschoben. Nach dem Upload des neuen Images habe ich diese Partition wieder gelöscht, Das war im alten Forum auch so beschrieben. Beim Versuch das Image auf einen anderen Rechner aufzuspielen ist mir der Torrentfehler aufgefallen. Außerdem konnte plötzlich die Partition 1 nicht mehr gemountet werden.
Was ich erst vorher festgestell habe ist das Windows seine Partition eigenmächtig um 10 Gb !!! ??? vergrösert hat. Nun habe ich mit Windows Bordmittel die Partition wieder verkleinert, und teste erneut.
bei 80 GB Daten dauert das eine weile…
Vielen Dank
Peter
hallo Holger,
der fehler mit der Torrent Datei ist weiterhin da.
Das letzte Log von der erstellung:
## Log session begin: Tue Feb 7 16:00:31 CET 2017 ##
Erzeuge Image 'F-win10.cloop' von Partition '/dev/sda1'...
## Tue Feb 7 15:23:08 UTC 2017 : Starte Erstellung von F-win10.cloop.
Starte Kompression von /dev/sda1 -> F-win10.cloop (ganze Partition, 126566400K).
create_compressed_fs -B 131072 -L 1 -t 2 -s 126566400K /dev/sda1 F-win10.cloop
Fertig.
Erstelle Torrent-Dateien ...
Create hash table: 1/266749
Create hash table: 2668/266749
Create hash table: 5335/266749
Create hash table: 8002/266749
Create hash table: 10669/266749
Create hash table: 13336/266749
Create hash table: 16003/266749
Create hash table: 18670/266749
Create hash table: 21337/266749
Create hash table: 24004/266749
Create hash table: 26671/266749
Create hash table: 29338/266749
Create hash table: 32005/266749
Create hash table: 34672/266749
Create hash table: 37339/266749
Create hash table: 40006/266749
Create hash table: 42673/266749
Create hash table: 45340/266749
Create hash table: 48007/266749
Create hash table: 50674/266749
Create hash table: 53341/266749
Create hash table: 56008/266749
Create hash table: 58675/266749
Create hash table: 61342/266749
Create hash table: 64009/266749
Create hash table: 66676/266749
Create hash table: 69343/266749
Create hash table: 72010/266749
Create hash table: 74677/266749
Create hash table: 77344/266749
Create hash table: 80011/266749
Create hash table: 82678/266749
Create hash table: 85345/266749
Create hash table: 88012/266749
Create hash table: 90679/266749
Create hash table: 93346/266749
Create hash table: 96013/266749
Create hash table: 98680/266749
Create hash table: 101347/266749
Create hash table: 104014/266749
Create hash table: 106681/266749
Create hash table: 109348/266749
Create hash table: 112015/266749
Create hash table: 114682/266749
Create hash table: 117349/266749
Create hash table: 120016/266749
Create hash table: 122683/266749
Create hash table: 125350/266749
Create hash table: 128017/266749
Create hash table: 130684/266749
Create hash table: 133351/266749
Create hash table: 136018/266749
Create hash table: 138685/266749
Create hash table: 141352/266749
Create hash table: 144019/266749
Create hash table: 146686/266749
Create hash table: 149353/266749
Create hash table: 152020/266749
Create hash table: 154687/266749
Create hash table: 157354/266749
Create hash table: 160021/266749
Create hash table: 162688/266749
Create hash table: 165355/266749
Create hash table: 168022/266749
Create hash table: 170689/266749
Create hash table: 173356/266749
Create hash table: 176023/266749
Create hash table: 178690/266749
Create hash table: 181357/266749
Create hash table: 184024/266749
Create hash table: 186691/266749
Create hash table: 189358/266749
Create hash table: 192025/266749
Create hash table: 194692/266749
Create hash table: 197359/266749
Create hash table: 200026/266749
Create hash table: 202693/266749
Create hash table: 205360/266749
Create hash table: 208027/266749
Create hash table: 210694/266749
Create hash table: 213361/266749
Create hash table: 216028/266749
Create hash table: 218695/266749
Create hash table: 221362/266749
Create hash table: 224029/266749
Create hash table: 226696/266749
Create hash table: 229363/266749
Create hash table: 232030/266749
Create hash table: 234697/266749
Create hash table: 237364/266749
Create hash table: 240031/266749
Create hash table: 242698/266749
Create hash table: 245365/266749
Create hash table: 248032/266749
Create hash table: 250699/266749
Create hash table: 253366/266749
Create hash table: 256033/266749
Create hash table: 258700/266749
Create hash table: 261367/266749
Create hash table: 264034/266749
Create hash table: 266701/266749
Create hash table: 266749/266749
Create metainfo file F-win10.cloop.torrent successful.
## Tue Feb 7 16:00:31 UTC 2017 : Beende Erstellung von F-win10.cloop.
## Log session end: Tue Feb 7 16:00:31 CET 2017 ##
## Log session begin: Tue Feb 7 16:24:26 CET 2017 ##
Torrent-Optionen: -I 10.23.0.3 -M 40 -z 32
Starte Torrent-Dienst fuer F-win10.cloop.
## Log session end: Tue Feb 7 16:24:26 CET 2017 ##
Gruß
Peter
Hallo Peter,
15:15/2 castor ~ # ls -al /var/linbo/F-win10.cloop*
-rw-rw-r-- 1 root root 70727056140 Feb 7 09:38 /var/linbo/F-win10.cloop
-rw-rw-r-- 1 root root 22 Feb 7 09:05 /var/linbo/F-win10.cloop.desc
-rw-rw-r-- 1 root root 135 Feb 7 09:38 /var/linbo/F-win10.cloop.info
-rw------- 1 root root 147 Feb 7 09:12 /var/linbo/F-win10.cloop.macct
-rw-rw-r-- 1 root root 853 Jul 18 2016 /var/linbo/F-win10.cloop.reg
-rw-rw-r-- 1 root root 5396223 Feb 7 10:17 /var/linbo/F-win10.cloop.torrent
dein Windwos Image ist 70 GB groß?
Ist das normal?
Schau mla mit
ls -al
/var/linbo/
nach, wie groß die alten Images F-win10 sind.
Ob folgendes damit etwas zu tun hat weis ich nicht, ich habe es auch
erst vorher bemerkt:
Nach einem Upgrade von Win10 wurde eine Sicherheitspartition angelegt.
Diese hat die Partitionstabelle verschoben.
… da kann dann nichts mehr passen unter linbo, wenn die Partitionen
verschoben wurden.
Der erstellt ja ein Image von sda1 und legt es in sda2.
Wenn sda1 jetzt irgend eine weitere Partition ist und windows in sda2
liegt, dann ist der cache ja schon nicht mehr da, wo er hin soll…
Nach dem Upload des neuen
Images habe ich diese Partition wieder gelöscht, Das war im alten Forum
auch so beschrieben.
… dass windows beim Update eine Partition anlegt?
In welchem Post steht den das?
Beim Versuch das Image auf einen anderen Rechner
aufzuspielen ist mir der Torrentfehler aufgefallen.
… so wie ich das sehe, versucht linbo da das Iamge von sda2 in sda1
zurück zu spielen: das kann icht gut gehen.
Was ich erst vorher festgestell habe ist das Windows seine Partition
eigenmächtig um 10 Gb !!! ??? vergrösert hat.
… das klingt alles sehr abstrus.
Dass WIndows eine Partition beim UPdate anlegt, selbst wenn es ein
aniversary update ist, hab ich noch nie gesehen oder gehört.
Dass es seine Partition vergrößert, auch nicht.
Nun habe ich mit Windows
Bordmittel die Partition wieder verkleinert, und teste erneut.
bei 80 GB Daten dauert das eine weile…
… ich würde auch überlegen, mal ein Image zurück zu gehen, und dann
nochmal das UPdate zu fahren.
Ich würde aber sowiso windows nicht auf ein neues aniversary Update
heben: es sei den, ich würde es testen wollen, ob das geht.
Vor allem würde ich das nicht in einer produktiven Umgebung machen.
LG
Holger
Hallo Holger,
das Image ist inzwischen nicht mehr das Problem. Es läuft stabil und kann mit rsync problemlos verteilt werden. Die Größe muss auch so sein da eine Datenbank und ein Warenwirtschaftsystem für die Meisterprüfung integriert sind.
Das Problem ist nur noch die Verteilung mit Torrent.
Das Upgrade musste ich machen da nur so ein Wechsel von Pro zu Enterprise möglich war.
Das ist übrigens der Artikel aus dem alten Forum
http://www.linuxmuster.net/forum/thread/962
viele Grüße
Peter
Hallo Peter,
das Image ist inzwischen nicht mehr das Problem. Es läuft stabil und
kann mit rsync problemlos verteilt werden. Die Größe muss auch so sein
da eine Datenbank und ein Warenwirtschaftsystem für die Meisterprüfung
integriert sind.
Das Problem ist nur noch die Verteilung mit Torrent.
Entweder haben wir hier eine größenbeschränkung von Torrent gefudnen
(70GB), oder es ging beim Erstellen des Images etwas schief.
Das vergrößern/verkleinern der WIndows Partition ist auch eine kitzlige
Sache.
Um festzustellen, ob es möglicherweise ein Größenproblem ist, sollten
wir erst andere Probleme ausschließen.
Folgendes würde ich machen:
Das ist übrigens der Artikel aus dem alten Forum
http://www.linuxmuster.net/forum/thread/962
danke: das wußte ich nicht mehr.
Viele Grüße
Holger
Hallo Holger,
Torrent ist bei diesem Image bis letzten Donnerstag gegangen.
Inzwischen habe ich die Partionsgröße reduziert, chkdsk ausgeführt, neues Image erzeugt und mit rsync verteilt. Das erstell Log von diesem Image ist weiter oben zu sehen. Die Punkte 1-6 habe ich damit schon erledigt. Ein anderes Image mit 51 GB läuft ohne Probleme mit Torrent. Ich versuch mal das Image zu verschlanken.
Gruß
Peter
Hallo Peter,
Ich versuch mal das Image zu verschlanken.
ccleaner hilft bei normalen Datein.
Um wenigstens einen kleinen Teil der Updatedateien wieder aus dem System
zu bekommen, sollte man die Datenträgerbereinigung laufen lassen.
Wenn sie offen ist auf „Systemdateien bereinigen“ klicken: das kann
nochmal ein paar GB frei machen.
Schau auch mal, ob die alte Windows INstallation noch rumliegt: Direkt
in C:ß
in einem versteckten Unterverzeichnis
~BT???
so irgendwie heißt das.
Die Datenträgerbereinigung sollte es aber zum löschen anbieten.
LG
HOlger
Hallo Holger,
ich habe das Image auf Ca. 44GB verkleinert.
nun läuft Torrent wieder. 
Es wäre interresant zu wissen wo die Obergrenze ist.
Gruß
Peter