Best posts made by fry_p

@Sebastian-Roth said in FOG 1.5.6: Auto resize is unpredictable:

@fry_p On first read this doesn’t sound related to me but we’ll see. I know you are very busy right now but would you mind opening a new topic with this one as well and post more information there? Picture of the error would be great!

I figured a new topic may be in order. I will open one up if I have time the beginning of next week when I would be able to replicate. If I am able to get some time I will gather as much info as possible including error messages and pictures.

@george1421 said in Surface Pro 4 on 7977:

@fry_p slightly off topic. But if your dhcp server is 2012 server there is an option to configure it to support both uefi and bios pxe booting.

I did see that in another thread. I am planning on implementing that, but I haven’t had any time to sit down and do it. Plus, right now, we have a grand total of roughly 25 UEFI devices compared to the thousand plus BIOS devices. It doesn’t need to be changed often (at least not yet). We are moving administrators to Surface Pro 4’s gradually so this will become a necessity. Thanks for the heads up.

@Tom-Elliott That worked. What was different about what I had vs. the ones you had me download? I tried re-installing this morning and that didn’t work.

@george1421 Here are my results:

Spun up one FOG Image server and FOG client server, both connect to db on Image server.

Uploaded/deployed image no problem to two laptops.

Installed client and pinned client server as the address in the installation on both laptops (changed checkin time to 30s for testing purposes).

Both clients authenticated successfully. Deployed simple MSI snapin from client server to both laptops. Clients checked in no problem and pulled the files from the imaging server, and ran them without trouble.

I am starting to think this proof of concept is a success. Is there anything else I should try with this test environment I have set up?

I’m still on 1.5.6 and this doesn’t work for me. Honestly it has not worked in many iterations of FOG prior either. I usually just go into the VM and manually remove them after I delete the definitions in the GUI. Thought it was just a bug on my end.

@Wayne-Workman said in Surface Pro 4 on 7977:

@fry_p Once DHCP is configured, you will never have to change it. It takes 10 minutes to setup, every step is laid out for you in here:

https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence

I was able to set this up this morning. Works perfectly. The only thing is we have many scopes in the building I set up Surfaces at, so I set the policy at server level. Thanks for the tip!

@Psycholiquid This is what helped me:

@Tom-Elliott said in Microsoft Surface Pro 4 Deployment stuck at init.xz:

Try changing your tftp files with those from:

https://sourceforge.net/p/freeghost/code/5835/tree/trunk/packages/tftp/

I don’t know why, but this particular issue seems related to something that I have literally no control over.

I had the same issues with a Pro 4 either getting stuck at init.xz …OK or a black screen (on RC1 and RC2). The ipxe files in the current release don’t seem to play nice. Give that a try and see what happens. Remember to not move/rename/delete the default.ipxe out of the tftpboot folder (or else you have to reinstall), everything else can be replaced.

@george1421 I have not had time to do this because of some medical issues keeping me from work. Hopefully it is all sorted out soon and I can test this!

IMHO spinning up a fog server from scratch takes out a lot of variables that may cause issues. The install script for FOG is quite streamlined these days. Though I am a vmware user, I find that templates and pre-builts save you literally just a few minutes at the cost of many potential issues, especially since network environments vary so much.

@avaryan From what I understand, it will only pxe boot from a microsoft dongle.

From the Website
https://docs.microsoft.com/en-us/surface/ethernet-adapters-and-surface-device-deployment

“Third-party Ethernet adapters are also supported for network deployment, although they do not support PXE boot. To use a third-party Ethernet adapter, you must load the drivers into the deployment boot image and you must launch that boot image from a separate storage device, such as a USB stick”

@Wayne-Workman It is blank. I take it that’s bad…

I might as well throw my hat in, I think I know enough about imaging with FOG to help. If anything, updating some basic things to reflect newer versions of FOG.

@Sebastian-Roth Whoops, I did not know that was the norm now. It is in the wiki article as auto. My bad, I can certainly change that before I try again.

EDIT: fixed my first post with the delay and a missing space just in case it works and someone uses it later

@cool1107cm said in Maybe the USB cable is bad:

Hi @Quazz & @fry_p

How can I add kernel argument as below,
Would you please provide me more detail info?
Thank you so much

usbcore.old_scheme_first=1
has_usb_nic=1

Hi @cool1107cm ,
Much has changed in the way of Surface imaging for me. At the time of this post, I was able to image using these kernel arguments with a USB NIC on a Surface Pro 4 . However, as time passed, a number of other variables have come out of the woodwork to prevent the use of FOG on Surface Pro’s for me. I have reverted to manually installing Windows. I believe for a while I was working with @Sebastian-Roth and/or @george1421 on getting this to work. If you have a surface pro/ usb nic issue, I would highly recommend starting a new thread. Perhaps someone has come up with a solution since the time of this post.

Sorry I couldn’t be much more help. For the record, I used the Host Kernel Argument box on the host information page for the particular host on the web GUI and added these arguments in the order I specified separated by a single space.

@Sebastian-Roth sorry it took so long, but I finally was able to create a separate thread in bug reports. https://forums.fogproject.org/topic/13486/fog-1-5-6-pushbullet-plugin-not-functioning

We are in the midst of reassembling classroom tech after the custodians did their cleaning so that is what caused the delay.

@george1421 I will most likely try post init scripts eventually for that reason. I saw your post on the other thread and it honestly looks easier than what I did lol. I’m burned out today, plus I just got the thing working

@sebastian-roth we may have found a workaround since we have a uefi/bios co-existence setup, we are trying to legacy boot to capture/deploy the uefi image. It appears to have worked. I am not sure I want to pursue this issue further since it is a very old model and a one off case.

I appreciate your help on the matter regardless, thank you.

“Renaming a Windows computer and then joining a domain is now 2 times faster
Renaming a Windows computer inside a domain is now 3 times faster”

What black magic is this?

@wayne-workman said in Where can i get the new 1.53 install with the fixed Binaries from:

Just noticing here, @developers @moderators @testers is it normal for the message to be bzImage412 ? I’m refering to the screen-shot the guy posted a few posts below.

I do not get the “412” at the end of bzImage to answer your question.

@Jbob Thanks a million! Now I sat down and made the described changes from the wiki and it works flawlessly.