Partclone loops

[hdhzero]

Server

• FOG Version: 1.3.0
• OS: Lubuntu 16.04

Client

• Service Version:
• OS: Lubuntu 16.04

Description

I’m using FOG 1.3.0 trying to create an HD’s image. These are the partitions

• swap (primary)
• /dev/sda2 (extended)
• /dev/sda5 (17GB ext4 /)
• /dev/sda6 (21GB ext4 /home)

Partclone started to copy sda5, then it emitted a message saying something like “clone successfull”. Then it started to copy sda6 and when sda6 finished, partclone began again to clone sda5. Now it keeps cloning sda5 and sda6 over and over again. Its been about 2 hours since I started the image creation. Is this the correct behavior?

On the dashboard I can see the storage node slowly growing. Also, when I created
the image, these were the configurations:

OS: Linux 50
Img Type: Single Disk - Resizable
Partition: Everything
Img enabled: yes
Replicate: yes

Also, could someone explain, please, what the options img enabled and replicate are for?

[hdhzero]

@Wayne-Workman You and Tom are right, the second problem was, indeed, a FTP one. I am sorry, but I was in a hurry and reinstalled everything: FOG server and the client to be cloned. Didn’t use extended partitions this time, so I can’t reproduce anymore the first reported error. The good news is that in this new install, everything worked out of the box.

[Wayne Workman]

Image enabled means the image is allowed to be deployed. Replicate means the image is allowed to replicate to all members of it’s storage group, and to all storage groups it’s assigned to.

I think the extended partition is why this is happening. If you could remake the image without extended partitions, it would probably work fine, just continue to use Ext4.

[hdhzero]

@Wayne-Workman Oh, this is bad… I’ve spent all the morning configuring the machine to then clone it with FOG

[Quazz]

@hdhzero Unless you need to support legacy/MBR for some reason, I’d recommend making a UEFI image with GPT partition table so you don’t have to create extended partitions.

[Sebastian Roth]

@hdhzero Can you please get us a full partition table listing? I’ve never seen a loop happening and we better find out what this is about. So please boot into a debug image upload session (like you schedule a normal task but select debug just before you hit “Create Task” select the debug checkbox).

When you get to the shell run sfdisk -d /dev/sda. Please post a picture here.

[Wayne Workman]

Please do what Sebastian said.

[hdhzero]

@Sebastian-Roth

Here is the output of sfdisk -d /dev/sda:

[Fri Sep 30 root@fogclient /]# sfdisk -d /dev/sda
label: dos
label-id: 0xa9ce9327
device: /dev/sda
unit: sectors

/dev/sda1 : start=        2048, size=     3997696, type=82, bootable
/dev/sda2 : start=     4001790, size=   308578306, type=5
/dev/sda5 : start=     4001792, size=    58591232, type=83
/dev/sda6 : start=    62595072, size=   249985024, type=83

[Sebastian Roth]

@hdhzero Sorry for the late reply. Couldn’t make it any earlier. From what I can see from the output the partition table is perfectly fine. I cannot imagine this causing a loop. Are you able to reproduce this issue again or was it happing only once?

[hdhzero]

@Sebastian-Roth I can reproduce it. I’ve tried to clone three times then I gave up. I don’t know if I should have mentioned earlier, but I am using FOG + DNS proxy. Currently I am trying to clone a Windows machine, but at the last moment, it fails saying that it couldn’t update database. Perharps there is a misconfiguration that I am missing?

[Tom Elliott]

@hdhzero Do you mean this is where it’s “looping”? That the system reboots, then tries to run the upload/download process after again and again? See, as I understood it, the “looping” was happening without any reboots.

[Tom Elliott]

Most often, the issue to capture (where it cannot update the database) it is the FTP user and password not matching for the node it’s uploading to.

Please run through:

https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP

[hdhzero]

@Tom-Elliott Your initial thought was correct: when trying to clone the Linux machine, the partitions were being cloned over and over again, without rebooting. Now, with the Windows machine, it tries to clone, it emits the message saying that the clone was successful, then it warns that couldn’t update database. Then it reboots and tries to clone again.

[Wayne Workman]

@hdhzero Tom is still correct about this new error. That’s most usually FTP credentials being wrong. Look through the link he posted.

[hdhzero]

@Wayne-Workman You and Tom are right, the second problem was, indeed, a FTP one. I am sorry, but I was in a hurry and reinstalled everything: FOG server and the client to be cloned. Didn’t use extended partitions this time, so I can’t reproduce anymore the first reported error. The good news is that in this new install, everything worked out of the box.

[Sebastian Roth]

@hdhzero Thanks heaps for letting us know. I am kind of relieved that this thing is solved.

[Tom Elliott]

@Sebastian-Roth I have a feeling the “looping” without reboot actually “was looping with reboot” it was just a matter of “timing” between when it restarted due to failure and starting gathering the data itself.

This particularly so considering nothing in the init’s changed in the time the issue occurred and when the updates happened.