Fog 1.2 and Imaging to SSD
-
Had this on the backburner but as new machines are in bound with SSD’s time to find a solution.
I have tried formatting the drive before imaging. Attempt to image, fog begins to load then restarts and says job complete. When i got check the partitions again on the disk it has created the partitions as per the image but of course no data.
I am using a machine that images standard hard drives perfectly but as soon as SSD enter the equation it fails.
Does anyone have any other ideas? -
What kind of image is it? (e.g. Multi Part, resizable, raw?)
My guess is:
The disk you’re attempting to image to is smaller than the image is expecting, therefore the partitions are outside of the boundaries of the disk.
-
I’ve had this before with brand new hdd’s on Panasonic Toughbooks.
Boot from a GParted live usb stick or cd and see if the ssd is flagged with a yellow warning triangle. If it is, use GParted to put a bog standard MS-DOS partiton table on the drive, then try Fog again. Always works for me.Cheers
Robin -
yeah, I mentioned that, in case there is no partition label, fogpartinfo --list-parts barfs, and it dies… solution is to use parted /dev/sda mklabel msdos (or gpt)…
And that can be done in the fog debug client
-
Hi All, thanks for the replies, it turns out the particular image i am using doesn’t like going to SSD so that gives me something to rebuild. Probably should open a new thread but will just ask here. We are buying a fleet of Hp 210 G1 netbooks. They have a realtek NIC but will not boot into FOG. Any help would be appreciated as i need to start these over the next couple of weeks.
-
Were you able to get the 210’s to image? We have 300 that just arrive and I’m not having much luck.
-
@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.
