@Strahd At the least I’d suggest downloading an export of your hosts/images:

From there you can delete the database or rebuidl from scratch by:

mysql -u root If you have a password on your db I don’t know it but use the -p and you’ll be prompted to enter it.

DROP DATABASE fog;

Will delete everything.

From there, I still highly recommend you delete the /opt/fog/.fogsettings

Then rerun the installer.

I’m still going to say use working-1.6 as the testbed.

I hate that you’re having issues and I assure you I’m unable to replicate the problem you’re currently having which makes trying to fix your specific case impossible of course.

Hope this helps.

I’d still (at the least) get a full backup of your DB just in case something goes horribly wrong.

@Tom-Elliott said in Wiping Drive via PXE menu:

@vanfifty1 Sweet so it is functional and seems to be much more verbose about the actions it’s performing, thank you!

Thank you!

With the experimental init.xz when it said the following in my case: “Erasing /dev/nvme0n1 with an NVMe sanitize block erase (sanact 2)” does this mean the following command was run?: nvme sanitize /dev/nvme0n1 -a 2

Does this mean the bug is patched? Should I use the experimental init.xz file on the production FOG server? What ramifications will this have? Is it better to wait until this is released in an official version down the road?

@Tom-Elliott Tom, looks like everything has been resolved after going from 2144 to 1.5.10.2218! No errors and I was able to capture no problem. Thanks

Working 👍

@JJ-Fullmer This was it, thank you!!

Everything I read kept telling me this machine was x86 based and there is no hint in the BIOS or the serial number lookup tool, of it running an ARM processor(other then “Elite”). We are going to return these machines to the vendor, so problem solved for us.

Would be interested in hearing about future support for ARM in FOG because I’m sure this isn’t the last time we will cross paths with it.

@Tom-Elliott Hi! I updated my FOG server to latest beta-branch version: 1.6.0-beta.3197. I also updated my storage node to 1.6.0-beta.3197. This fixed the invalid path issue I was having. Thank you for the help!

1a0e5491-b776-49fe-9fbf-d2bc40087f78-image.png

@Tom-Elliott

Thanks so much for your help with this. Happy to feed back any info I can so please do let me know if there’s anything else you need me to test. Will be on annual leave for a couple of weeks after this and have no access to the systems but I think this confirms your suspicion. Please see results below from a Dell OptiPlex 3070:

Addresses on this machine:

NIC: 01:00.0 (Realtek RTL8168h)
Root port: 00:1c.0

UEFI mode:

setpci -s 01:00.0 CAP_EXP+10.w = 0142 (last digit 2 = L1 enabled)
setpci -s 00:1c.0 CAP_EXP+10.w = 0c42 (last digit 2 = L1 enabled)

Legacy/CSM mode:

setpci -s 01:00.0 CAP_EXP+10.w = 0040 (last digit 0 = ASPM off)
setpci -s 00:1c.0 CAP_EXP+10.w = 0c40 (last digit 0 = ASPM off)

Dell’s UEFI firmware enables L1 on both the NIC and root port. The Legacy/CSM path leaves both off. The only difference between the two readings is those two ASPM bits. Everything else in the register is identical.

Thanks for the nudge to run these. Anything else needs testing please do let me know. We love using FOG and it’s invaluable in our set of schools that we work in at least so please do keep up the great work!

To check the BitLocker status, open an elevated Command Prompt and run:

manage-bde -status

If the C drive shows as encrypted, disable BitLocker and allow the drive to fully decrypt before attempting another capture:

manage-bde -off C: manage-bde -off D:

Have you tried setting the image type to “Multiple Partition Image - All Disks (Not Resizable)” instead of “Single disk - resizable”?

In “Single disk - resizable” mode, you will save an image of only one of the two disks. In the host settings, you can set the primary disk.

Try disable Windows Fast Boot or restart computer from cmd

shutdown /r /t 0

@Tom-Elliott said in How to upgrade to FOG 1.6?:

@Tom-Elliott, Thank you very much for the comprehensive guide. All the necessary files for secure boot were signed correctly when upgrading from 1.5.10.1903 to 1.6.3200 I encountered a few problems, however. I’am now on 1.6.3279.

1. Secure boot

I set my dhcp server (FortiGate) to forward DHCP option 67 (set filename) “secureboot/snponly-shimx64.efi”. On my computers that already had an enroll key, so:
loading snponly-shimx64.efi OK
loading bzImage OK
no FOG task -> refind should be loaded -> SECURITY VIOLATION

I don’t know why, but for some unknown reason the file /var/www/fog/service/ipxe/refind_x64.efi is not loaded and the file refind.efi is loaded, which was not signed, so I signed them additionally and now the whole boot process works as it should, then no more secure boot errors.

root@fog:/var/www/fog/service/ipxe# sbverify --cert /root/sbkeys/FOG_SB.crt refind_x64.efi Signature verification OK root@fog:/var/www/fog/service/ipxe# sbverify --cert /root/sbkeys/FOG_SB.crt refind.efi warning: data remaining[237128 vs 262592]: gaps between PE/COFF sections? Signature verification failed root@fog:/var/www/fog/service/ipxe# sbsign --key /root/sbkeys/FOG_SB.key --cert /root/sbkeys/FOG_SB.crt --output refind.efi refind.efi warning: data remaining[237128 vs 262592]: gaps between PE/COFF sections? Image was already signed; adding additional signature root@fog:/var/www/fog/service/ipxe# sbverify --cert /root/sbkeys/FOG_SB.crt refind.efi Signature verification OK 2. Web GUI

In the menuStorage Node-> List All Storagegroups, I see a table with a list for only one row, but I have 12 storage groups created. I can scroll through them using the mouse wheel, but only one row is displayed. Tested in Firefox and Chrome on Windows 11.

storage_group.png

In the menuStorage Node -> List All Storagenodes, the same problem as the previous Storage Group.

3. iPXE menu

The new item “Enroll Secure Boot Key” did not appear in the iPXE menu, but I had to add it manually. I have FOG 1.6 installed as a clean installation in another virtual machine. Just for testing. In this clean installation, this iPXE menu item was there, but in the version upgraded from 1.5.10 it did not appear. I had some custom items added to the iPXE menu before the upgrade. Maybe that caused the new one not to be added?

@toschulz So I suspect the problem is due to a divergence of db schema between dev-branch/stable + working-1.6

If you can update yoru Mysql directly:

sudo mariadb -u root fog (if no root password of course - if you have a root password add -p

UPDATE schemaVersion SET vVersion=0;

Then refresh your screen, click the install/update, and hopefully the error will go away.

The way the schema is configured is it will attempt (idempotently) to rerun every single SQL query in the schema chain.

This should fix the problem you’re seeing.

I believe there’s a column on the login history piece being requested that may just simply be missing which would cause the issue with datatables.

@DiegoP I believe mdadm will still be allowed to work, but I think you’re supossed to use “mdraid=true” for a kernel argument. If this is not set, FOG won’t know to build the array. This would help explain why the disk couldn’t find a partition layout as well since it’s expecting to be part of an array (which then looks/acts as the disk you’re truly working with.

As for “partclone to partimage” I’m not sure I understand.

Fog moved FROM partimage -> partclone way back in the 1.0.0 days as partimage has been obsolete for quite some time now.

@Tom-Elliott

Thanks for your quick response. We’ll be using Fog heavily over the next few days, so we won’t be able to update the version right away.
We’ve found a workaround while we wait for the update by setting the setgid bit on the directory:

chown fog:fog /images/dev
chmod 2775 /images/dev

Best.

Jérôme

@Tom-Elliott Hi, Yes with the proposed fix, it works now.

@Tom-Elliott
The fix worked perfectly! The menu issue is now resolved.

Thanks for the support!

@Tom-Elliott Hello Tom yes I have installed the compatible Fog client from the Fog server on the reference machine, sys prepped and captured the image and now I am deploying.

@Tom-Elliott
Updated to latest dev-branch and snapins are working now
Thansk for help.

@rpycroft Please attempt to update to 2231.

I have figured out the issue. I was looking in the wrong place in BIOS for the secure boot setting which was on. Turning off secure boot fixed the process which runs perfectly now.

@JasonNaughton

Hi, I noticed that this was unresolved after so long. Wonder if you have solved it?
I recently stumbled across the man page for dhcpcd.conf. In there is a denyinterfaces (pattern) should solve the issue for you. It tells dhcpd to ignore the nic interfaces listed in pattern. Just was wondering if you found the fix otherwise hope this helps.

** WARNING: /etc/exports still exports with no_root_squash.
** Captures land as root, so moving the image out of
** /images/dev fails with ‘550 Rename failed’.
** Replace the /images/dev export options with:
** all_squash,anonuid=1002,anongid=1002

Fixed problem