- 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 error I was getting happens when the client is doing a restore and the server has to switch from the first volume to the second. The error displayed is 'Can't read block 0 at 0'. The fix is to uncompress the second volume, strip the first 512 bytes using dd, recompress and then zcat the files together and pipe the result to partimage or to an ssh tunnel i.e. the partimaged does not seem to work.
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:
Code: Select all
# script to workaround partimage restore bug of multivolume images
for i in $1.???
zcat $i 2>/dev/null | dd skip=$toskip 2>/dev/null
Note the redirections of &2 to null - these messages confuse the partimage display if left out.
From the PC that you want to restore type:
Code: Select all
ssh server "partcat /images/PC" | partimage --batch --erase restore /dev/hda3 stdin
to restore the image PC on server 'server' to hda3. The --batch is necessary otherwise partimage hangs and cannot be killed.
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 ....
Anybody else got any comments ?