@fry_p You didn’t do anything wrong. Thanks for at least keeping us posted.

https://forums.fogproject.org/topic/7738/customizable-ipxe-menu-text-colors

Cross linking.

Hopefully this helps.

Found the problem. Motherboard battery was dead and the power went out yesterday. Date was reset to 2005.

Corrected the date and HTTPS works again, and installed NTP to cover my ass.

@Wayne-Workman
Thanks for the info that did the trick for me all up and running now. You can mark this as resolved.

Thanks for the explanation - much appreciated Wayne.

I will take a look.

Tom

That reminds me of another point from above. As long as your current dhcp server is not sending out dhcp options 66 and 67 or you don’t have altiris current on that subnet, you can setup dnsmasq to supply the missing dhcp information without touching your managed dhcp server. If you do have altiris or current dhcp options 66 and 67 on your main business network then your isolated network is the best choice for this install. You can setup the FOG server to act as the dhcp and dns server for your deployment network.

Areca cards work well in both environments, they are all pretty universal. I’ve used quite few different models in both OS’s (DebianLinux and Windows) . Debian has support built as modules (arcmsr) into the kernel out of the box, and those modules are also by default in the initrd. I’m not sure what the FOG kernel/initrd are based on, but I would imagine it couldn’t be too hard to add if needed.

I can attest they are fast cards, and fully support 4k sectors and 64bit LBA, as well as some SSD specific options.

One thing to be aware of - most OS’s aren’t aware of TRIM support for RAID drives. Some controllers expose emulated TRIM and convert it to drive level TRIM, but that is rare. Consequently, SSD’s will wear out rather quickly in a RAID array with a lot of writes.

@RobTitian16 That’s what I’ve done, yes. I discovered, by luck, that not appending anything to memdisk works for certain ISOs. I use Parted Magic frequently, so I was happy to get it working. I’ve never seen this documented anywhere…glad you’re working!

@Tom-Elliott

That resolved the issue. Thank you so much for the time. Please resolve this ticket.

Thank you
Chakri

@SteveB689 search the wiki for .fogsettings it explains each item.

Awesome help george 1421!!! That was my issue all along was that I was not using the /var/www/html/iso, but I was pointing directly to just /iso. It all makes sense now. Thanks for all the help!!! WinPE is successfully booting for me!!! Great work FOG and thank you for the advanced menu!!!

@Tom-Elliott After dropping and updating to latest git, I was able to register my computers. I’m now running into an issue pulling my first image, will start another thread for that. This one is solved!

Thanks Wayne really useful to know.

Regards,
Tom

@Quazz I can FTP into my fog server. I don’t think that is the issue. However, I rebooted the server and am trying the upload again.

Thanks for helping on this Tom.

After installing the latest trunk to a new VM and importing my db, I failed to realize that I need to update the credentials.
Thanks for all your help on narrowing this down.

@yusrijamal said:

EXT4-fs (ram0): couldn’t mount as ext3 due to feature incompatibilities

That’s because we use ext4 in the newer inits but FOG 1.2.0 does not pass a kernel option to tell it so. This is just a warning and does not harm anything!

sd 5:0:0:0 alua: Attach failed (-22)

Read through this. Guess this can be ignored as well.

sd 5:0:0:0 [sdb] No caching mode page found

The message is harmless I reckon but I still wonder why it says sdb (second hard drive)?!?

Please do as advised. Try newer kernel with old init files. If that does not work you can still look into properly upgrading to trunk version to be able to image that new hardware.

Great to hear that the new client fixed this! Just for further references: My guess is the old version of the client did send the VPN adapter MAC address or something like this.

@Wayne-Workman said:

That makes a lot of sense to me. Does the inits assume it’s re-sizable if those files are present?

While I am still not sure this was the issue I am pretty sure that things can go wrong if you simply change from resizable to non-resizable (plus use different size destination disks) without uploading again. But the inits do not assume resizable just because those files are there - they do the image type configured in the DB and just try to use the partition information available (d1.partitions in case of non-resizable) ignoring the other stuff.

As I said: It doesn’t have to cause trouble but it’s likely to.

@TomBagley Glad you figured it out. With what you described, I would not have guessed this.