Dell E6410 - Solid State Drive (SSD) Compatibility

[george1421]

@Omanimous said:

Multiple Partition - Non Resizable and while that is busy uploading I will debug.

If you get this format to work, I have a script you can add to the setupcomplete.cmd that will expand the drive to the size of the physical disk if you need it. I had to use this method before moving to the trunk which now solidly supports resizeable disks.

[Sebastian Roth]

@Omanimous said:

Error: Can't have a partition outside the disk!

This is not a SSD issue at all AFAIK! Your source disk is larger than the destination disk I suppose… You need to set image type to resizable and capture a new image from the source disk!

[Omanimous]

@Sebastian-Roth See, the issue with that is the source disk is smaller than the SSD, and the image type was already set to resizable.

[Sebastian Roth]

@Omanimous Well, the fdisk output is telling a different story:

Disk /dev/sda: 119.2GiB, 128035676160 bytes, 250069680 sectors
...
Sector size (logical/physical): 512 bytes / 512 bytes
...
/dev/sda2               616448    488392703       243008128      7 HPFS/NTFS/exFAT

Your current disk (the SSD I suppose) has 250069680 sectors (multiplied by 512 byte sector size ~ 120GiB). But the partition sda2 which was created by dumping the d1.mbr file (MBR including the partition layout) to your SSD ends on sector 488392703 (multiplied by 512 byte sector size ~ 233GiB). So either your source disk was actually larger or it used a smaller block size (never ever seen this! Not talking about file system cluster size or something but actual disk block size). Please upload /images/DLE6410TU/d1.mbr here in the forum and I might be able to find out a little more.

image type was already set to resizable

What do you mean by this? From all the outputs (logs and files in /images/DLE6410TU/) this is NOT a resizable image. If you change image type you always need to re-upload/capture the image again!!

[Omanimous]

@Sebastian-Roth I promise you, while I am wrong about the source disk being smaller (It’s from a 250 GB hard disk to a 128 GB SSD, but even if that is the case I make for certain that any Non-Resizable Images, that were done in the past, were shrunk down as far as they possibly could before uploading,) but I one-hundred percent promise you that it was originally set to Single Disk - Resizable (1).

Reply 4:

Disk Structure: Single Disk - Resizable. (I am using this one, but I have also seen in a few other posts about it not having too much of an effect.)

I can verify this, because after we upgraded to 1.2.0, I began trying out the Resizable images and loved them. From then on I have done nothing but Resizable.

[Tom Elliott]

@Omanimous The post this is replied to shows the issue.

In resizable images, you should have a d1.partitions (maybe d1.partitions.original) and d1.minimum.partitions file.

These are missing from the ls -l you gave us. You only have three files (d1.mbr, d1p1.img d1p2.img).

This is why they’re not resizing properly. This particular image was uploaded either as non-resizable OR something else occurred during the upload process.

[Sebastian Roth]

@Omanimous Well, I am not sure what this means now? Tom already pointed out what is wrong with that image… So what happens if you set the type back to resiable and re-upload the whole image from the source disk??

[Omanimous]

@Sebastian-Roth I’ll double check. I have a computer ready to be sent up.

I will, using an HDD:

• Create a Non-Resizable test image shrunken to a 60GB partition.
• Create a new Resizable test image with the drive expanded all the way out.

@Tom-Elliott I see what you mean about the ls -l now. I double checked another image that is resizable and it has:

[root@fog images]# ls -la DO755U
total 14612492
drwxrwxrwx   2 root root        4096 Feb 17 14:05 .
drwxrwxrwx. 57 fog  root        4096 Mar 16 10:21 ..
-rwxrwxrwx   1 root root           2 Feb 17 14:03 d1.fixed_size_partitions
-rwxrwxrwx   1 root root          15 Feb 17 14:03 d1.original.fstypes
-rwxrwxrwx   1 root root         259 Feb 17 14:03 d1.original.partitions
-rwxrwxrwx   1 root root           0 Feb 17 14:03 d1.original.swapuuids
-rwxrwxrwx   1 root root     8588271 Feb 17 14:05 rec.img.000
-rwxrwxrwx   1 root root 14954576482 Feb 17 14:44 sys.img.000
[root@fog images]#

I am very positive that it was resizable, but I’ll stop dwelling on that and let you know how this works after I send the images up and down.

[Omanimous]

Well, now I feel dumb.

I don’t get it:

• Took the image fine when going from an HDD-to-SSD non-resizable.
• Took the image fine when going from an HDD-to-SSD resizable.
• Took the image fine when going from an SSD-to-SSD resizable.

Something messed up some where and now I am feeling that it was user error (I AM STILL SAYING IT WAS RESIZABLE!) when I originally made the image, but it just doesn’t make sense.

I mean, technically speaking if it was a non-resizable image, then it wouldn’t be an out of partition thing because the very first time I made an image for these computers was with the one going from a 128GB SSD to a 128GB SSD (without knowing the SSD was my source disk.) Why it works now, I don’t know.

I even tested going from a resizable image shot down to the SSD, which was then shot up to a test image, then shot right back down to that computer, and it works. The only possible thing left to try, that would still probably yield it working fine, is uploading from an SSD, downloading to a HDD, and uploading again, and then downloading to an SSD - I did this before, but it just doesn’t make sense to go back and test it if the other ones have worked.

@Tom-Elliott @Sebastian-Roth @george1421 I don’t know, if nothing else thanks for showing me something new with FOG I didn’t know (debug and image structure.)

[george1421]

@Omanimous Without knowing the exact details. A 128GB disk (ssd or hdd) from two different manufacturers are usually different sized down to the byte level. So in theory if your source disk is one byte larger than your destination disk a non-resize FOG image will fail.

I can say for my reference image (which I deploy to all hosts), I create on a VM with a 40GB hard drive. That way I’m assured it will deploy to all hardware on my campus. For win10 I use a 60GB reference image.

With FOG 1.2.0 I used non-resizable and then let windows expand the disk. With the 1.2.0 trunk build FOG expands the disk now. I still use a 40GB reference image for Win7. So I always go smaller to larger when the image is deployed.