Uploading image breaks source machine, XP

neodawg

Trying to upload an XP image from a Dell Optiplex 740 to fog (7981). The whole upload process goes perfect and no issues.

After its done the original source computer doesn’t boot back to windows. I have tried loading the XP disk and doing a fixmbr
and fixboot. That didn’t fix the installation either. I think also tried redeploying the just uploaded image and that didn’t work either.

I have an old partimage image that I am able to successfully deploy.

I understand that XP is no longer supported and if you choose not to fix this I understand, just passing the information along.

EDIT:
Doing further testing, I am able to view the files on the non booting drive just fine. So the data is still readable, the MBR must be what is getting goofed.

Sebastian Roth

@neodawg Thanks a lot for reporting. We are trying hard to support all the various partition layouts that people have out there. I guess we can fix yours as well. Especially as you seem to be able to reproduce this issue. We just need more information from you:

Image type? (resizable or non-resizable)
picture or listing of ls -al /images/<imagename> on the FOG server
content of /images/<imagename>/d1.partitions
upload binary file /images/<imagename>/d1.mbr
Plus can you please deploy the old working image to it and then schedule a debug upload (normal upload but tick the checkbox for debug just before creating the task), then run sfdisk -d /dev/sda (take a picture), start uploading with fog command and do another sfdisk -d /dev/sda directly after it finished - again take a picture.

I am sure we can figure this out easily if you can give us all the requested information.

neodawg

Resizeable - forgot to mention that

Here is the info, listed in the order you requested.

Here is 2 definitions that I attempted an upload to:

[root@fog images]# ls -al Optiplex740/
total 3504244
drwxrwxrwx 2 root root       4096 Jun  4 01:09 .
drwxrwxrwx 8 root root       4096 Jun  6 00:23 ..
-rwxrwxrwx 1 root root          1 Jun  4 01:03 d1.fixed_size_partitions
-rwxrwxrwx 1 root root      32256 Jun  4 01:04 d1.mbr
-rwxrwxrwx 1 root root        132 Jun  4 01:04 d1.minimum.partitions
-rwxrwxrwx 1 root root         15 Jun  4 01:03 d1.original.fstypes
-rwxrwxrwx 1 root root          0 Jun  4 01:03 d1.original.swapuuids
-rwxrwxrwx 1 root root 3588280852 Jun  4 01:09 d1p1.img
-rwxrwxrwx 1 root root        132 Jun  4 01:03 d1.partitions
[root@fog images]# ls -al Opti740/
total 3251564
drwxrwxrwx 2 root root       4096 May 15 23:28 .
drwxrwxrwx 8 root root       4096 Jun  6 00:23 ..
-rwxrwxrwx 1 root root          1 May 15 23:21 d1.fixed_size_partitions
-rwxrwxrwx 1 root root      32256 May 15 23:23 d1.mbr
-rwxrwxrwx 1 root root        132 May 15 23:23 d1.minimum.partitions
-rwxrwxrwx 1 root root         15 May 15 23:21 d1.original.fstypes
-rwxrwxrwx 1 root root          0 May 15 23:21 d1.original.swapuuids
-rwxrwxrwx 1 root root 3329538183 May 15 23:28 d1p1.img
-rwxrwxrwx 1 root root        132 May 15 23:21 d1.partitions
[root@fog images]#

[root@fog Opti740]# cat d1.partitions 
label: dos
label-id: 0x0003307f
device: /dev/sda
unit: sectors

/dev/sda1 : start=          63, size=   156249937, type=7, bootable
[root@fog Opti740]#

0_1465271179541_d1.mbr

Before picture

After picture

If you need anything else let me know.

Sebastian Roth

@neodawg Things just don’t add up for me. Looking through the files over and over I see things that just don’t make sense to me:

output of sfdisk in before and after picture match exactly - I doubt that this is the machine that fails to boot XP - see my comment below
label-id in d1.partitions and d1.mbr match (good!) but are different to those in the pictures

Rereading that I wrote I think I might not have been clear enough in my instructions:

Plus can you please deploy the old working image to it and then schedule a debug upload (normal upload but tick the checkbox for debug just before creating the task), then run sfdisk -d /dev/sda (take a picture), start uploading with fog command and do another sfdisk -d /dev/sda directly after it finished - again take a picture

What I meant is, deploy using the old image to you have a working Windows XP. Boot once or twice to make sure everything works. After that schedule a debug upload with your new FOG server and do the before/after sfdisk stuff. Did you do it this way?

PS: Moving this to bugs as I am pretty sure this is something in the code. At least from what I have seen so far.

neodawg

I pushed out the good image
Then boot it
then rebooted to debug upload
I am obviously uploading to a different image on fog as to not wipe out my working image.
The pictures are of before and after, I noticed that they matched as well.

So to further clarify, I pushed down an old partimage of xp i have, then i change the image on the host to the new one, rebooted client after successful boot, then scheduled the upload-debug, ran sfdisk took a pic, imaged it all the way, then ran sfdisk again and took a pic. after rebooting the client it no longer booted and hung on the GRUB screen, doesnt matter if I skip PXE or not, it will no longer boot.

I hooked up the failed booting drive to another pc and could see and read the files on the hard drive just fine.

What sort of logs or information would you like from me? video of my actions and the image process?

EDIT: I will try a multiple partition image upload tonight and see if that works. I guess the next step would be to try a new xp install and upload that.

Sebastian Roth

@neodawg Thanks for the detailed description of the steps you took. Please give me a little more time to try and reproduce this issue in a VM. Will get back to you soon.

Tom Elliott

For what it’s worth I have an XP VM that I have tested both upload and download. I’m unable to reproduce on current trunk. I’ll read more and see if I can find the scenario directly.

Wayne Workman

@neodawg said in Uploading image breaks source machine, XP:

I guess the next step would be to try a new xp install and upload that.

In my opinion this is your best option.

neodawg

I wipe out the partitions and loaded XP from CD:

Using build 8088

Single partition upload: breaks source install
multi part upload: works

Tested the partimage image i have been using:

single partition upload: breaks source install
multi partition upload: works

Tom Elliott

@neodawg XP normally defaults to a single partition using the whole disk. Is this not the case in your image? I still cannot replicate. The only thing I can think it might be is the upload portion isn’t resetting the boot flag on upload but download tasks use the same expanding item as upload when the image is complete writing.

Sebastian Roth

@neodawg Thanks for the update on this! I will do some more testing in the next days.

neodawg

@Tom-Elliott I was more so meaning that I had blown away any factory restore partitions. I have no idea why it doesn’t work, the whole upload process appears to work fine.

JJ Fullmer

@Sebastian-Roth Might this person be having the same problem I was having? https://forums.fogproject.org/topic/7404/old-computer-asus-eeetop-all-in-one-touchscreen-mbr-fails-to-restore-after-imaging-task/25
It sounds like a similar issue

Sebastian Roth

@neodawg I am very sorry for taking such a long time!

Same as Tom said I cannot replicate this issue. I got a WinXP VM, booted it in virtualbox just fine. In disk management I see one single partition. Then uploaded a image. Before and after the upload I have this disk layout:

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

/dev/sda1 : start=          63, size=   266116662, type=7, bootable

Looks pretty similar to what you have. After the image upload I can boot into the Win XP OS without an issue.

Are you absolutely sure the kernel and initrd was updated when you installed trunk version 8088? Please post a listing of the following command: ls -al /var/www/fog/service/ipxe/{bzImage*,init*}

Can you do me a favour? Please run the following commands on debug upload and post the files (sda_before.gz and sda_after.gz) in the forum so I can do a binary diff and hopefully see what changed:

dd if=/dev/sda bs=512 count=4096 | gzip > sda_before.gz
fog
...
...
dd if=/dev/sda bs=512 count=4096 | gzip > sda_after.gz
mount -o nolock x.x.x.x:/images/dev /mnt
mv sda_* /mnt
umount /mnt

Put in your FOG server IP instead of x.x.x.x and you should find the files in /images/dev/ on your server.

PS: @JJ-Fullmer Don’t think this is related. Here we have a single partition and XP while you have more than one partition with the bootable flag flapping.

Tom Elliott

Any way to ask if you could try reuploading a working XP image and see if it still breaks booting? After an update of course.

neodawg

Sorry for the delay, I ran out of time on this and just used multiple partition single disk method. It sounds like you guys are not able to replicate the problem, so it must be an issue with my server/client pc. If I get time again later I will try to replicate the issue with a new install of XP.

Thanks for the help

Tom Elliott

@neodawg I have solved this thread for now. Please keep us posted if you’re still running into this issue. I’m fairly confident fog can do this with little problem, but I can not know all the possible scenarios that might present this problem.

Uploading image breaks source machine, XP

150

12.1k

17.3k

155.3k