After some more debugging I found that the redirection loop is not caused by the apache rewrite rules but by /var/www/fog/api/index.php and those included by that PHP file. Maybe this is because we don’t supply correct parameters?! Would be nice if it wouldn’t redirect in an endless loop.

@Dino_Nerd I think you can re-add the RewriteRule ^/(.*)$ /fog/api/index.php [QSA,L] in your 001-fog.conf and still should be able to access and boot http://192.168.0.143/pmagic/bzImage64 if that folder is in /var/www!!

Note to myself: Accessing directories (like http://192.168.0.143/pmagic/) does not work albeit the second RewriteCond because DirectoryIndex setting makes it request index.html in that directory, which usually does not exist. Therefore again redirecting it to /fog/api/index.php

@Sebastian-Roth

Yes I tried the below code which you have given and it works, Many thanks.

kernel http://${fog-ip}/fog/service/ipxe/clonezilla/vmlinuz initrd http://${fog-ip}/fog/service/ipxe/clonezilla/initrd.img imgargs vmlinuz initrd=initrd.img boot=live username=user union=overlay config components quiet noswap edd=on nomodeset nodmraid locales= keyboard-layouts= ocs_live_run="ocs-live-general" ocs_live_extra_param="" ocs_live_batch=no net.ifnames=0 nosplash noprompt fetch=http://${fog-ip}/fog/service/ipxe/clonezilla/filesystem.squashfs boot || goto MENU

and yes it is all about the putting right parameters.

Regards,

DDRescue is best bet for bad sectors.

@george1421

Thanks for clearing stuff up with me. Appreciate it

The “image ignore” and “client ignore” flags are meant to IGNORE the mac address in use for the respective item. For example:

Image Ignore makes it so the MAC Address being loaded is NOT going to be able to be used for Imaging. But this is only regards to the system it’s registered with. (Seeing as identity is verified/validated by the MAC Address this should be expected).

So, an unregistered machine, using a NIC that is registered to another machine, will appear to be that “registered” machine. Why would Image Ignore be a useful option? I don’t know, but I know the client ignore option IS useful (for example a shared USB nic on multiple machines so you can have the client work without thinking the system is another host.)

@Sebastian-Roth I still think you’re correct.

The CD SHOULD be asking you to “press any key to boot from CD”. Is there some reason this is a big concern? Sure it adds another step, but I think the reasoning is something in 1.2 iPXE code wasn’t sending the HDD, where in newer versions it’s releasing the system allowing the ISO to actually see the HDD prompting it to run a scan.

I don’t understand what problem it working as if this was a CD being booting this brings to the table.

@TCS_Taylor After sysprep you could technically just go into Audit mode again, but of course it would take more time to do so.

@fabritrento No.

Github on different branches might. The Tar files are built off the repository.

If you use the dev-branch or master branches from github, it’s identical to how the tar.gz file operates.

Hi,

i boot all my iso’s that way:

initrd http://${fog-ip}/iso/acronis2017.iso chain memdisk iso raw || goto MENU :easeuspms initrd http://${fog-ip}/iso/easeuspms.iso chain memdisk iso raw || goto MENU :aomeipau initrd http://${fog-ip}/iso/aomeipau.iso chain memdisk iso raw || goto MENU :veeam initrd http://${fog-ip}/iso/veeam.iso chain memdisk iso raw || goto MENU :erd2005 initrd http://${fog-ip}/iso/erd2005.iso chain memdisk iso raw || goto MENU :dart7 initrd http://${fog-ip}/iso/dart7.iso chain memdisk iso raw || goto MENU :dart8 initrd http://${fog-ip}/iso/dart8.iso chain memdisk iso raw || goto MENU :dart81 initrd http://${fog-ip}/iso/dart81.iso chain memdisk iso raw || goto MENU :dart10 initrd http://${fog-ip}/iso/dart10.iso chain memdisk iso raw || goto MENU :dban initrd http://${fog-ip}/iso/dban_2.3.0.iso chain memdisk iso raw || goto MENU

Here is my complete menu: https://pastebin.com/zWBnT5c0

Hi all,
I wanna thank everyone for their support. I was able to free up my storage node in the dashboard by login in my Ubuntu Server via Putty and erasing the images that were supposed to be erased in /images.

Have a great day! 🙂

@Tom-Elliott said in Debbuger.exe:

when running the isntaller, are you setting the IP address portion to your actual FOG Server’s IP Address?

yes, I am setting the ip address.

@Joe-Gill said in Chromebooks Refreshing Protocol:

Yes we do Enterprise enrollment via Google Admin.

Can you “Power Wash” them remotely?

Thanks!

Device management --> Chrome --> Device Settings --> User Data
alt text

This pretty much takes everything off of them as soon as the user signs out.

@sudburr How in the **** could i have missed that… It is running now. So shutdown with the shift i totally forgot and worked for me…
And you did not insult me at all, thanks for the solution…

And to all participants who did try to help me, thank you all…

@Tom-Elliott Ok, thanks. I think everything is working now.

@Wayne-Workman http://forum.kanka.net/showthread.php?943763-mOBSCENE21-s-Multi-Boot-USB-v3-0-8GB-amp-16GB is an older version but it’s a pretty good description. I have v6.0 but I think there is a v7.0 out there. The only way I have ever found to get it is via torrents because the full package is so large.

I was going to upload the readme.txt that comes with it, but the site won’t let me and the text is way to long to c/p.

@Joseph-Hales Thank you sir, yes, it would appear that may be a best practice that has to be instated. Even though I regularly update images, at no more than 2 month cycle, it shouldn’t add much extra work to the process in total.

@alh said in Group Management: Handling Conflicts:

So if I change the settings of a group, this change is applied to all members of the group overwriting the settings received through “earlier” group memberships?

Yes.

@tri_94 said in Active Directory Joining:

I can get it to join if I wait till the machines are imaged and then un-tick and re-tick the box to send the command again.

This doesn’t send the command again. The FOG Client gets it’s information via polling the server every x amount of seconds, default is five minutes. The server doesn’t initiate a send, the client does. On every single pole, the FOG Client is given all configuration the host should have from the server - similar to how Puppet works in a way. It sounds to me like you’re probably experiencing a server bug in what is probably an older version of FOG - The latest is 1.4, I strongly suggest you upgrade to it.

The only things the FOG Server initiates a send of are WOL and Multicast and pings, replication, maybe a couple other minor things. Most client side activities is completely controlled either by the FOG Client or network booting via some method at the client.

@Wayne-Workman @george1421 thank you both so much. you’ve been incredibly helpful!

I just wanted to post to close this out.

I got a test environment working with better switches and FOG was able to pass 64-bit UEFI traffic correctly the first time, every time. Thanks all for the big help! I really appreciate it!