Trinity Trammell

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

[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).

@george1421

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.

@Sebastian-Roth

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 -l sees 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/exFAT

If 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

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

Well, I found this:

http://devdocs.magento.com/guides/v2.0/install-gde/prereq/php-centos.html#instgde-prereq-php55-install-centos

Little manipulating and I got it to get me into FOG.

I’ll keep an eye on the server to make sure I’m not getting any failure logs, but it took.

Thanks, Wayne.

Omanimous

I saw someone else with a PHP error post, but didn’t want to thread jack.

We just updated to trunk from 1.2.0, and now when I try to access http://fogserver/fog/management

It gives me this error: FOG Requires PHP v5.5.0 or higher. You have PHP v5.3.3

Everything installed fine, but I am slightly confused on what to do now, and whether “You” is referring to the server or the computer I am using to access the server.

Server running FOG: CentOS 6.7

Omanimous

@ITSolutions That was it; I’m normally better at catching that, or leaving it set to AHCI (which most of our computers come in as) but it just never crossed my mind.

@Arrowhead-IT

I do not sysprep. (yet - I want to try it out)
I have.
Did not check that as @ITSolutions idea fixed it when I tried it.

Omanimous

The computer specifications we are using for our upload:

System Manufacturer 	  Dell Inc.
System Product	          Latitude E6410
System Version	          0001
System Serial Number      
System Type	          Type: Laptop
BIOS Vendor	          Dell Inc.
BIOS Version	          A16
BIOS Date	          12/05/2013
Motherboard Manufacturer  Dell Inc.
Motherboard Product Name  0667CC
Motherboard Version	  A00
Motherboard Serial Number 
Motherboard Asset Tag	
CPU Manufacturer	  Intel
CPU Version	          Intel(R) Core(TM) i5 CPU M 520 @ 2.40GH
CPU Normal Speed	  Current Speed: 2399 MHz
CPU Max Speed             Max Speed: 4000 MHz
Memory	                  3.72 GB
Hard Disk Model           ST9250410AS
Hard Disk Firmware        D005SDM1
Hard Disk Serial Number   5VGBJ2CC
Chassis Manufacturer      Dell Inc.
Chassis Version	
Chassis Serial	         
Chassis Asset	          Not Specified

The computer specifications we are using for our download:

System Manufacturer        Dell Inc.
System Product             Latitude E6410
System Version             0001
System Serial Number       
System Type                Type: Laptop
BIOS Vendor                Dell Inc.
BIOS Version               A16
BIOS Date                  12/05/2013
Motherboard Manufacturer   Dell Inc.
Motherboard Product Name   0667CC
Motherboard Version        A00
Motherboard Serial Number  
Motherboard Asset Tag	
CPU Manufacturer           Intel
CPU Version                Intel(R) Core(TM) i5 CPU M 520 @ 2.40GH
CPU Normal Speed           Current Speed: 2399 MHz
CPU Max Speed              Max Speed: 4000 MHz
Memory                     3.72 GB
Hard Disk Model            TOSHIBA MK2561GSYN
Hard Disk Firmware         MH000D
Hard Disk Serial Number    231RTPJZT
Chassis Manufacturer       Dell Inc.
Chassis Version	
Chassis Serial          
Chassis Asset              Not Specified

General Gist:
We recently built an image; we have successfully managed to push this out to two clients, but the rest seem to just throw it away. I even recently uploaded the image again, and still will not boot. It will accept and download the image, but not boot from it.

I do not know if posting the inventory differences will mean anything, but I am assuming it is hardware related.

Also, I know I had a post recently about HDD-to-SSD imaging trouble. This is not related at all - entirely different issue.

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.)

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

@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

@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

[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).

@george1421

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.

@Sebastian-Roth

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 -l sees 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/exFAT

If 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

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 system

This 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.

Trinity Trammell

@Omanimous

Best posts made by Omanimous

Latest posts made by Omanimous