New Lenovo M900 Tiny Computers
-
I’m about to roll out 350 new computers to replace the existing computers that we have now. I was able to roll out all the previous computers with Fog, and had no issues, so I wanted to do the same with these new ones.
We have purchased Lenovo m900 computers loaded with Windows 7, with an option to update to Windows 10. I have loaded up one PC to Windows 7, ran all the updates, and made an image with no issues. I did have to update the Kernel, but that wasn’t a big deal and was sort of expected.
Another PC I have loaded Windows 10 with a VLK. I wiped the entire drive during the install and allowed Windows to do what it had to do. I ran all the updates, got the software we needed, and wanted to create a default image. I can register it, however when I try and pull an image it gets to the hard disk and just stops. I logged into the PC, went to Disk Management, and it shows that the Partition Style is set to MBR.
I ran the compatibility check on the Partition Information and then Check FOG Compatibility, and this is what I get. I have even reloaded Win 10 thinking that it was related to a BIOS update that a co-worker did. I’m not sure if this is a Windows issue, or if it is because I’m running Ubuntu for the server.
Partition Information
Model: ATA SanDisk SD7TB6S2 (scsi)
Disk /dev/sda: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: pmbr_bootWarning: /dev/sda contain GPT signatures, indicating that it has a GPT table. However, it does not have valid msdos partition table, as it should. Perhaps it was corrupted – possibly by a program that doesn’t understand GPT partition talbes. Or perhaps you deleted the GPT table, and are not using and msdos partitio table. Is this a GPT partition table?
-
I’m not sure if this make a difference or not either, since I use this same setup at another location where I have deployed FOG. The following is the settings I’m using for the Windows 10 image that I’m trying to pull.
Operating System: 8.1
Image Type: Multiple Partition Image - Single Disk (Not Resizable) -
@Towndrunk It’s because it shipped with a GPT formatted hdd and was changed to MBR. You can fix it by doing a debug upload, and running
fixparts /dev/sdaand then either 1. Cancel the debug task, create a regular capture task and reboot. or 2. issue thefogcommand and press [enter] for each step. -
I had already started loading another spare SSD we had with Windows 10, using the same VLK. I will see if that works any better. If not, I will try your recommendation. I may try it either way, just to see if that was the issue. Thanks for the response.
-
The new drive loaded with Win 10 is working great, and I am in the process of uploading an image now. If I can get a good image off of this drive, will it cause any issues pushing it out to the other devices with the factory formatted GPT drives?
-
I don’t know.
What version of FOG are you running?
I’m fairly sure trunk builds will work for you without much issue, and you can define the appropriate OS. I say this because, if I had to guess based on how you created the image, it seems that you’re running FOG 1.2.0. Systems are always going to be coming and going, but FOG is not always going to be able to work on the new systems. Add that to the fact the improvements of trunk vs that of the stable “builds” and I think you’'ll find, at the least, a much better overall imaging environment.
-
Yes, you are correct. I am using FOG 1.2.0. I’m sorry, it has been a while since we pushed out new computers so I haven’t kept up to date. Should I be looking into another configuration? If so, now would be the time to do it before we get to far into this. I will look into “Trunk” and see if I can find anything.
I spoke to soon as well. I tried to upload an image from the same models so we could have a default Win 7 and Win 10 image. I just looked at the FOG images, and both look as though they connected to the server, but didn’t work out as I had hoped.
Win 7 says 224.57 GiB on the client, and 0 GiB on the server. With the correct time I uploaded today.
Win 10 is almost the same. 465.27 Gib on the client, and 0 GiB on the server. -
I’m sort of at a loss now. I have tried Windows 7 out of the box setup, Windows 10 installed from a VLK on the same disk, and Windows 10 installed from VLK on new disk. Two will capture and image to FOG, but there is no data. The other will not work at all.
I went and updated my install to “Trunk” by following the Wiki. The following is what I have now. I need to take a break, and I will come back to this later. Thanks for all the help so far. I really do appreciate it. I am attempting to post a link as well to what I see on my image screen.
Running Version 8533
SVN Revision: 5891https://www.dropbox.com/s/awbzqh83smouri1/Fog.JPG?dl=0
-
@Towndrunk Now that you are on the trunk build you have a better chance to capture and deploy Win10 images. You will need the trunk version to support win10, gpt, and uefi systems.
What would be interesting to know if you pxe boot into the FOG menu and then select the compatibility tests, what are your results for both disk and network?
Something else interesting to know is if this is a new fog installation (ignoring you just upgraded to the trunk). Meaning did you just setup fog or have you been using this specific server for a while capturing and deploying images?
-
@Towndrunk yeah it’ll probably work now that your on trunk.
-
I suppose the real questions, beyond those already asked, might be are the systems actually accepting the images as assigned? If they’re not that’s a totally separate issue and one that will take a little more time to help figure out.
The image size on client is a convenience element that just helps determine the smallest drive you can use with fog. It’s not a perfect system as in some cases the disk may not be laid out properly (Offset start of fixed + the full filesystem). However, this should not be impacting your ability to image in any regard.
-
@george1421, once I updated the system to Trunk, I deleted all of the images and hosts, and started over. What you see in the image was all done after updating. I can run the compatibility tests tomorrow once I’m back in the office, but the Windows 7 out of the box load, and the Windows 10 on the new disk both seemed to work. The Windows 10 that I loaded with VLK on the system drive that came with the PC did not work.
I had the Win 7 image, and tried to deploy it to a third PC, and it would not work. Like the image wasn’t really there. I know I’m not being very descriptive, but I can give more information once I am in front of the computers again tomorrow. It connects, registers, but it doesn’t seem to be capturing a valid image.
-
@Tom-Elliott, OK. Maybe I was just a little confused. I thought that one of the items was size on server, and that was 0. I was making the assumption that it was reading the size of the drive like you said for “size on client”. The old 1.2.0 said size on server was 0, which I thought meant it didn’t actually capture an image.
I was hoping that updating to Trunk was going to resolve some of this, but it doesn’t appear as though it has. I will continue to work on this since I want to get it working.
This was an old server that we used for our last deployment of Acer M498G desktops. I was able to pull and deploy images with no issues, but now with the new computers I’m having an issue. That is why I thought this was hardware issue, and not an issue with FOG.
-
@Towndrunk said in New Lenovo M900 Tiny Computers:
The old 1.2.0 said size on server was 0, which I thought meant it didn’t actually capture an image.
That particularly sounds like you used to have an FTP credentials issue. No worries now though, FOG Trunk ensures that the correct credentials are set during every installation and update.
Just so you know - if an image is VLK or otherwise, fog doesn’t care about that. It has no effect on imaging itself. Often times, manufacturer images have custom MBRs and custom GPT layout that have in the past been known to be problematic. While FOG should be able to image those and the developers work hard to support them, often the fast and easy answer is to build your own image from scratch and set it up with VLK as you need. This would include using the “Advanced” area in the windows installer and deleting every existing partition, and then telling the Windows installation to create a new partition. If the system is BIOS, the installer will make 2 partitions by default. If the system is UEFI, the installer will make 3 partitions.
Simply saying it didn’t work isn’t near enough. We need details. Exactly what didn’t work, exactly what point was their a failure? Exactly what is the problem? Can you give a video or photos of errors? We need more to go on.
-
@Towndrunk said in New Lenovo M900 Tiny Computers:
If I can get a good image off of this drive, will it cause any issues pushing it out to the other devices with the factory formatted GPT drives?
No. They just need the same firmware settings. If they shipped in UEFI mode, and you flipped the golden machine to BIOS to build an image on, you’ll need to flip the same setting on them all.
-
PC: DefautlWin7
Lenovo M900 tiny.
Unboxed PC and booted with factory installed Windows 7 OS, and then updated the BIOS.
Ran all the updates (excluding the Windows 10 upgrade)#2 Network Information
1: lo: <LOOPBACK, UP, LOWER_UP> mtu 65536 qdisc nonqueueqlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST, MULTICAST, UP, LOWER_UP> ntu 1500 qdisck pfifo_fast qlen 1000
link/ether 00:23:24:b7:84:ca brb ff:ff:ff:ff:ff:ff
inet 10.15.32.99/24 brb 10.15.32.255 scope global eth0
valid_lft forever preferred_lft forever
DNS Information
search xxxx.local # eth0
nameserver 10.15.31.25 # eth0
nameserver 10.15.31.24 # eth0#3 Partition Information
Model: ATA SanDisk SD7TB6S2 (scsi)
Disk /dev/sda: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:Start End Size Type File System Flags
1 1049kB 1574MB 1573MB primary ntfs boot
2 1574MB 243GB 241GB primary ntfs
3 243GB 256GB 13.4GB primary ntfs#4 FOG Compatibility Test
FOG Compatibility Test
Computer appears to be compatible with FOG!
Results
Network [Pass]
Disk [Pass] -
PC:DefaultWin10
Same Lenovo M900 tiny as DefaultWin7 PC.
First thing we did is update the BIOS, then using the same drive I loaded Windows 10 via a VLK.
Install was a custom install, deleting all old partitions and installing Windows 10.
Ran updates, and wanted to use this as a base image and build from there.#2 Network Information
1: lo: <LOOPBACK, UP, LOWER_UP> mtu 65536 qdisc nonqueueqlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST, MULTICAST, UP, LOWER_UP> ntu 1500 qdisck pfifo_fast qlen 1000
link/ether 00:23:24:b7:85:57 brb ff:ff:ff:ff:ff:ff
inet 10.15.32.72/24 brb 10.15.32.255 scope global eth0
valid_lft forever preferred_lft forever
DNS Information
search xxxx.local # eth0
nameserver 10.15.31.25 # eth0
nameserver 10.15.31.24 # eth0#3 Partition Information
Model: ATA SanDisk SD7TB6S2 (scsi)
Disk /dev/sda: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:Start End Size Type File System Flags
1 1049kB 525MB 524MB primary ntfs boot
2 525MB 256GB 256GB primary ntfs#4 FOG Compatibility Test
FOG Compatibility Test
Computer appears to be compatible with FOG!
Results
Network [Pass]
Disk [Pass] -
I removed all of the images I had on FOG, and attempted to capture both a new Win7 and a Win10 image from the two computers listed below. The Windows 7 PC appears to be working, and is going through the process now. I will check it once it is done. The Windows 10 failed the capture right away.
Here is what I received on the Win10 PC. When I browse the /var/log folder and look for the partclone.log it doesn’t exist.
Partclone fail, please check /var/log/partclone.log
An error has been detected!
Failed to complete capture (savePartition)
Args Passed: /dev/sda2 1 /images/002324b78557 all
Computer will reboot in 1 minutes -
@Wayne-Workman, I just looked the logs in FOG, and it appears as though there may be an FTP credential issue? I see this over and over.
[Wed Jul 13 08:34:33.547856 2016] [:error] [pid 5725] [client 10.15.32.99:36668] PHP Warning: ftp_login(): Login incorrect. in /var/www/html/fog/lib/fog/fogftp.class.php on line 107
-
@Towndrunk That is what I was suspecting. When the files don’t get moved (but remain in the /images/dev folder), its typically an FTP authentication issue. This is where the (linux) fog account password isn’t in line with the password defined for the storage node configuration.
