Posts made by perler

which really doesn’t help the average admin. but let’s leave it at that.

ok, if I didn’t overlook something, the stance is: this is open source, anyone can contribute, but we (the commenters from the dev team that answered) won’t do it. if this holds, this project more or less ends with windows 10, which in itself ends from a practical point of view in a year or so when everyone rolls out windows 11 by default.

did I miss something?

I do this from time to time. Is there anything new beside “not possible because M$” and “here is a howto from 2017 but you need to compile your own kernel version 4.20 between 9pm an 4am”?

I solved it this way (not sure what solved it in the end): in the beginning, the NUC had UEFI boot only enabled and wouldn’t PXE boot at all. so I enabled lagacy just to get to the iPXE menu (where it hang). I fixed the UEFI boot this way https://wiki.fogproject.org/wiki/index.php?title=ProxyDHCP_with_dnsmasq - especially the part with adding the different dhcp-vendorclass entries.

I could now PXE boot via UEFI and the problem was gone.

before i did this I downloaded a new kernel from the fog web interface, but I am not sure if this had anything to do with it.

anyway, thanks and any chance to get a working PXE secure boot? disabling secure boot is an option obviously but can be a hassle if you want to fully automate rollouts…

fog 1.5.9
what do you mean by “latest iPXE”?

I have some newer NUC8s which hang on the iPXE menu. The menu is set that way, that after 3 seconds Quick Registration and Inventory should run. on older NUCs this works and it even works in older NUC8s as I know I have deployed them two years ago on the same system. with the newer NUC8s the countdown doesn’t start and keyboard is unresponsive

It must be a BIOS update or a setting I miss?

any suggestions?

sorry, I didn’t. but I think you can easily recreate this by following your instructions and immediately after the upgrade is finished try to capture a machine.

Ok, a server reboot fixed the error 139 (so there may be a small issue with the updater) and I can confirm that the original bug is fixed in the dev branch.

ok, sorry, this took a while but I finally managed to witch to the dev branch. now the capturing stops earlier, when trying to capture the big “main” partition of the test machine it exits with error 139 and it asks me to check the space on the server (which is fine).

# df
Filesystem               1K-blocks     Used Available Use% Mounted on
udev                        977344        0    977344   0% /dev
tmpfs                       201784      848    200936   1% /run
/dev/mapper/fog--vg-root  60655460 27545672  29998876  48% /
tmpfs                      1008900        0   1008900   0% /dev/shm
tmpfs                         5120        0      5120   0% /run/lock
tmpfs                      1008900        0   1008900   0% /sys/fs/cgroup
tmpfs                       201780        0    201780   0% /run/user/0

Is there an easy way to switch branches?

I set up a new FOG server and exported/imported the images from the old one. I put the image folders into /images and successfully deployed an image. so far so good.

I now try to capture the same image from the just deployed PC and get the dreaded “Invalid Storage Group” message after the capture is finished. I also see, that there is a folder with a seemingly random name in /images/dev (name is: 20cf302bd905) with the captured image.

please advise.