www.partimage.org

Joined: 21 Nov 2006 Posts: 2

Hey guys,

I've searched high and low for a solution to this forsaken problem. Let me give a slight insight as to what it is that I am doing.

I run a pxe server/kickstart server here at work, which also serves a dual purpose of providing a cloning interface. Basically this consists of, a machine booting off of pxe, dhcp gives the box an address, tftp sends a kernel for it to boot, and then it mounts a remote filesystem via NFS. I also wrote an automated cloning interface/wrapper for partimage which allows you to restore images onto the pxe booted server. Now, the restore of images works flawlessly, it's fast and I am very happy with it, but I am experiencing one major major problem:

I cannot seem to save any last partition of any drive, be it scsi or ide.

I've tried many different hardware configurations, and all of them in fact allow me to save all but the last partition. So for instance a setup that goes something like this :

100MB /dev/sda1 /boot
2000MB /dev/sda2 /tmp
4000MB /dev/sda3 swap
/dev/sda4 extended
REST_OF_SPACE MB /dev/sda5 /

/boot, and /tmp would image fine, but as soon as /dev/sda5 would be attempted, the "Can't read bitmap block 0 from image" error comes up.

I've tried different kernels, different partition sizes, different partimage versions, a ton of stuff. Nothing works. Now, on one of our older pxe servers, this function works without any problems, but I have yet to find any relevant differences at all. The only major different is that our older pxe server doesn't run off of a 3ware raid card, unlike the new box.

Please, if anyone could provide any insight into this at all, it'd be greatly appreciated.

Thanks,

Dan S.

Joined: 07 Dec 2006 Posts: 2 Location: USA

I have the same problem but I have it happening on just ONE partition of a brand new vanila install of Fedora 6. Nothing fancy. In my case, the partition is #3 of a dozen, so the problem seems to wider than you state.

The key line in the /var/log/partimage-debug.log was:
[Main] fs_base.cpp->checkBitmapInfos#823: CHECK BITMAP: qwBitmapFreeSize.........15644282880 = 30555240 sectors
[Main] fs_base.cpp->checkBitmapInfos#835: ERROR BITMAP Used and m_bCanBeMore=0
[Main] fs_base.cpp->checkBitmapInfos#837: THROW: -95
[Main] exceptions.cpp->CExceptions#107: checkBitmapInfos -> throws (DWORD): -95 (0)
[Main] imagefile.cpp->closeWriting#605: PTHREAD_JOIN: before
[Main] buffer.cpp->procWriteBufferToImage#77: EOF
[Main] image_disk.cpp->write#166: called for 4853
[Main] image_disk.cpp->write#230: m_qwTotal = 19189

Disabling the two checks (I know I was doing something dangerous!) DID allow partimage to continue and do the backup but the restore was VERY DAMAGED. Of the 700MB, only 220MB was any good, rest ended up in lost+found.

The two checks were in src/client/fs/fs_base.cpp
m_bCheckSuperBlockUsedSize and m_bCheckSuperBlockFreeSize

Bit of printfs gave:
m_bCanBeMore = 0, qwBitmapUsedSize=1134231552, m_qwSuperBlockUsedSize=0

Partitions passes fsck (1.39) with flying colors... nothing wrong with it
otherwise. Here's the tunefs:

tune2fs 1.39 (29-May-2006)
Filesystem volume name: /1
Last mounted on: <not available>
Filesystem UUID: bf676205-66f5-43c1-bed6-2b82e3ff7c65
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 4100544
Block count: 4096575
Reserved block count: 204828
Free blocks: 3819959
Free inodes: 4089662
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 1000
Blocks per group: 32752
Fragments per group: 32752
Inodes per group: 32544
Inode blocks per group: 1017
Filesystem created: Sun Nov 12 14:32:13 2006
Last mount time: Thu Dec 7 10:51:41 2006
Last write time: Thu Dec 7 10:51:41 2006
Mount count: 9
Maximum mount count: 15
Last checked: Wed Dec 6 07:00:27 2006
Check interval: 0 (<none>)
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Default directory hash: tea
Directory Hash Seed: 03bb674e-b2cb-486b-b840-0ce89bf9d445
Journal backup: inode blocks

And here's a different drive, created at the same time with the same tools that works fine:

tune2fs 1.39 (29-May-2006)
Filesystem volume name: /workspace
Last mounted on: <not available>
Filesystem UUID: 8a0cd02f-85b7-4153-8217-b9e19cb5cc42
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 2560864
Block count: 2560351
Reserved block count: 128017
Free blocks: 2200057
Free inodes: 2554124
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 625
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 32416
Inode blocks per group: 1013
Filesystem created: Fri Dec 16 16:07:05 2005
Last mount time: Thu Dec 7 10:51:41 2006
Last write time: Thu Dec 7 10:51:41 2006
Mount count: 8
Maximum mount count: -1
Last checked: Wed Dec 6 07:02:05 2006
Check interval: 0 (<none>)
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Default directory hash: tea
Directory Hash Seed: 91574bf8-e8c9-4bec-8dea-a87ea00053df
Journal backup: inode blocks

Cheers,
Fil

P.S. Had to go back to tar... and rewrite my scripts... ugh.

Joined: 20 Dec 2006 Posts: 2

I am also seeing this problem with some /ext3 partitions on a SATA drive. Partiton 1 imaged ok. P2 failed with the "unable to read bitmap ...." message. Later p2 was imaged sucessfully. Later still it did not. P3 seemed to fail every time.

e2fsck -f /dev/sda2 showed no problems. (same for the other partitions)

The version of partimage I was using was 0.6.5beta3.

Is this a new feature of 0.6.5beta3? What other versions are showing this problem?

Joined: 07 Dec 2006 Posts: 2 Location: USA

> Is this a new feature of 0.6.5beta3?
> What other versions are showing this problem?

Clearly, the problem is in earlier versions, I am using 0.6.4. I tried the 0.6.5 beta with no changes. I did see on the linux kernel hacking list that a bunch of changes were made to ext3 in the 2.6.xx kernels. So, the question is: is anyone running 2.4.xx experiencing this problem? It would be good to get this one out of the way as culprit. I looked into the code but it would take getting intimately familiar with ext3 (which I'm not) to see what's going on. I rewrote my scripts to use tar. I still use partimage for ntfs, though :-)

Cheers,
Fil

Joined: 20 Dec 2006 Posts: 2

I went back to 0.6.4 to check and I also see the problem there.

I am using a 2.6 kernel (Ferdora Core 5) and ext3 file system.

Partition size may be significant. The partition where it works is small (/boot).
The partitions where it fails are 10gb and greater.

===
Brian

Joined: 21 Nov 2006 Posts: 2

Pretty crappy :( Still experiencing these problems. I have a feeling I might just have to stop using partimage as well, and just rely on tar or some other archiver because of this nasty issue.

Although I haven't tried this from a 2.4 kernel, I can attest that it happens on sata and ide drives.

I doubt the size is of relevance as I can often 'image' a 200GB partition, as long as it's not the last partition in the partition table. Maybe that has something to do with it.

Regardless, I doubt this will be resolved. Hello tar.

-Daniel

Joined: 02 Feb 2007 Posts: 1 Location: France

I use partimage for a long time with no problem. I come just to meet this problem on a test machine.

I have first installed Fedora Core 6 on a new disk. After testing I have saved the ext3 unmounted partitions hda1 (1Gb), hda2 (1Gb) and hda3 (5Gb) with partimage as usually... No problem!

Then I have installed Fedora Core 5 over the same 3 partitions. The partitions have been formatted ext3 again during the installation process. The OS was operating correctly... Then I wanted to save again the 3 partitions using the same method and now I get "Can't read bitmap block zero from image" with hda1 and hda2. I could save hda3 alone. I have checked the partitions: They are clean...???

Cheers,

Bernard

Joined: 30 Sep 2006 Posts: 1

I discovered after a bit of playing around that this error only seems to occur on partitions created by Fedora's Anaconda installer, which uses Diskdruid I believe. I've created partitons with the help of a live-cd's prior to installation that use parted, I've haven't had any issues cloning these partitions thus far.

Joined: 30 May 2007 Posts: 1 Location: Omaha, Nebraska USA

dans wrote:

Hey guys,

I've searched high and low for a solution to this forsaken problem. Let me give a slight insight as to what it is that I am doing.

<snip>

Greetings!

Is this problem not resolved by

http://www.partimage.org/forums/viewtopic.php?t=420

? [added by edit]

Thanks.

Joined: 16 May 2007 Posts: 1 Location: Minneapolis

Hi,

I am running a 2.4.33.3 kernel for these tests.

I have found that by varying the -V param from 620 to 629 by 1 I wind up with images that either "Block 0" error at the point between "segments" 1 & 2, or work perfectly! Of course, if I do not use -V (or use -V 0) to create one large file, there is no problem.

I can't figure out if the problem is creating the multiple image files, or restoring them.

I have debug logs for the errors (debug=3) if anyone wants them.

[BufferW] image_disk.cpp->read#254: cid: 14336 ; m_qwTotal = 655284224
[BufferW] image_disk.cpp->read#254: cid: 14336 ; m_qwTotal = 655298560
[BufferW] image_disk.cpp->read#254: cid: 14336 ; m_qwTotal = 655312896
[Main] fs_base.cpp->restoreUsedBlocksToDisk#322: CRC = 503088796
[Main] fs_base.cpp->restoreUsedBlocksToDisk#325: dwCheckCount= 65536
[Main] fs_base.cpp->restoreUsedBlocksToDisk#329: BEFORE READING CHK
[Main] fs_base.cpp->restoreUsedBlocksToDisk#338: CHECKING(2619772): check=0 and CRC=65536
[BufferW] image_disk.cpp->read#254: cid: 14336 ; m_qwTotal = 655327232
[Main] fs_base.cpp->restoreUsedBlocksToDisk#322: CRC = 336939501
[Main] fs_base.cpp->restoreUsedBlocksToDisk#325: dwCheckCount= 49152
[Main] fs_base.cpp->restoreUsedBlocksToDisk#287: i = 2620028, m_header.qwBlocksCount = 8193148
[Main] fs_base.cpp->restoreUsedBlocksToDisk#293: CPY: dwCount=256, bUsed=1
[Main] fs_base.cpp->restoreUsedBlocksToDisk#322: CRC = 2616973764
[Main] fs_base.cpp->restoreUsedBlocksToDisk#325: dwCheckCount= 65536
[Main] fs_base.cpp->restoreUsedBlocksToDisk#329: BEFORE READING CHK
[Main] fs_base.cpp->restoreUsedBlocksToDisk#338: CHECKING(2620028): check=0 and CRC=65536
[BufferW] image_disk.cpp->read#254: cid: 14336 ; m_qwTotal = 655341568
[BufferW] image_disk.cpp->read#254: cid: 14336 ; m_qwTotal = 655355904
[Main] fs_base.cpp->restoreUsedBlocksToDisk#322: CRC = 3921196481
[Main] fs_base.cpp->restoreUsedBlocksToDisk#325: dwCheckCount= 65536
[Main] fs_base.cpp->restoreUsedBlocksToDisk#329: BEFORE READING CHK
[Main] fs_base.cpp->restoreUsedBlocksToDisk#338: CHECKING(2620028): check=0 and CRC=65536
[Main] imagefile.cpp->read#409: READ ERROR: dwLength=65536 and dwRes=0 and g_nThreadState=0
[Main] imagefile.cpp->read#427: READ ERROR 2: dwLength=65536 and dwRes=0 and g_nThreadState=0
[Main] imagefile.cpp->read#428: THROW: -96
[Main] exceptions.cpp->CheckArguments#69: WARNING: -96 with wrong argument number (0)
[Main] exceptions.cpp->CExceptions#88: read -> throws: -96
[Main] fs_base.cpp->restoreUsedBlocksToDisk#315: restoreUsedBlocksToDisk: except -96
[Main] fs_base.cpp->restoreFromImage#704: restoreFromImage: -96
[Main] image_disk.cpp->close#274: close -> 655355904
[Main] image_disk.cpp->destroySpaceFile#454: DESTROY SPACE FILE []
[Main] image_disk.cpp->CImageDisk#80: total written: 655355904
[Main] ../../src/shared/exceptions.h->get_szArg1#59: STR=(null)
[Main] interface_base.cpp->showError#37: showError: [Can't read block 0 from image (135702040)]
[Main] main.cpp->main#609:
FINAL ERROR

[Main] main.cpp->main#722:

============= TIME and CPU infos ================
[Main] main.cpp->main#723: Total time:...........26m:16sec
[Main] main.cpp->main#724: User time:............36sec (main=36sec, child=0sec)
[Main] main.cpp->main#727: System time:..........3sec (main=3sec, child=0sec)
[Main] main.cpp->main#730: CPU used:.............2 %
[Main] main.cpp->main#731: Beginning:............ 1183753819 = Fri Jul 6 20:30:19 2007
[Main] main.cpp->main#732: Start copy:........... 1183754217 = Fri Jul 6 20:36:57 2007
[Main] main.cpp->main#733: End:.................. 1183755793 = Fri Jul 6 21:03:13 2007
[Main] main.cpp->main#734:
============= TIME and CPU infos ================

[Main] main.cpp->main#740: End of operation: FAILED