Server

• FOG Version: 1.3.0
• OS: Ubuntu 16.04.1 LTS

Client

• Service Version: Debian Lenny
• OS: Debian lenny (any modern Linux with virtio block driver)

Description

During Image Creation or Image Restore disks are not found if using paravirtual drivers (virtio).

When a VirtualMachine uses VirtIO (KVM/VMware) or (presumibily) XEN vbd disk, during capture/deploy process fog reports this error: “Cannot find disk on system (getHardDisk)”

I have see the code and I think it could be fixed adding the next Major numbers to the lsblk filter: 202(Xen) and 253 (VirtIO)

So, the code will be something like this:

cat fogproject/src/buildroot/package/fog/scripts/usr/share/fog/lib/funcs.sh
...snip...
getHardDisk() {
    [[ -n $fdrive ]] && hd=$(echo $fdrive)
    [[ -n $hd ]] && return
->>> local devs=$(lsblk -dpno KNAME -I 3,8,9,179,202,253,259 | uniq | sort -V) <<<-
    disks=$(echo $devs)
    [[ -z $disks ]] && handleError "Cannot find disk on system (${FUNCNAME[0]})\n   Args Passed: $*"
    [[ $1 == true ]] && return
    for hd in $disks; do
        break
    done
}

Support for Rescue Imaging (force and rescue partclone.dd options) will be great, so you can generate Rescue Images from failing harddrives (or corrupted FS) for posterior analisys (ex. testdisk / photorec processing)

I propose add this option in Image Management (as image type, maybe RAW RESCUE??) or in Create Capture task as additional option.

Why in Create Capture task? Figure you try to Image capture a server and it fails because there is a Phisical Hard Disk problem, after that, you could create another capture task with RAW Recue (to keep reading after disk read error) and send it to affected server without change image definition…

NOTE: Adding a Warning for this option will be nice, something like: “Rescue Images are intended for Corrupted FS or Physically Failing Disks (it forces continue reading after disk read errors). This process may be SLOW and may GENERATE AN INCONSISTENT IMAGE!!!”

+1
Great!!

Hi all,

Thank you @Tom-Elliott

@Quazz
IMHO, This option is not intended for default use case.

This sholud be optional and maybe discouraged/Expert feature (Maybe showing a warning about posible issues, data loss or image corruption…)

Typical Scenario:
In the past if you fsck ext2 or ext3 with different kernel or fsprogs versions, this tends to fix existent issues in older versions but inexistent in new ones or viceversa. (call it bug, call it new feature)

Real Case scenario: https://bugzilla.redhat.com/show_bug.cgi?id=491385

This FR is intended to make life easier, because yesterday I shutdown a older linux (it shutdown Ok) for capturing Image with Fog and I had had to reboot it in rescue mode and fsck / FS because of partclone: “extfsclone.c:bitmap free count err” error.

If fog could this for us, and it have a relative recent kernel and e2fsprogs version(the newer, the better…), whats the problem?

I always can automatize fsck all FS outside fog, but i thought this could be a feature useful to share with others…

Great!!
I did not know about this feature…
You can close or resolve this FR or if someone tells me how I will proceed to cancel this.

Hi all,

I was using Clonezilla/DRBL for some time and it have an option very convenient for Windows imaging named “rm-win-swap-hib”

rm-win-swap-hib: Removes the page and hibernation files in Windows partitions if exists (NTFS / FAT). This speed up Image creation and restore procces.

Skipping those files may speed up cloning / restore process without causing any harm plus smaller final image size.

You could check the Clonezilla script to get an idea about how this works:
src: https://github.com/stevenshiau/clonezilla/blob/master/sbin/ocs-rm-win-swap-hib

NOTE: delete page and hibernation files should be secure, but sometimes this files may be necessary (for example, if system go to hibernation instead of shutdown… etc)

Support for Rescue Imaging (force and rescue partclone.dd options) will be great, so you can generate Rescue Images from failing harddrives (or corrupted FS) for posterior analisys (ex. testdisk / photorec processing)

I propose add this option in Image Management (as image type, maybe RAW RESCUE??) or in Create Capture task as additional option.

Why in Create Capture task? Figure you try to Image capture a server and it fails because there is a Phisical Hard Disk problem, after that, you could create another capture task with RAW Recue (to keep reading after disk read error) and send it to affected server without change image definition…

NOTE: Adding a Warning for this option will be nice, something like: “Rescue Images are intended for Corrupted FS or Physically Failing Disks (it forces continue reading after disk read errors). This process may be SLOW and may GENERATE AN INCONSISTENT IMAGE!!!”

Hi all,

I was using Clonezilla/DRBL for some time and it have an option very interesting for FS imaging.
They call it fsck-src-part-y, basically it FSCK the FS before image creation.
(src: http://drbl.org/faq/fine-print.php?path=./2_System/108_bitmap_free_count_err.faq )

NOTE Adding a Warning for this option will be nice, something like this: FSCK FS from non-native OS may CAUSE DATA CORRUPTION!!!

UNIX / FAT FS may be something like:
fsck -f -y /dev/sda1

NTFS FS may be something like:
ntfsfix /dev/sda1

Maybe could be good idea add clear dirty flag (Dangerous!):
ntfsfix -d /dev/sda1

This is interesting because sometimes you have to image a far far away server that not umount FS cleanly or there is a version difference between Kernel/FS utilities from SO (older) and FOG (newer)

For example in ext3 is typical to have this partclone error when FS was not cleanly umounted:

 calculating bitmap..please wait..extfsclone.c:bitmap free count err, free:25457320 ?

The solution is reboot and FSCKd affected FS, then reboot and PXE boot again.

Imagine you have to do this for 10 or 100 PC with this issue…

I propose add this option in Image Management or in Create Capture task,.

Why in Create Capture task? Figure you try to Image capture a server and it fails, after that, you can create another capture task with auto FSCK option active and send it only to affected servers without change image definition…

I have open Pull Request #152 in github
https://github.com/FOGProject/fogproject/pull/152

@george1421, +1 in github PR are welcome…

Server

• FOG Version: 1.3.0
• OS: Ubuntu 16.04.1 LTS

Client

• Service Version: Debian Lenny
• OS: Debian lenny (any modern Linux with virtio block driver)

Description

During Image Creation or Image Restore disks are not found if using paravirtual drivers (virtio).

When a VirtualMachine uses VirtIO (KVM/VMware) or (presumibily) XEN vbd disk, during capture/deploy process fog reports this error: “Cannot find disk on system (getHardDisk)”

I have see the code and I think it could be fixed adding the next Major numbers to the lsblk filter: 202(Xen) and 253 (VirtIO)

So, the code will be something like this:

cat fogproject/src/buildroot/package/fog/scripts/usr/share/fog/lib/funcs.sh
...snip...
getHardDisk() {
    [[ -n $fdrive ]] && hd=$(echo $fdrive)
    [[ -n $hd ]] && return
->>> local devs=$(lsblk -dpno KNAME -I 3,8,9,179,202,253,259 | uniq | sort -V) <<<-
    disks=$(echo $devs)
    [[ -z $disks ]] && handleError "Cannot find disk on system (${FUNCNAME[0]})\n   Args Passed: $*"
    [[ $1 == true ]] && return
    for hd in $disks; do
        break
    done
}