Dell E6410 - Solid State Drive (SSD) Compatibility
-
Alright, I have slaved over the related searches – up and down the menus – and cannot find anything that works.
I have a Dell E6410 with:
- Windows 7
- x86_64 Arch - Intel i5 Quad-Core (Supposed to be Quad-Core)
- Solid State Drive
I have tried several methods of imaging this computer:
- I have uploaded the image with the Master Drive after using FOGPrep - This allowed me to go from SSD-to-HDD.
- I have uploaded the image with the SSD as the Master Drive.
- I have uploaded the image with the HDD as the Master Drive.
- I have downloaded the image with the SSD as the Destination Drive.
- I have downloaded the image with the HDD as the Destination Drive.
Now, this is the code block I am receiving when I tell the computer to download ANY image that is compatible with to the SSD Destination Drive:
http://fog/fog/service/ipxe/boot.php... ok http://fog/fog/service/ipxe/boot.php... ok /bzImage... ok /init.xz... ok DHCP/BOOTP: Reply not for us, op[2] xid[cfdcccc0] Starting logging: OK Populating /dev using udev: udevd[2230]: error creating epol fd: Function not implemented done Initializing random number generator... done. Starting network... ip: RTHELINK answers: File exists ***************** *FOG SPLASH PAGE* ***************** * Checking Operating System...............................Windows 7 * Checking CPU Cores......................................2 * Send method.............................................NFS * Attempting to send inventory............................Done * Checking In.............................................Done * Mounting File System....................................Done * Checking Mounted File System............................Done * Starting Image Push * Using Image: DLE6410TU * Looking for Hard Disks..................................Done * Using Hard Disk: /dev/sda * Erasing current MBR/GPT Tables..........................Done * Restoring MBR...........................................Done * No extended partitions..................................Done * Checking Hard Disks.....................................Done * Changing hostname.......................................Done * Updating Computer Database Status * Database Updated! * Task is completed, computer will now restart. reboot: Restarting systemThis is all I get when I run the Download task from either the machine itself or the http://fog/fog/management/ website; this is regardless of what the Host Disk is (SSD or HDD) to the Destination Disk (SSD).
When I perform the same task, same image, same everything but instead it is from HDD-to-HDD, it works fine; when I perform the same task, same image, same everything but instead it is from SSD-to-HDD, it is hit-or-miss – Guaranteed miss without FOGPrep, and if it hits, I have to do a few things in Windows to make the image look like it what it should (HDD-to-HDD).
I’ve seen things like:
- Change your DHCP 67 to undionly.kpxe (ours is currently undionly.kkpxe.)
- Change your main hard disk format to something other than /dev/sda (I saw a post on this, but cannot find it again.)
I am completely out of ideas at this point, and it is only getting worse since everything that is being bought now has SSDs.
-
I can say I have similar hardware on my campus.
I have the 6410 with i7s dual core. These image properly with HDD or SDD disks.
There is some information missing from your post.
What version of FOG are you using?
Are you on 1.2.0 or a trunk build of 1.2.0?
What disk structure are you using (single disk resizable, single disk non-resizable, raw)?
It would be interesting to know the contents of the image DLE6410TU on your FOG server. Please post the output of
ls -la /images/DLE6410TUThe boot file unidonly.kpxe is the correct one for the Latitude e6400 to e7450 in BIOS mode.
-
@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.