Dell E6410 - Solid State Drive (SSD) Compatibility
-
@Omanimous George has definitely brought up some good questions. Some answers I might be able to give by reading between the lines of what you posted.
Version of FOG seams to be 1.2.0 by what I see from the output posted (FOG trunk is talking a lot more!). As well I am pretty sure the image type is set to ‘Multiple partitions - single disk’.
My guess if that the tool used by FOG 1.2.0 to enumerate partition information is somehow not happy to get the information from the SSD. This is probably why you don’t see the partclone screen at all. To see if this is the case please boot up that client you tried to put the image on SSD in debug (Host -> Basic Tasks -> Debug) and run the following command
fogpartinfo --list-parts /dev/sdaIf if shows you a proper partition listing (which I doubt!) then we need to have a closer look at your captured image. As George said: Please post what you get from
ls -al /images/DLE6410TU. Otherwise let us know if you see an error (exact message) and maybe try to get a listing withlsblk(not exactly sure if this tool was part of FOG 1.2.0).PS: undionly.(k)kpxe should not play any role in this! Changing ‘/dev/sda’ to something different will only work if your SSD is not recognized as ‘/dev/sda’
-
[root@fog images]# ls -al /images/DLE6410TU total 17997404 drwxrwxrwx 2 root root 4096 Mar 16 09:10 . drwxrwxrwx. 57 fog root 4096 Mar 16 10:21 .. -rwxrwxrwx 1 root root 512 Mar 16 09:10 d1.mbr -rwxrwxrwx 1 root root 8566104 Mar 16 09:10 d1p1.img -rwxrwxrwx 1 root root 18420750512 Mar 16 10:21 d1p2.img [root@fog images]#Should also point out the Server is running on CentOS 6.7 (Final).
- FOG Version: 1.2.0 Stable Release (Department a little too scared to rely on beta.)
- 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.)
- We’re using undionly.kkpxe, not undionly.kpxe - we upgraded a few months back and .kkpxe was the one most of our machines liked.
I will take a look at the debug after in a while and post the results here. Currently building an image to test the Multiple Partition - Non Resizable and while that is busy uploading I will debug.
Update – 2: Editing again for
lsblk[root@10 /]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 119.2G 0 disk |-sda1 8:1 0 300M 0 part `-sda2 8:2 0 119G 0 part
Update: I ran the debug, but I cannot say that I like the results; I cannot read too much of CLI, but if
fdisk -lsees the drive as /dev/sda, and FOG does not see the drive at all, then is there a problem with FOG?[root@10 /]# fogpartinfo --list-devices Error: Can't have a partition outside the disk! [root@10 /]# fogpartinfo --list-parts /dev/sda Error: Can't have a partition outside the disk! [root@10 /]# fdisk -l Disk /dev/sda: 119.2GiB, 128035676160 bytes, 250069680 sectors Units: sectors of 1 = 512 * 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimal/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x9deac661 Device Boot Start End Blocks Id System /dev/sda1 * 2048 616447 307200 7 HPFS/NTFS/exFAT /dev/sda2 616448 488392703 243008128 7 HPFS/NTFS/exFATIf this helps in any way, we are using (attempting to use) the following SSDs in our computers (What is supplied through our contact):
- Samsung - SSD 128 GB (6.0Gbps) 2.5" [Model: MZ-7PC128D] {P/N: MZ7PC128HAFU-000D1}
- Micron - SSD 128 GB (6.0Gbps) 2.5" [HP P/N): 652181-001] {(HP Model)P/N:MTFDDAK128MAM-1J1}
- Micron is what I am currently testing this on - client wise.
- Samsung - SSD 128 GB (3.0Gbps) 2.5" [Model:MZ-7PA1280/0D1] {P/N:MZ7PA128HMCD-010D1}
-
@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. -
@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!
-
@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.
-
@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/exFATYour 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.mbrhere 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!!
-
@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.
-
@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.
-
@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??
-
@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 -lnow. 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.
-
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.)
-
@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.
