Updated from FOG 1.5.10.1667 to 1.5.10.1771 Fatal Error: No valid drives found "Host Primary Disk"
-
FOG 1.5.10.1667 to 1.5.10.1771
Running on Ubuntu 24.04.2 LTS
Last night, I captured an image from my PC. FOG was version 1.5.10.1667 everything went fine. Today I updated to FOG 1.5.10.1771 then went to test capturing an image from that same PC, no changes were made hardware wise etc.
This happened. No valid drives foundNOTE: I use the drive serial number for Host Primary Disk because I have 2 NVME drives which are the same size. <— Could this be the problem?
I bypassed PXE boot and went into Windows fine.
I restored the FOG server (It’s running in a VM) from a backup prior back to 14 hours earlier version, when it was running 1.5.10.1667. And it captured fine. What is going on!?
-
@Fog_Newb For this host in question, are you indicating a serial number or wwn identifier for the drive? On this machine, it seems you have entered 21297930000130911023 on the Host Primary Disk field within the UI. Just trying to understand.
-
Hello Tom,
Yes, I am using the disk serial number (21297930000130911023) in the Host Primary Disk field. It’s been working fine going on a few years now.
-
@Tom-Elliott Should add… I have 2 NVMe drives that are the same size. And since they initialize randomly at each boot, I can’t specify /dev/nvmeXXX
https://forums.fogproject.org/topic/14822/nvme-madness?_=1753960837885At some point, a few years ago, someone said you could use the drive serial number if both NVMe drives are the same size, and it’s been working for a long time now.
-
@Fog_Newb It seems I introduced a bug on the init’s specifically surrounding a request to fail out if the Host Primary Drive is defined but not found to error out.
Effectively I tried to make a function more robust (normalize output data) but it only works on direct input rather than piped input. I’ve made a correction to fix this miss, but it will take about 2 hours to build.
Maybe I can get you to help?
I am currently building a new set of init’s under experimental: https://github.com/FOGProject/fos/tags
When it completes it will show up as EXP_20250731 (I think?) but if you can download the init and test it on your machine, this should fix the issue you found so thank you for reporting it.
-
Yes, I will test these as soon as they are available and have access to the PC, around 2pm EST. Just to confirm, the steps to test would be - update to 1.5.10.1771, then drop the everything into /var/www/html/fog/service/ipxe/ and try to capture again?
Thanks
-
@Fog_Newb No.
You shouldn’t have to touch your fog install (overall) to test the latest init files.
Just download the init.xz file from the EXP_20250731 tag and either replace your existing /var/www/fog/service/ipxe/init.xz with it, or put the filename you want to use (init_20250731.xz for example) in the same folder and set the Host’s Host Init field to the filename you created.
Once that’s known to be working, you are welcome to update to the latest version of fog, but you would still have to do the same work for the new experimental init files. We could potentially work to make these working fos files the latest “release” which might fix the issue for you, but first would like to know it’s working.
Luckily init’s are released as a separate funciton so it wasn’t FOGProject 1.5.10.1771 directly, but just the init’s having issues.
-
@Tom-Elliott Thanks.
I grabbed the new init.xz and copied it to /var/www/fog/service/ipxe/ and I was still able to capture the an image from the PC with FOG 1.5.10.1667. I updated FOG to the latest 1.5.10.1771 and tried to capture from the PC again and it failed with same error. -
@Fog_Newb Did you update the init to the one you downlaoded after updating to 1771?
The init that it is pulling by default has the bad data.
-
@Tom-Elliott No, but I just did now and it is working! Thank you. So for now, whenever I update FOG, I should copy over that init until it is worked into the dev or release version?
-
@Fog_Newb Yes, though maybe I can get the master release updated and it take hold for anyone from that point forward who gets 1771, but that’s not great practice, that we fall into better waiting the monthly release I think.
-
@Fog_Newb The fos release has been officially updated so if you were to do a full fresh update, it should pull the version you just tested automatically.
Thanks for the testing.
-
@Tom-Elliott Awesome sounds good. Another one can be marked as Solved
-
[[undefined-ago,
T Tom Elliott, ]]
-
@Tom-Elliott Thanks. I grabbed a full fresh release but haven’t had a chance to reinstall 1.5.10.1771 over itself to confirm the included inits work. But if they are the same inits you posted earlier… it definitely should
-
@Fog_Newb Yeah, we did release the experimental as the “release” version so it should be the same init you get for 1667 or 1771 now.
-
@Tom-Elliott Fog now tells me the latest dev version and the one I have is 1.5.10.1671
Was 1.5.10.1771 all a bad dream or were we both mistakenly calling 1.5.10.1671 1.5.10.1771?
-
@Fog_Newb probaly just typoed it and i went with it too lol.