@george1421 i’m thinking we could have an “unregistered host” host and have it auto-register and auto-remove when the tasking was created/finished. that would also allow us to have a task to track in the gui.

just chiming in to say that i would also like this feature

@Beyondlimitation the version of dnsmasq you’re running is old. old versions only allowed .0 to be on the tail end of a file name

https://serverfault.com/questions/882554/when-configuring-dnsmasq-for-pxe-booting-why-do-i-need-to-change-undionly-kpxe/882697#882697

@AdrianW are you having this problem on one system, or multiple?

@AdrianW as the user or password been changed since it was last working?

@george1421 said in Where are the general iPXE settings?:

and that should pull the file from the tftpboot directory. But then you will need to have a mac address file for each system. But then what happens if you don’t have a mac address file the boot fails.

in this case, you could just end the chain command with || and it would try the next available command, which can be booting to the fog server

@Gamienator if you’d like examples on how to make iPXE menus (a good starting point) just search the forum for “advanced menu”

@Gamienator ipxe.org has references to all of the commands and functions available, and you can find examples of ipxe menus on the forums.

@Hubi i’m pretty sure there’s references on how to do it on the forums, but here’s how i’ve done it in the advanced menu. it will take just a little modification to put this into the ipxe menu entries instead, but it should give you a pretty good idea of where to start

:Win7SP1x64
kernel bzImage root=/dev/ram0 rw ramdisk_size=127000 ip=dhcp web=${fog-ip}/fog/ consoleblank=0 loglevel=4 type=down img=Win7SP1x64 ftp=${fog-ip} imgType=n imgPartitionType=all osid=5 storage=${fog-ip}:/images/ capone=1
imgfetch init.xz
boot ||
goto MENU

@Hubi ok, that’s a little different. i haven’t touched it in a long time, but we have a plugin called “capone” that does exactly that. i’m not sure if it’s been updated or supported. i just tried to activate it on my dev server and it didn’t work, but that might just be my dev server being a little borken (i’ll leave that typo, it seems fitting).

if the plugin doesn’t work, it can still be done with adding a custom ipxe menu item and setting it as the default for unregistered hosts.

@Hubi that sounds like fog’s normal mode of operation though

you schedule an imaging task telling what hosts to be re-imaged with what image, and on the next boot they do it

what am i missing here?

@Hubi could you provide more details on exactly what you’re trying to do and what you’re trying to achieve? there are multiple ways of doing things that match what you describe, and some of them can have very bad consequences if done without understanding the goal and environment. i wouldn’t want to give you instructions on how to reimage every computer when they boot without an understanding that it’s what you actually want…

important side note: if you make modifications to this file, make backups of your changes. the default.ipxe file is overwritten on any fog upgrade.

@Gamienator the fog ipxe boot file is compiled to load /tftpboot/default.ipxe as soon as it starts. this is the writable file that we use to give a writable address location for the fog server, so we don’t have to recompile the boot file for every server.

normally, this file just gathers some information and chain loads

 http://<your-fog-server-address>/fog/service/ipxe/boot.php##params

this “file” is a dynamically generated boot file that will change according to scheduled tasks for that host

but, something you can do, and what i do to direct my testing machines to my development fog server and away from the production one, is add a few lines before the chain load like this

iseq ${serial} <your-machine-serial-number> && chain <alternative-boot-file-destination> ||

this reads
iseq (is equal)
${serial} (one of the pieces of info that we have ipxe already gathering and assigning to a variable)
<your-machine-serial-number> (the serial number of the host you want to redirect booting of)
&& (if previous condition tested true, do the next command)
chain (boot the following)
<alternative-boot-file-destination> (can be local to the default.ipxe, or http location, etc)
|| (if previous conditions fail, proceed to the available command instead of throwing an error)

these command descriptions aren’t exact, but effectively what’s happening here. for more info, check out ipxe’s website

i’m not sure what went wrong here. I haven’t installed fog on a Buster system yet, but i know others have without issue.

This is my first time ruining Linux so you are going to have to excuse me overlooking something stupid.

don’t worry, we all do that at some point. lol (i think that was a typo though)

did you create any users on the system other than the “kelly” one we see in the log?

@no0NE are there any power saving features available on the nic under windows that are enabled? sometimes those get stuck in windows and the linux side doesn’t have the ability to re-enable the performance mode.

@cnschindler said in Add support for Windows ReFS filesystem:

ReFS

we can’t really support a file system until an open source cloning software can. we currently use partclone for almost all of our data copy operations. once they support, it we can too.

@f-an what does your storage subsystem look like?

@f-an i know the benefits of creating master images on VMs and understand the use of VMs to test image deployments, but it sounds like you’re trying to as your method of creating pre-configured VMs. what’s the benefit of using fog for this purpose instead of using a VM template?