Fog 1.2 and Imaging to SSD
-
@marcalle What version of FOG? and are you trying to use a manufacturer image or a “from scratch” image ?
-
Fog is on 1.1.2. (We tried version 1.2.0, however ran into AD issues not registering Full Host machines). At this point, I’m just trying to boot into FOG’s Registration GUI. It is the only machine out of 9 models we have that won’t go.
I applied the latest kernel in hopes that was it, but it was not. It sounds like the same issue that Baron was having.
-
@marcalle Some basic things to check is:
- Secure boot needs turned off in the firmware
- If using UEFI, use a .efi bootfile.
- If using Legacy/BIOS, try undionly.kkpxe
Also, 1.1.0 is aged… Your problem might just go away if you move to 1.2.0. If you have issues with that, that’s what the forums are for. There are people that are willing to help.
-
@Wayne-Workman I’d be willing to try out 1.2.0, but I heard I may lose all of my existing images. Is that true?
Secure boot is off in the BIOS, it is setup to use undionly.kkpxe already. We’ve been using Fog for about a year at this point, and this seems to be the only machine causing issues.
-
@marcalle lol you will not lose your images. The only way you’d lose them is if YOU delete them yourself… or your HDD dies.
Also, and I don’t know why it isn’t a more popular topic but,
people in general need to back up their images…
HDDs die… this is a fact of life and there is nothing that anybody can do to stop it. You wouldn’t believe how many “sys-admins” on here say “I lost all my settings because I didn’t have a DB backup”, or… “my HDD died and I lost all my images”… Really? Backing up stuff for safety should be intrinsic in I.T. folk.
There should never, ever be any situation in which an I.T. person is left “without” important data.
You can easily use Samba to share your images directory and easily copy your images off to a windows desktop or windows server or NAS or SAN. You could easily boot up a live Linux CD and access the images directory via NFS and copy everything in it from the fog server to some other server. Or you could mount a CIFS share from the FOG server itself and copy images over to a remote directory. You could even recursively copy the images via FTP if you wanted.
and in 1.2.0, you can easily backup your database by doing this: FOG Configuration -> Configuration Save -> Export ; Host Management -> Export -> Export
And, of course I’ll always tell people to backup images and database. Not for fear of FOG deleting them, but for fear of users deleting them, or some misconfiguration or mistake that renders the server crippled or bricked. It’s just good practice to backup and there’s never a reason why you shouldn’t backup.
-
@Wayne-Workman Gotcha. I have backups of the images, I suppose a better way to word my concern would’ve been to say “incompatible” with the new version.
I have backups of the hosts and config DBs, as well as images, so I’m not concerned about that! Backups are key. I don’t feel bad for those who don’t do backups haha.
-
Got Fog updated to 1.2.0. The 210’s still don’t work though, still gets stuck on the iPXE right before the fog GUI loads (before the php files get called).
Looks to me that it might be a driver issue, but I’m not positive.
-
So…in desperation, I found this article:
https://wiki.fogproject.org/wiki/index.php/Chainloading_PXE_to_iPXE_using_pxelinux.0
This method boots up the 210 G1, however it breaks all the other machines from booting to the GUI PXE haha. I dont really understand what that “chainloading” is doing though.
-
@marcalle Not really an answer but it’s a good start.
-
@Wayne-Workman Unfortunately I have no idea what that means for me haha! I’ve messed with it a bit more today, but haven’t found out why.