Unable to capture image, previously was able to

[Shadow00Caster]

Server

• FOG Version: 1.3.1-RC-5
• OS: Debian 7 32bit

Client

• Service Version:
• OS: Windows 8.1 64bit

Description

Trying to capture an image of a VM that I was previously able to, now getting:
Fatal Error, unable to find size data out on /dev/sda2. Cmd: ntfsresize -f -i -v -P /dev/sda2

Image is setup as a single disk, resizable, all partitions. Disk has system reserved (default win install) and C partition.

Any help would be appreciated.

[Tom Elliott]

You aren’t the first, and probably won’t be the last. (Hopefully you might be).

I’m taking an approach that is untested a bit, but should fit the bill hopefully.

My change in thought is if that portion is “met”, I will take the partition number and add it to the “fixed size partitions” file. It won’t try to resize the partition and it should get you on to the next partition.

Please install the latest RC (reinstall if you already did install it) and you should have the upload capability back.

Thanks,

[Shadow00Caster]

@Tom-Elliott Did a git pull to latest, installfog.sh failing on Setting up and starting MySQL, nothing changed, worked with RC5.

[Tom Elliott]

@Shadow00Caster I haven’t changed the installer.

[Tom Elliott]

Are you still on the branch dev-branch?

It should look something like:

[root@localhost fogproject]# git branch
* dev-branch
  master
  persistentGroupPlugin
  working-RC-6
[root@localhost fogproject]#

The * denotes which branch you’re currently on.

[Shadow00Caster]

@Tom-Elliott

root@fog:~/fogproject# git branch
* dev-branch
root@fog:~/fogproject#

[Tom Elliott]

@Shadow00Caster Figured I’d add to here so others can follow.

We found that the system was in a really weird state. This state broke the root user password and it was not allowing services to be started properly. Worked together and reset the root user password. The installer still failed and we found the issue was due to how the OS was booting and starting services. It was using init as the service starter, but the command systemctl exists on the system. The service was failing with dbus messages because the systemd side was not what was used to load services on the system.

I’ve added a few checks just to ensure all will be well for the next release cycle.

Essentially I’m now checking three things.

1. Does the systemctl command exist? (command -v systemctl)
2. Is the system booted to use systemd? (ps -p 1 -o comm= | grep systemd)
3. Is the systemctl variable already set?