- - this is a known problem
- there is a workaround involving zcat,dd and stripping the first 512 bytes off volumes greater than 1
- do not compress multivolume images
- these concerns go back 3-4 years and still have not been fixed
- partimage 0.7 seems to have stopped development
- partimage is written in C++ and is not the best code I have seen
- partimage is an intimate blend of GUI (newt) threads all in a mix of C and C++
- the design does not comply with accepted UNIX philosophy - many small tasks
- everybody wants to use partimage
- partimage is not actively maintained
- there is no managed development process - no CVS/svn repository
The details are (thanks to 'treczoks' on this forum and Steven Shiau):
Put the following script (called 'partcat') in your executable path on the server PC:
Note the redirections of &2 to null - these messages confuse the partimage display if left out.
Code: Select all
#!/bin/bash # # script to workaround partimage restore bug of multivolume images # toskip=0 for i in $1.??? do zcat $i 2>/dev/null | dd skip=$toskip 2>/dev/null toskip=1 done exit 0
From the PC that you want to restore type:
to restore the image PC on server 'server' to hda3. The --batch is necessary otherwise partimage hangs and cannot be killed.
Code: Select all
ssh server "partcat /images/PC" | partimage --batch --erase restore /dev/hda3 stdin
Going back to the original error - I looked at the code and the problem seems to be in the client. The client starts a thread ( procReadBufferFromImage) to read from the network and pipes this to the main thread which writes it to disk. The network thread sets a global variable g_nThreadstate to THREAD_EOF but only after writing output - consequently the mainthread sees the short read, (buffer.cpp-> CImage::read()) and checks this global variable g_NThreadstate but for some reason it is still 0 (THREAD_RUNNING) and it then throws an ERR_READINg exception. If you see remarks about '-96' in your logs this is the value of ERR_READING.
I tried fixing it but to no avail - my C++ skills are not good and there is something about the thread management in partimage that is not obvious.
All the above experience leads me to the conclusion that partimage should be retired and a new package (let's call it ghost-utils) created. It will be:
- - written in C
- consist of a lot of small applications.
- have no GUI code
- no threading. (Note that the ssh scripting fix I detail above was no slower than the normal partimage operation)
- use wellknown filesystem images such as iso9660,squashfs ....