@TaTa said in DNSMASQ 2.76-5 on Jessie:

Has anyone tried this version on Jessie?

Yes, but not from the stretch repository. We have documentation on how to compile it for Debian 8 here: https://wiki.fogproject.org/wiki/index.php?title=ProxyDHCP_with_dnsmasq#Compiling_dnsmasq_2.76_if_you_need_uefi_support

In general, is it okay to use packages designed for Stretch on Jessie?

No idea. Try it on a test box. Worst thing that can happen is it doesn’t work, then you can come back here and let the world know. My personal advice though - don’t use Stretch packages on Jessie - just my 2 cents. They have two different names for a reason.

@Tom-Elliott said in Certificate expired FOG Website:

I’ve modified the cron to run every 5 days so this should no longer happen.

with letsencrypt i let the cron job run every 2 months (certs are valid for 90 days).
i would leave the cert server contacts as small as possible, for what should 5 days good for? 🙂
Sure, the best way in my mind would be 24 hours before it expires…

Regards X23

@george1421 said in UEFI Screen Size:

vga=792

That seems to work as expected. I will do some more extensive testing of it this afternoon if possible and report back.

@Quazz
The device is a Lenovo X1 Yoga Gen 2.

There are no other devices on the subnet. I have the server physically and logically separated from all other networks/devices in my scheme. I will disable secure boot and report back.

EDIT: Secure boot disabled is letting me boot to the FOG menu now. I just need to change the MENU EXIT TYPE I think. When I chose the Boot From Hard Disk option, I got a “Chainloading” failure. I think once I get that straightened out, it will work.

EDIT 2: I changed the option FOG_EFI_BOOT_EXIT_TYPE to REFIND_EFI and it was able to boot successfully from the FOG Menu.

@Tom-Elliott said in CentOS 7 Problems:

The really feels like a double installation almost. Though I don’t know quite how to describe it.

I’ve fresh installed CentOS with fog at least 5 times now and keep getting the same result
I attempted a fog installation with Archlinux as well and got this same result.
by fresh install, I mean wiping the hard drive completely and installing a brand new OS, then installing fog

@Tom-Elliott said in CentOS 7 Problems:

Also can you please check FOG Configuration Page->FOG Settings->Web Server->FOG_WEB_ROOT and make sure it’s not set to WEB_ROOT, aka please set to /fog/

0_1498592218897_bandicam 2017-06-27 14-35-18-036.jpg

@Tom-Elliott said in CentOS 7 Problems:

Are you doing any weird redirects? For example FOG is expecting to look to /var/www/html/fog (http://SomeIP/fog/)
But you have it set to go: http://someIP and it’s passing you to the fog site?

This is a clean install, I haven’t changed any settings that aren’t stock

Yes. In the hour field 0, 23/2

Are you sysprepping? Was the reference machine previously joined to the domain?

For your images, you should keep them pure - never capture a dirty image because it only causes problems. Pure means NEVER having been on the domain before, and as lean & clean as possible meaning not using old images to make new ones - keep your old images as backups, but build from scratch (installation media) every time - always delete old partitions and remake them, and capture new images.

At my old job, I would include month and year (not day) in my image names.

@Sebastian-Roth Multicasting is working, so I don’t think it was a port issue. I ended up making another session for those 6.

I had another session afterwards with 25 computers (different model) that worked.

Issue only observed on Dell OptiPlex 3020 so far.

@Wayne-Workman It works. At the end, it is very simple. I just uploaded the .exe file and added /silent under Snapin Arguments. It works very smoothly. Just for future reference for other users, installing Citrix receiver is also slimier method. ie. CitrixReceiver.exe /silent.

Thank you all. 👍 🙂

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.