Confirmed fixed, MBR looks like a much more reasonable 32k now.

Thanks!

I think i found the problem; MYSQL.class.php changed its method to require a valid queryResult from reap_async_query before incrementing the processed counter. I admit to hypothesizing since i’m not intimately familiar with the code, but the return value of reap_async_query is only useful for queries that have return data. If an insert/update/etc query is getting passed in, i think it will always return FALSE - which will cause the process counter to never be incremented, causing an infinite loop.

</speculation>

Is there a debug process where I can show/record the commands that are being executed on the imaged machine? It would make it easier to debug the script.

Thanks.

# fdisk /dev/sda -lu

Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x552e1400

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              63       80324       40131   de  Dell Utility
Partition 1 does not start on physical sector boundary.
/dev/sda2   *       81920    20505243    10211662    7  HPFS/NTFS/exFAT
/dev/sda3        24686592   976771071   476042240    7  HPFS/NTFS/exFAT

Any other thoughts or ideas to try and help debug this?

Also, for reference; minimum partitions:

$  cat d1.minimum.partitions
label: dos
label-id: 0x552e1400
device: /dev/sda
unit: sectors

/dev/sda1 : start=        63, size=     80262,  type=de
/dev/sda2 : start=     81920, size=  20423324,  type=7, bootable
/dev/sda3 : start=  24686592, size=  88663008,  type=7

On the original disk, the partitions are 41.1MB, 10.5GB, and 487GB, respectively along sda[123].

On the fog server, the .img files are 79k, 8.2G, and 17G, respectively.

$ cat d1.original.partitions
label: dos
label-id: 0x552e1400
device: /dev/sda
unit: sectors

/dev/sda1 : start=          63, size=       80262, type=de
/dev/sda2 : start=       81920, size=    20423324, type=7, bootable
/dev/sda3 : start=    24686592, size=   952084480, type=7

I don’t have a d2.original.partitions file.

Hello again,

I’ve progressed beyond making images and have moved to testing out the deployment aspect. I attempted to deploy the image a different laptop (but identically configured - even purchased at the same time), but on the first partition partclone fails with an error

Target paritition size (41 MB) is smaller than source (42 MB).  Use option -C to disable size checking(Dangerous).

Debugging assistance welcome! Where do i look to try and solve this, or what information do you need to help debug?

Thanks!

Edit: This deployment was done using latest trunk (3563); images were crated with 3540

Confirmed fixed, MBR looks like a much more reasonable 32k now.

Thanks!

I think i found the problem; MYSQL.class.php changed its method to require a valid queryResult from reap_async_query before incrementing the processed counter. I admit to hypothesizing since i’m not intimately familiar with the code, but the return value of reap_async_query is only useful for queries that have return data. If an insert/update/etc query is getting passed in, i think it will always return FALSE - which will cause the process counter to never be incremented, causing an infinite loop.

</speculation>

It is happening to me as well. Confirmed that the webserver is completely unresponsive, no matter what fog-specific URL is requested. (The default apache page responds just fine).

Also confirmed the issue was introduced in r3542 (3541 works fine)