Suggestion please

[george1421]

@ziolucione Ok it sounds like a wifi issue maybe??

From the command prompt you can key in ip addr show to show the ip address of the target computer. If it has what you expect for the wireless adapter, then see if you can ping the fog server ping 10.10.10.1 If a ping is successful then I find it a bit strange that the error is thrown.

[ziolucione]

@george1421

So guys, I did have network issues.
I have now fixed them all and it looks like it’s working from a ping and broadcasting dhcp side.
Still I have the same issue.
I don’t know if it’s something related to my partition/disk choice in FOG or there is something else broken.

Thank you for your help.
Lucio

[george1421]

@ziolucione ok the first thing I noticed is now the IP address of the fog server has changed from 10.10.10.1 to 192.168.1.2. Is this expected? The fog server itself is not happy when its IP address is changed after FOG is installed. There are steps to take to fix this condition.

At the error message (below) press ctrl-c to exit out of the script try to ping the fog server’s IP also ls -la /images to see if there is any content.

[ziolucione]

@george1421
Yes, 192.x.x.x is expected. I have reinstalled FOG from scratch too.
Ping is working and the command returned the following:

Regards.
L.

[george1421]

@ziolucione Well at this point we can rule out networking (wifi), probably. Since we have the network share mounted. If you look into the 60f677d582f7 directory there should be some files in there.

So lets change our focus for a second. You had capture working using the usb ethernet adapter right? Is there a way to use the usb ethernet adatper on the 192.168 network. Right now we are pretty sure that networking isn’t the problem. To rule out networking, change to the usb network adapter without changing anything else. I don’t think this issue is networking at all, but we have to find out where the problem isn’t to find out where it is.

The other difference from before and now is that before you were using the FOG 1.5.7 virtual hard drive (init.xz). What I built was using the pre-release version of 1.5.8 which has an updated partclone program (right where the imaging blew up). So if networking isn’t the issue I’ll have to roll the build back and use the older version of partclone. But I don’t want to throw too many variables in the mix just yet. But that is what I’m thinking.

[ziolucione]

@george1421 Hi guys,
I cannot test the wired using the 192.168.x.x because it is controlled by the IT department and the DHCP and DNS is working under another subnet.
I have to configure FOG as the DHCP server and so start again from scratch.

[ziolucione]

Hi @george1421,
it looks like FOG has issues with the ‘Microsoft Reserved’ windows partition.
I can image the EFI partition, I am trying now to capture just the main one, but it is very slow apparently 1h 20m left (12GB - 115MB/min) using partimage instead of partclone (I have selected it in the image configuration, but the tool actually is partclone).

If this duration is due to the wifi transfer/speed, I will go back to the wired scenario.
[wired] In order to capture one and massively deploy to multiple devices (without managing the devices in FOG), what’s the best workflow in your opinion?

I’ll keep you posted.
Lucio

[george1421]

@ziolucione I was thinking that since you can’t image with the ethernet adapter using the same setup I should rebuild the inits with the older partclone tool. Again to only change one thing at a time.

As for your speed of 115MB/min that translates over to 15Mb/s. If I had to guess you are using 802.11b (11Mb/s) or 802.11g (54Mb/s) wireless network link. If I had to pick one or the other I would say 802.11b. So your numbers are reasonable for wifi. Its not fog, the device, or partclone/partimage at fault here its your network link speed that is the bottleneck.

In order to capture one and massively deploy to multiple devices (without managing the devices in FOG), what’s the best workflow in your opinion?

Assuming you still want to go with the usb boot method, once we have a captured image I’ve prepared a template on the usb flash drive. Its number 5 in the grub menu. Right now it has data I borrowed from @Junkhacker 's post on how to call an image directly from the iPXE menu. I translated it to grub format. So my idea is once you have captured the reference image, we will go and update that #5 menu to call for that image directly without needing the target computer to be registered in FOG. But that part will only work after we have captured your reference image.

[ziolucione]

Hi @george1421 I have the reference image now.
Can you help me to create this entry in the FOS system so I can push the image directly from there (without going into FOG I believe), and also, I should have 3 different images to deploy. How can I create another menu entry in FOS?
Thank you for your help.
Regards.
L.

[george1421]

@ziolucione Ok this part has a few steps but is not hard. What you need to do as a test is to take a registered computer and setup a debug deploy of the image you are interested in quick deploying. (it would probably be faster to use a wired connection for this, but what ever works). When you are dropped to the FOS Linux command prompt key in the following cat /proc/cmdline That will print out the kernel parameters used to call that image.

Now when I created the grub menu for that wireless usb boot I created a menu entry 5, that is the template you need to populate with the values collected from the cat cmdline command. You will need image name, image type from your debug deploy image into that option 5 in the grub menu. You can make more grub menu entries by just copy and pasting the section 5 menu entry. The order the menu items are in the grub menu is the order they will be displayed when the system usb boots.

I can give you a hint if you want to edit the grub menu on a windows computer, use notepad++ and not windows notepad. Windows notepad adds in windows specific characters that sometimes confuses linux applications.

[george1421]

I thought of a bit of an easier way to explain the field mapping between the kernel parameters ( cat /proc/cmdline ) and the grub menu. Here is a graphic that explains how to map the values between the two different booting methods.