FOG restore only one partition

plegrand

@Sebastian-Roth
i have to capture again before deploy ?

Just to be clearer, here is my configuration :

On my own pxe server(dhcp and tftp) 192.168.151.247
dhcp is configured like that :

 next-server 192.168.151.247;
 filename "pxelinux.0";

then on my tftp server i’ve got pxelinux.0 into the tftp root directory
and
this configuration

LABEL FOG_ETUDIANTS
KERNEL fog/ipxe.krn dhcp && chain http://192.168.39.243/fog/service/ipxe/boot.php?mac=${net0/mac}

192.168.39.243 is the fog ip address
Do i have to put on my tftp server the new ipxe.krn file ?

Tom Elliott

@plegrand you should not have to re upload the image.

plegrand

@Tom-Elliott Hello
Fog 6427 / 4874

here is the tests i made

Restore the station with an old symantec ghost image
List partitions with diskpart

DISKPART> list disk
 Disque ###  Statut      Taille     Libre     Dyn  Gpt
 --------  ---------  -----------  --------   ---  ---
 Disque 0    Connecté     149 GB      0 B

 DISKPART> select disk 0
 Le disque 0 est maintenant le disque sélectionné.

 DISKPART> list partition
 Partition ###  Type              Taille     Décalage
 -------------  ----------------  -------  -----------
 Partition 1    OEM                126 MB    20 KB
 Partition 2    Principale          49 GB   126 MB
 Partition 3    Principale         100 GB    49 GB

Defragmentation of all the partition
On fog create a image :

	default: Windows 2000/XP
	Single Disk - Resizable
	Everything

Assign the new image to the host
On fog create a new capture task for the station as a debug task
Launch the task
Capture works fine
On the server fog :

	d1.fixed_size_partitions
	d1.minimum.partitions
	d1.original.fstypes
	d1.original.swapuuids
	d1p1.img
	d1p2.img
	d1p3.img
	d1.partitions

	cat d1.fixed_size_partitions 
	1:

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

	/dev/sda1 : start=          40, size=      257480, type=de
	/dev/sda2 : start=      257520, size=    31386360, type=7, bootable
	/dev/sda3 : start=   102657680, size=      779520, type=7

	cat d1.original.fstypes 
	/dev/sda2 ntfs
	/dev/sda3 ntfs

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

	/dev/sda1 : start=          40, size=      257480, type=de
	/dev/sda2 : start=      257520, size=   102400160, type=7, bootable
	/dev/sda3 : start=   102657680, size=   209839360, type=7

At reboot, the station stay displaying “Booting…”

Then i try to deploy the image

Create a new deploy task for the host

During the restauration of /dev/sda1, i’ve got the following error message from partclone

Target partition size (132MB) is smaller than source 132 MB. 
Use option -C to disable size checking (Dangerous)

And just after

Image failed to restore and exited with exit code 0 (writeImage)
Args passed /images/test/d1p1 img* /dev/sda1

Then the only solution is to redeploy the old ghost image

Tom Elliott

@plegrand have you tried after updating to the latest.

plegrand

@Tom-Elliott
no
do i have to capture again or just deploy ?

plegrand

@Tom-Elliott hello
i just made the following test with latest version : 6476 / 4895
just create deploy task
same problem

After upgrade, Do i have to put on my own tftp server the new ipxe.krn file ?

Sebastian Roth

@plegrand As Tom said, could you please upgrade to the latest version. He is saying that you don’t need to re-upload. But I’d say it wouldn’t hurt anyway.

You don’t need to update ipxe.krn on your TFTP server if booting the client works fine. The iPXE binary is not related to the error you see AFAIK!

plegrand

@Sebastian-Roth Same problem

Sebastian Roth

@plegrand Please boot that client you tried to write the image to in debug deploy again (schedule a normal deploy task but tick “Schedule task as a debug task” in the advanced settings box just before you hit the button “CREATE DEPLOY TASK FOR …”).

When you get to the shell please run sfdisk -d /dev/sda and post a picture of the output here (we need the exact numbers!!).

plegrand

@Sebastian-Roth

label: dos
label-id: 0x2bd2c32a
device: /dev/sda
unit: sectors

/dev/sda1 : start = 63,         size = 257024,    type = de
/dev/sda2 : start = 257087,     size = 102401024, type = 7, Bootable
/dev/sda3 : start = 102658111,  size = 209841152, type = 7

Sebastian Roth

@plegrand Did you copy&paste the numbers or typed them from the screen? I hope there is no typo in them!

If the figures are correct this is simple maths. The original first partition (as seen further down) starts at sector 40 and ends at 257480. Makes 257440 in total. After writing to the new disk the first partition starts at 63 (which should not be an issue) but ends at 257024. Makes a total of 256961 sectors for the first partition. Slightly smaller than the original one.

I guess our re-sizing logic is still hating those recovery partitions (type=de)!

Sebastian Roth

I think I found where the issue is. Please give me some more time to see why things go wrong…

Sebastian Roth

@plegrand Can you please do a debug UPLOAD task on the original client you pull the image from. You don’t need to do the full upload. I just need to get some information. Run the following command when you get to the shell and post the full output here: blkid -po udev /dev/sda1

You can simply delete the task in the web interface and shutdown that client after you got the information.

plegrand

@Sebastian-Roth

ID_PART_ENTRY_SCHEME=dos
ID_PART_ENTRY_UUID=2bd2c32a-01
ID_PART_ENTRY_TYPE=0xde
ID_PART_ENTRY_NUMBER=1
ID_PART_ENTRY_OFFSET=63
ID_PART_ENTRY_SIZE=257024
ID_PART_ENTRY_DISK=8:0

plegrand

@Sebastian-Roth said:

@plegrand Did you copy&paste the numbers or typed them from the screen? I hope there is no typo in them!

no typo !!

Sebastian Roth

@plegrand Thanks for posting all the details. They were really helpful in finding the issue and being able to replicate this on my test system. Tom and I have been working on a fix and it is up now. Please upgrade to the latest version and re-run the installer! No need to re-upload. Just try deploying to your machine and let us know if things are working.

plegrand

@Sebastian-Roth Hello
I updated fog to the version 4919 / 6527 and i cant deploy image :

Failed to create deployment tasking for the following hosts
You must first upload an image to create a download task

Sebastian Roth

@plegrand That’s a different issue… We’ve seen this reported by another user yesterday. I think @Tom-Elliott is onto it already. Stay tuned.

plegrand

@Sebastian-Roth Hello
then i made the test to deploy. Except the ftp problem (solved for the moment by editing “/var/www/fog/lib/fog/fogftp.class.php”.
There is again a problem :
Now the deployement works fine, i mean no error message from partclone but once deployement finished :
“Error loading operating system”

i made some test :

sfdisk -d /dev/sda
label: dos
label-id: 0x2bd2c32a
device: /dev/sda
unit: sectors

/dev/sda1 : start=          40, size=      257480, type=de
/dev/sda2 : start=      257520, size=   102401024, type=7, bootable
/dev/sda3 : start=   102658544, size=   209841152, type=7

For sfdisk as you can see , the informations are not the same than my older post

blkid -po udev /dev/sda1
ID_FS_SEC_TYPE=msdos
ID_FS_LABEL=DellUtility
ID_FS_LABEL_ENC=DellUtility
ID_FS_UUID=07D9-0C13
ID_FS_UUID_ENC=07D9-0C13
ID_FS_VERSION=FAT16
ID_FS_TYPE=vfat
ID_FS_USAGE=filesystem
ID_PART_ENTRY_SCHEME=dos
ID_PART_ENTRY_UUID=2bd2c32a-01
ID_PART_ENTRY_TYPE=0xde
ID_PART_ENTRY_NUMBER=1
ID_PART_ENTRY_OFFSET=40
ID_PART_ENTRY_SIZE=257480
ID_PART_ENTRY_DISK=8:0

blkid -po udev /dev/sda2
ID_FS_LABEL=OS
ID_FS_LABEL_ENC=OS
ID_FS_UUID=0660C20C60C20303
ID_FS_UUID_ENC=0660C20C60C20303
ID_FS_TYPE=ntfs
ID_FS_USAGE=filesystem
ID_PART_ENTRY_SCHEME=dos
ID_PART_ENTRY_UUID=2bd2c32a-02
ID_PART_ENTRY_TYPE=0x7
ID_PART_ENTRY_FLAGS=0x80
ID_PART_ENTRY_NUMBER=2
ID_PART_ENTRY_OFFSET=257520
ID_PART_ENTRY_SIZE=102401024
ID_PART_ENTRY_DISK=8:0

blkid -po udev /dev/sda3
ID_FS_LABEL=data
ID_FS_LABEL_ENC=data
ID_FS_UUID=86DC8201DC81EC2D
ID_FS_UUID_ENC=86DC8201DC81EC2D
ID_FS_TYPE=ntfs
ID_FS_USAGE=filesystem
ID_PART_ENTRY_SCHEME=dos
ID_PART_ENTRY_UUID=2bd2c32a-03
ID_PART_ENTRY_TYPE=0x7
ID_PART_ENTRY_NUMBER=3
ID_PART_ENTRY_OFFSET=102658544
ID_PART_ENTRY_SIZE=209841152
ID_PART_ENTRY_DISK=8:0

Sebastian Roth

@plegrand Are source and destination machine the same model? Please let us know what kind of hardware you are doing this on. Check the BIOS settings as well. Searching for that error on the internet I found several people who have issues after cloning a machine. See if you can match up the BIOS settings of source and destination on disk geometry. See here:

The most likely solution is that your HD geometry is set wrong… On many motherboards in the BIOS setting for your HD, it is set to AUTO… which sometimes tries to use CHS which is incorrect for most modern computers. Manually set it to LBA instead.

FOG restore only one partition

184

12.0k

17.3k

155.2k