Hey Tom, I appreciate you following back up on this. Currently, I do have a drive that has failed in the LVM and am waiting on my boss for a replacement.
However, I don’t think that was the problem. As soon as I get a replacement drive, I’ll finish the upgrade process from Ubuntu 12.04 LTS to 14.04 LTS and from FOG 0.32 to 1.2.0. (The first one of these temporarily caused GRUB to break…)
Thanks again,
Chuck
When restoring a single disk, multiple partition image, the 2nd (main OS win 7 32-bit) partition shows to be 90 GB on the screen, when the entire image file is only 13 GB. The problem is that it takes at least an hour and a half to restore that one partition.
It seems that the data streaming across to the drive and then written to the drive is much faster the the process which seems to write zeros to the empty space in that partition. (Also, the network traffic seems to drop off during this process.)
Is there any way to speed this up? On my machines with 500 GB drives, it’s taking something like 6 hours to image.
Thanks,
Chuck
Hey Tom,
Yes, the partition is one that HP sticks on there from the factory. My department waivers back and forth on whether or not to keep them.
Surely, Clamav can be configured to either skip all sda4 partitions, or to skip all non-NTFS partitions, but scan the rest.
Thanks,
Chuck
When attempting to run the anti-virus from the task management advanced options, I get the following error from a little 100 MB Fat32 partition.
[IMG]http://i44.tinypic.com/11htquo.jpg[/IMG]
Any suggestions?
(Ubuntu 12.04.3 LTS; fog 0.32; on VMware)
Thanks,
Chuck
I’m uploading an image right now. Built a new simple (no bonding, no LVM, simple partitioning with default /images) VM Ubuntu 12.04.2 LTS with Fog 0.32 on a 200 GB drive.
The really funny thing is, it still reads:
“Available space for image:…1.66 GiB = 1778888704 bytes”
Hey Tom, I appreciate you going through all the steps with me. I just wanted to rule out something silly that I may have missed. I’m currently waiting to see if I can establish another storage node.
-Chuck
pvck & vgck ? Right now, I replaced one of the drives on sda5, and one of the drives on sdb1. They will need some time to rebuild.
Yes (/storage/images) is part of the LVM.
Here’s the output:
root@kiri1:~# pvdisplay
— Physical volume —
PV Name /dev/sdb1
VG Name kiri2
PV Size 1.36 TiB / not usable 1.29 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 357587
Free PE 17587
Allocated PE 340000
PV UUID glQE6b-qwEH-LQo3-k2an-owfH-OPvy-PXnj1I
— Physical volume —
PV Name /dev/sda5
VG Name kiri1
PV Size 136.46 GiB / not usable 2.00 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 34933
Free PE 6
Allocated PE 34927
PV UUID GUvasn-41Eh-ozeI-bZnZ-UaXV-HsYC-r1C9MI
root@kiri1:~# vgdisplay
— Volume group —
VG Name kiri2
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 2
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 1
Act PV 1
VG Size 1.36 TiB
PE Size 4.00 MiB
Total PE 357587
[COLOR=#ff0000]Alloc PE / Size 340000 / 1.30 TiB[/COLOR]
[COLOR=#ff0000]Free PE / Size 17587 / 68.70 GiB[/COLOR]
VG UUID Agux9x-QG3h-O5Gg-WZrc-wuDh-4oGO-twHaDg
— Volume group —
VG Name kiri1
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 3
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 2
Open LV 2
Max PV 0
Cur PV 1
Act PV 1
VG Size 136.46 GiB
PE Size 4.00 MiB
Total PE 34933
Alloc PE / Size 34927 / 136.43 GiB
Free PE / Size 6 / 24.00 MiB
VG UUID NRCufd-StrG-CQb0-87bS-2ehH-7Yea-PSMhKM
root@kiri1:~# lvdisplay
— Logical volume —
LV Name /dev/kiri2/storage
VG Name kiri2
LV UUID 75YgXN-ucDL-pgvA-E6lm-h6LK-sSTz-urI94a
LV Write Access read/write
LV Status available
LV Size 1.30 TiB
Current LE 340000
Segments 1
Allocation inherit
Read ahead sectors auto
— Logical volume —
LV Name /dev/kiri1/root
VG Name kiri1
LV UUID 2Z2aY7-qkTk-gu1y-j8qt-x9gO-IObv-f7Ht3M
LV Write Access read/write
LV Status available
LV Size 130.86 GiB
Current LE 33499
Segments 1
Allocation inherit
Read ahead sectors auto
— Logical volume —
LV Name /dev/kiri1/swap_1
VG Name kiri1
LV UUID u4ZjMQ-j9IO-n8Pt-GP5p-uGzv-R76q-HQmt0f
LV Write Access read/write
LV Status available
LV Size 5.58 GiB
Current LE 1428
Segments 1
Allocation inherit
Read ahead sectors auto
root@kiri1:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/kiri1-root 129G 3.0G 120G 3% /
udev 5.9G 4.0K 5.9G 1% /dev
tmpfs 2.4G 336K 2.4G 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 5.9G 0 5.9G 0% /run/shm
/dev/mapper/kiri2-storage 1.3T 141G 1.2T 11% /storage
/dev/sda1 228M 47M 170M 22% /boot
Thanks, Tom! That may very well be the problem. It appears I’m getting conflicting data…
vgdisplay shows only 68.70 GB free, while df -h shows 1.2 T available.
-Chuck
Hey Tom,
Yes, I do have everything pointing to /storage… actually /storage/images, and when I try to create new images, the new files are written there. For example, when creating the all disk image you suggested it did the following:
/storage/images/4300AllDisk contains: d1.mbr, d1p1.img, d1p2.img, d1p3.img, d1p4.img
The only thing is that d1p2.img is only 2G for a 456.7 G partition.
(I’ve checked /images and the only files there are the /dev directory and the .mntcheck file)
.mntcheck is present in /storage/images and set to 777 root:root
Oh, and /etc/exports looks ok to me with:
/storage/images *(ro,sync,no_wdelay,insecure_locks,no_root_squash,insecure)
/storage/images/dev *(rw,sync,no_wdelay,no_root_squash,insecure)
Thanks again,
Chuck
I’ve checked the disks, and they look good. /storage shows 1.2T Available (and / shows 120 G available)
Somehow, the system doesn’t register what’s available. Any ideas where to look on the server? I’ve already looked up the Storage Management -> All Storage Nodes and double checked those settings, along with the config in /opt/fog/service/etc/config.php and /var/www/fog/commons/config.php.
Would the memory_limit, post_max_size, and upload_max_filesize all set at 1900M in /etc/php5/apache2/php.ini cause a problem? (I tried to image a 325 G drive today and I still ran into a problem…)
Thanks,
Chuck
Yes, Tom, I think that is part of the problem. I’ve looked at the server settings, but I don’t see where it’s misconfigured. The strange thing is that previously I didn’t have any problems; it’s worked great for more than 18 months or so. I guess I got smacked by an update or two.
-Chuck
Actually, the “Image file size” continues to grow in size. Just did the all disk option, same (similar) results.
It’s a WD 500 GB SATA3 6 Gb /16 MB Cache (WD5000AAKX) and looks like a regular run of the mill platter to me.
The only thing that looks odd to me is the Available space for image:… 1.66 GiB
I’m not sure how big the image file will be. The drive is a 500 GB drive. The partitions are as follows:
1 - 100 MB System
2 - 456.70 GB NTFS
3 - 8.86 GB HP Recovery
4- 100 MB
I have 1.2 TB available on the server.
Hello all,
I’m running Fog 0.32 on Ubuntu 12.04.2 LTS, and I’m trying to take a full disk image of a HP 4300 workstation. However, when it gets a minute or two into the second partition (the 500 GB windows 
drive), I get the error message:
pigz abort write error on <stdout>
Any suggestions would be greatly appreciated!
Unfortunately, that did not fix the problem.
I’m seeing the same thing in my log files.