Developers

@lambo I am not exactly sure what size and file types are allowed in the forums. You can give it a try or upload to a file share/cloud of your choice and post a link here.

@boombasstic I think you run into an issue we fixed after the release of 1.5.9, see https://github.com/FOGProject/fos/commit/8d310f51d7d945c5dc1685eb6698d1aed8634dc7

I suggest you just grab the latest inits from our server and use those until we officially release the next version of FOG.

https://fogproject.org/inits/init.xz
https://fogproject.org/inits/init_32.xz

Put those into /var/www/html/fog/service/ipxe/ on your FOG server, renaming the original files.

@rogerpenn Why would you want to install FOG 1.4.4? It’s years old and we don’t fix installer issues in older versions. Just use current 1.5.9 and it will install just fine.

@mikmatcr While a default Windows layout usually hast 4 partitions instead of those 5 I would still say that the mentioned init-201114.xz should be able to capture your layout from a 500 GB disk and deploy to a smaller one.

As I said, use a new image definition, capture using the init-201114.xz and deploy that. Let us know if it works and best if you’d also post d1.partitions and d1.minimum.partitions from that new captured image here as well.

@mstabrin said in Using git inside FOS:

Something I need to be careful about regarding the git FOS version? When I use FOG 1.5.9 the latest master branch is ok I guess?

Yes, latest master branch of the fos repo should be fine. I have to say that I updated to a newer buildroot version a day ago which is not yet tested much. But as it’s just an update to buildroot’s latest LTS version I don’t think there is much to possibly go wrong with that. I will release that for dev-branch soon as well.

@mikmatcr The most important thing you need to consider is: Do you have a proper UEFI installation with GPT partition layout. Unless you can answer yes here, there is no point in going ahead with this.

Beside that you might want to post you current captured partition layout before trying the beta init referenced in the other post! Post the contents of the text filed1.minimum.partitions (you should find that in /images/IMAGENAME/ on your FOG server.

As George said this is still an early stage test init and I recommend you follow the process outlined in the other topic. Especially make sure you create a new image definition before re-capturing the image (yes you have to re-capture!) and as well don’t just substitute the original init.xz with init-201114.xz but put that into the same directory on the FOG server and change host settings.

You are free to do whatever you like but I suggest not to go and just use this as if it’d be an official init. It’s not!!

@mstabrin While I can see why you would want to have that I am not too keen to add this to the official FOS inits because I imagine they will grow a fair bit when git is added and most people don’t use it.

But you are free and welcome to compile your own inits and enable git to be added. Start by cloning the fos repo to some machine with CPU and RAM power and at least 20 GB of disk space available. Then change into that directory and run ./build.sh -f -a x64 - it starts downloading and preparing stuff for you. Then it will ask if you want to edit the configuration. Say y(es) here and you will get to a blue screen menu setup. Navigate to Target Packages -> Development Tools and enbale git (hit space key). Then choose EXIT (right arrow key + ENTER) three times to get back and confirm saving config changes. Then again say y(es) to let it start building.

Will take 90 minutes on a powerful machine and heaps longer on a normal consumer laptop.

If it all works out you should have a fresh compiles 64 bit FOS init file in …/fos/dist/init.xz to use on your FOG server.

@diegotiranya said in HP ProBook 640 G8 imaging extremely slowly:

In my case, with VMD enabled, there is no need to plug in any usb storage device in order to get normal throughput.

But if VMD is disabled you can still get faster speeds if you plugin the USB key?

@Dungody Can you confirm enabling VMD in the UEFI settings will get you faster speeds without plugging in a USB key?

Seems like VMD support has been in the Linux kernel since quite some time now. Though I still wonder why we see it being so terribly slow when VMD is disabled.

@Florent Which version of FOG do you use?

@testers Anyone able to confirm this is an issue?

@choppaholic26 Ok. Those manual tests just work fine from what we see. Thought of a spanning tree issue kicking in late (not on the early PXE boot but only when the FOS kernel boots up) but that shouldn’t happen when you connect the notebook directly to the Proxmox host. Just to be very sure this is not something caused by a direct connection can you connect a dump mini switch in between those two too keep up the ports?

Yes I made those changes but nothing changed with either the attempt to PXE boot VirtualBox or the physical laptop.

Did you restart the dhcpd service on the FOG server or the whole VM to make sure the changes were applied? If so you might want to take another packet dump so we can check the DHCP options in the packets.

It’s really strange you stumble into so many issues right from the beginning. Too bad this keeps you from diving into the real fun with imaging using FOG.