@dantehaversham without a bootloader on a SD card? i’d love to see proof of this.

@george1421 the raspberry pi only supports booting from SD card.

you can not boot ipxe on a pi.

@sebastian-roth happening in
chrome and Firefox (but not edge or explorer) on Windows 10 and
chromium and Firefox on Lubuntu 17.10 and
Firefox (but not safari) on Mac OS Sierra

@sebastian-roth tested in firefox and chrome on multiple OSs, textarea isn’t missing on my current box.

@sebastian-roth

@quazz i can confirm the existence of this problem with 1.5.0-RC10 on Ubuntu 16.04.3-LTS. knowing the user (he’s a coworker) his server will be CentOS.

have you considered setting up the storage node, disabling replication, and updating the files manually?

@Fernando-Gietz that is absolutely not normal. i have no idea why it would be doing that.

@deepak727 “junk in compressed archive” you may want to verify the integrity of your files

@deepak727 have you tried the options here? https://forums.fogproject.org/topic/9606/trying-to-add-clonezilla-to-pxe-menu/10

@rwakc well, it would be technically possible to set up a method where you could be automatically imaging any device pxe booted from the network, and set up multiple dhcp scopes on different network ports, serving out different pxe boot files with embedded scripts. that way, you’d be able to choose what image the system gets imaged with by choosing what network you plug the device into.

@george1421 or, he could temporarily attach a keyboard

@TCS_Taylor files are no longer used the way they were in FOG 0.3x
ipxe can request the files over http instead of just tftp like pxelinux could, so we generate the boot information on demand using php.

@Benjamin_D you have been misinformed. the client can be used to schedule the capture task, but the system needs to reboot to begin pulling the image.
FOG is not typically used to capture systems that have been in use by users, but rather used to deploy a standardized image to systems.

@scgsg what are the specs of your server? have you tried capturing them in reverse order?

@Benjamin_D look into the location plugin. i think you should be able to do what you want to do, but i don’t think anyone has done it before.

@bertalanimre that doesn’t look correct. options 66 and 67 aren’t just things you have to enable, they’re configured. dnsmasq calls these options next-server and filename, i believe.
try adding this line to your config

dhcp-boot=undionly.kpxe,,<fog_server_IP>

@bertalanimre first off, i think you may have a misunderstanding of what fog is. fog isn’t used for “installing” operating systems. it’s for deploying pre-configured images of systems. you install your system to a computer, configure it the way you want, then capture it with fog. then you can deploy that image to other systems.

with that out of the way, have you set your DHCP 66/67 options?

@scgsg i would like to point out that, unless the client you’re using for testing is similar to the clients you’re deploying to, your benchmarks aren’t going to be very useful for you. your test client is using a processor that was a economy model when it was released almost 7 years ago. zstd and pigz are optimized for modern efficient multi-threading systems, and i suspect your Pentium isn’t taking advantage of them very well.

personally i use zstd compression level 11, as i find it has nearly the same upload speed as gzip at compression level 6 while making the images 26% smaller and deploy 36% faster. again, that is on more modern hardware than you’re using, your results will vary.

zstd compression level 19 is the highest normal compression level. above 19 are “ultra” compression levels that require massive amounts of ram.