@jeromecandau said in Problems with exit boot on M.2 SSD drive:

The only time when the boot occurs is in case whe just make a network boot until the fog menu appears and then select boot to hard drive (first item) (or do nothing : then the boot occurs after timeout).

OK lets start with the above. If this happens then you have the right exit mode in FOG. The exit mode values are only used in the FOG iPXE boot menu. When you start imaging, bzImage and init.xz are copied to the target computer then FOS (Fog Operating System, the customized LINUX that runs on the target computer for capturing and deploying images) starts. What is happening here after imaging (capture or deploy) FOS tells the computer to reboot then nothing… Do I understand that correctly?

PS: You should probably start your own thread since your issues are different than the original poster. I don’t want to give mixed information in this thread.

@kjoslin Ok you want to physically add a second drive.

Then you need to decide how you want to do it.

One option if your computer uses LVM (logical volume manager) you can just add the new drive to the disk pool and linux will just start using the new disk space. ref: https://askubuntu.com/questions/458476/adding-disks-with-lvm

Second, you can add as a new disk and setup a new image directory. In this configuration you will have to create a second storage node on the main fog sever. Then when you define new images you will have to pick which location (disk) you want to store the images to. ref: https://forums.fogproject.org/topic/10450/adding-additional-image-storage-space-to-fog-server

You typically sysprep your golden image so it may be deployed to any number of computers and hardware. The words “should sysprep them first” makes me think you are doing something else.

@greg-plamondon The instructions were in both documents. The one I linked and one that Wayne linked. Unfortunately it happens more often then you might think. There are some documents out in the wild that recommend you setup the fog account to install the software and manage the syste (which is the wrong way).

@sourceminer There has been a rash of these in the last 2 days on the FOG forums, Connical must have changed something to trigger this again.

https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy

Out side of your issue of FOG not picking the proper storage node for deployment you have a different issue here.

Since you are imaging 15-30 machines at once you are using the wrong technology. If they are all of the same image, you should be using multicast and not unicast images. Each fog server will fill its 1GbE network uplink connection with 3-4 simultaneous unicast sessions. To deploy 30 unicast streams you will need to add a bit more storage nodes.

The same goes for the switch to switch links. So how can you mitigate this?

1. Upgrade to a 10GbE network
2. Add more links in your network (LAG link groups)
3. Use a multicast stream.

Just for a baseline number, for a single unicast stream, what does partclone indicate your transfer rates are in GB/min?

@sudburr Does the linux user fog have write permissions to /var/ww/html/fog/service/ipxe and all files under?

@sudburr lets start out with

ls -la /var/www/html/fog/service/ipxe

bzImage needs to be owned by fog or have world write access.

@rstockham23 The most notable thing I saw in the second video was this error message

Can not open file '/images/CloudRead61/d1.original.swapuuids".

So what I would like to see is the output of this command.
ls -la /images/CloudReady61

also
cat /images/CloudRead61/d1.partitions

We’ve seen a sharp uptick in these issues related to ubuntu in the last weeks. There is a document that should give you guidance. https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy

You can confirm by checking the apache error log tail /var/log/apache/error.log If you see an errors that have pdodbc and insert field failed. That is a good indication that ubuntu has been tweaked.

@wombathuffer In regards to the storage node, can we remove that from the equation? Power it off and you still have the same issue? I’ve seen some pretty creative uses of a NAS with fog. I just want to ensure you are not cross mounting the NAS onto the fog server and trying to reshare the mounted nfs share. Because that won’t work. As long as the NAS is a stand alone storage node then we are ok.

So now I wonder what is unique about your setup where the standard nfs connect is failing? If you say its the same with virtual box and vmware. Understand I’m not poking at your issue, I’m trying to understand what might be different in your setup.

To answer your question, yes you can change how the FOS engine mounts the fog server. You will need to unpack the inits (init.xz) and then edit the file /bin/fog.mount In there you shall find the mount command you seek. Once you update the fog.mount script then just repack the inits and move them back to /var/www/html/fog/service/ipxe directory.

Here is how you edit the inits: https://wiki.fogproject.org/wiki/index.php?title=Modifying_the_Init_Image

@wombathuffer said in NFS mount options needed.:

The only thing I am asking in this thread is - How do I specify NFS options when the PXE booted server is mounting the NFS-service?

I was replying to your question just as you posted. See below

But I can say many people (including myself) run FOG in a vm on vmware and I’ve never seen this issue.

@rstockham23 How many client computers are hitting this FOG server? What is your check in interval?

@rstockham23 Lets try this, go to: FOG Configuration->FOG Settings->FOG Client->FOG_CLIENT_CHECKIN_TIME note the value and then set the value to 900. Wait what ever your checkin interval was and see if response is better.

@rstockham23 OK so every 30 seconds all 500 systems “ping” the fog server looking for any new instructions. So wait 5 minutes and see what your load is like.

Now understand we’ve set the check in interval to 15 minutes. That means if you schedule a snapin deployment to these computers, It will take up to 15 minutes for the target computer to get the job.

Just guessing but if you watch the capture that takes hours does it say Raw somewhere on the partclone screen? If so, is this a win10 instance, or I guess also win7 where bitlocker is enabled? If so partclone can’t read the partitions (because they are encrypted) so the only option it has is to read the entire disk, possibly taking hours.

ref: https://forums.fogproject.org/topic/10824/image-upload-deploy-taking-a-long-time/54

@creative1204 If you look at this post: https://forums.fogproject.org/topic/10824/image-upload-deploy-taking-a-long-time/41 the poster also said that bitlocker was not enabled. In the post by @themcv he provides the commands to ensure that bitlocker is off.

Then if you look at this post: https://forums.fogproject.org/topic/10824/image-upload-deploy-taking-a-long-time/59

Its stated: “The problem is Microsoft is pushing for more BitLocker, so while it is technically off, it is encrypting the free space on the drive causing FOG to want to make it a raw image. I don’t know if this is just on pre installs or with the latest version of Windows, but I ran into this with the latest Surface Pro.”

I’m not saying this your exact issue, but it does align up with what was said and done in that thread.

@shad0wguy It would be helpful once you prove this setup as reliable, if you could write a tutorial explaining how you setup FOG on this device as well as what others need to watch out for. I don’t think the FOG Project developers will support this configuration directly, but I’m sure there are others in certain situations with your exact use case. Your configuration may help guide them.

Please consider contributing to the cause, if you can.

@x23piracy Let me see if I can explain it. I’ll explain the easy part first.

As you know with FOG, it has 2 exit modes. One is for bios type computers and one is for uefi mode computers. These exit modes actually tell iPXE how to leave the PXE boot menu. They really don’t come into play for imaging at all. Once imaging starts then FOS takes over rebooting the system. So in our case we can only instruct iPXE how to react.

So for bios systems they will only use the bios exit mode field. The same for uefi systems they will only use the uefi exit modes. Understand because of the way fog is setup, you can technically assign a uefi exit mode to the bios field. That would cause the system to not reboot correctly. So anyway to the point if you have a uefi system changing the bios exit modes for that host will not have any impact on the computers ability to reboot since it only looks at the uefi exit mode field.

Now the second part. What that refind error is saying is that you have a parameter in the scanfor line of the refind.conf file that says if it can’t find any uefi boot loaders, to look for bios boot loader in the firmware. The CSMD support error basically means that your firmware doesn’t contain any legacy mode boot loaders. In Dell terms this means that you don’t have the legacy roms enabled in uefi mode (which is only provided for backwards compatibility). So to fix this (unfortunate with refind and the way its currently setup is either all or nothing, we can’t have system unique refind.conf files) 1. Remove the parameter in the scanfor line in refind.conf to tell it to not look for CSMD firmware. 2. Enable legacy roms support in the target computer’s uefi firmware.