d1.original.partitions not being created on image upload

[aaoyagi]

svn r3562 installed. I’m running into an issue trying to upload a dual boot image with Win8.1 and Ubuntu 14.04. My image settings are as follows:
OS: Linux - (50)
Image Path: /images/15SU
Image Type: Multiple Partition Image - Single Disk (Not Resizable) - (2)
Partition: Everything - (1)
Protected: Unchecked
Compression: 6

When the image process is complete this is what I end up with in my /images/15SU directory:

-rwxrwxrwx 1 root root 0 Jun 16 17:07 d1.has_grub
-rwxrwxrwx 1 root root 1048576 Jun 16 17:07 d1.mbr
-rwxrwxrwx 1 root root 0 Jun 16 17:07 d1.original.swapuuids
-rwxrwxrwx 1 root root 10702305 Jun 16 17:08 d1p1.img
-rwxrwxrwx 1 root root 90732163352 Jun 16 19:28 d1p2.img
-rwxrwxrwx 1 root root 137 Jun 16 19:28 d1p3.img
-rwxrwxrwx 1 root root 20 Jun 16 19:28 d1p5.img

Then when I try to send a download task to a different machine using 15SU as the image, the script complains that it can’t find the d1.original.partitions file and quits out. Should I be using a different Image Type for this?

[Wayne Workman]

Fog works best with single - OS systems.

When you choose the OS type, you’re basically telling fog what sort of partitions to look for and how to do resizing, how to handle processing the upload… Choosing Linux would probably ignore windows partitions, choosing windows would likely ignore linux partitions. See?

But of course, RAW always works… but it’ll be a massive image.

This is an edge scenario… The developers might be able to help you finagle this around, so keep checking back here.

[Tom Elliott]

I’m pretty sure, but could be wrong, d1.original.partitions should only exist in the case of resizable. I’ll take a look at the source to remove the checks if the OS is not resizable.

[aaoyagi]

@Wayne-Workman Thanks for your reply. A little more background here, in case the water wasn’t muddy enough. On a prior FOG install using the Official 1.2.0 release from last summer, or an SVN from very shortly after anyway, r2100s maybe, those were the image settings that I needed to use in order to get a working image that could then be pushed to other workstations in the lab I’m maintaining. I’m sure code has changed significantly in the last year so I have no idea what is and isn’t expected behavior here.

@Tom-Elliott Thanks for checking on it. Should I be/try using Single Disk - Resizable for this case or will that not work given the 4 partitions on the disk?

[Tom Elliott]

It probably won’t work, not because of the number of partitions, but because neither the d1.original.partitions or d1.minimum.partitions files exist.

I just need to look at the code, I have to add back fixparts anyway.

[aaoyagi]

As a test I tried uploading a new image with Single Disk - Resizable as the image type and that definitely didn’t work. It created files, but didin’t pull any of the data from the drive.

@Tom-Elliott Should I give the latest trunk a try?

[aaoyagi]

It occurred to me just now that there is a d1p3 and a d1p5, but no d1p4 which I’m guessing is the ubuntu root partition. It looks like the image may not be uploading properly. Or the upload script isn’t detecting/saving the partitions correctly.

[aaoyagi]

Still having trouble getting a good image. I’ve updated to r3591 and tried to upload an image using the settings from my first post and I get what appears to be a good image:

-rwxrwxrwx 1 root root 0 Jun 23 09:26 d1.has_grub
-rwxrwxrwx 1 root root 1.0M Jun 23 09:26 d1.mbr
-rwxrwxrwx 1 root root 0 Jun 23 09:26 d1.original.swapuuids
-rwxrwxrwx 1 root root 250M Jun 23 09:27 d1p1.img
-rwxrwxrwx 1 root root 14G Jun 23 09:51 d1p2.img
-rwxrwxrwx 1 root root 138 Jun 23 09:51 d1p3.img
-rwxrwxrwx 1 root root 1.4G Jun 23 09:54 d1p5.img

When I try to run a download task on a separate machine it restores grub and the mbr, but doesn’t restore any of the partition data. I saw an error about EBR signature for logical partitions being invalid and then it finishes and reboot to a grub rescue prompt.

[aaoyagi]

Okay changed the partitions on the master to Primary Partitions instead of Logical Partitions and everything seems to be working fine now. I guess logical drives don’t really work well. In any case I’ll mark this solved because the issue has veered wildly from the initial question, which Tom answered for me. Thanks all.