Issue Imaging Optiplex 780
-
0.33b Revision 1291 (The most up to date as of right now)
-
I know… I’m getting cut by the “bleeding edge” right now…
-
One moment. There may be a typo where the sysinfo isn’t appearing. That’s a simple fix. However you can do the compatibility thing real easy.
Go into debug mode from the option menu.
Once in run the command:
fog.sysinfo
You should be good.
-
I think you’re right Tom, I’m not sure what my revision is on this server right off the top of my head but I know it’s atleast a month old running 0.33b and I have the option but this is before the switch to iPXE and all that.
-
I found the culprit. The value wasn’t set for some reason. It got deleted. Sorry. It’s back in. r1292 released for this issue.
It also updated the TomElliott.config files (32 and 64) for 3.13.6 kernel and the init_32.xz file is truly included now.
Thanks.
-
The bootlooping you’re seeing in the other forum should be fixed now as well.
Sorry, I forgot to check if the tasking was all snapin or single snapin. Basically it found the tasking and sent you into an “imaging” type of task. Sorry about that. It should be good now.
r1293 released to fix this issue.
-
Ok, Thanks Tom!
I ran the Compatibility Check and it says it appears to be compatible with FOG, but at the top, just under the Title, it says “Error: Can’t have a partition outside the disk!”. I’m a little confused on that one.
-
are you trying to image a system that had a larger drive than the system you’re working on?
-
The original image was on a machine that had a 500GB drive. The older has a 250GB, but the actual partition is only 23GB…
-
Yep, still won’t work.
-
-
Nope. It’s smaller. Actually, it’s half the size.
-
What do you mean?
If the image came from a system with a 500GB drive, it cannot be put on a smaller drive. No matter how much you try! I talk about this in the post as well.
The size of the image doesn’t determine the size of the drives you can put it on.
If you imaged the systems in resizable mode, you’d be all set, but my guess is the image type was mps or mpa (multi part single/all disk non-resizable) You can’t take a larger disk image and put it on a smaller drive. The mbr can’t write to the hard drive.
-
:(… ok.
Luckily, I only have about 20 of these machines anyway… and all of my 7010’s have 500GB+ drives.
I wonder how Ghost did it then… I never had that issue before, that’s why it took me by surprise.
-
Whew!.. I just figured out how to save my butt here! I’m going to virtualize my 500GB drive onto one of my virtual hosts, then shrink the C:\ partition volume down to around 30-40GB, then shrink the virtual drive size down to match! Then, all I have to do is pull an image back to FOG.
-
[quote=“BigMan99211, post: 23884, member: 21932”]Whew!.. I just figured out how to save my butt here! I’m going to virtualize my 500GB drive onto one of my virtual hosts, then shrink the C:\ partition volume down to around 30-40GB, then shrink the virtual drive size down to match! Then, all I have to do is pull an image back to FOG.
[/quote]This is why I wanted you to run the compatibility check, it will tell you exactly where the issue is. It seems to think you are putting a larger image on the drive than what there is space.
This is probably the best idea… I have , in the past, used a Gparted live cd and fix your partition to be smaller that your SMALLEST hard drive in your corporation… When I create images I ALWAYS start with a small drive, ~ 30 gb. You CAN NOT find a drive for less than 80 GB unless you REALLY try. This give you the ability to put your image on a larger drive. Just add the portion to your unattend file that expands the partition to the end of the disc.
The size of the drive you image on is imporant, the ammount of spaced used by the image or on the fog server for storage is USELESS to calculate the size of an image or a disk.
-
It’s just a little frustrating getting used to the way FOG does things. In Ghost, the partition info was extracted directly to .gho files. So, you never had to worry about the drive size, as long as your actual partition information fit on the disk. Now that I think about it, it even pulled multiple partitions (whole drive image) the same way.
-
And in FOG we use Partclone and Partimage. The problem is we are using previously created services to complete the required task here. FOG is open source, it uses all open source pieces to complete the puzzle. These are free.
Ghost is a privately created and operated, it uses it’s own services specifically designed for Ghost, not a piece designed for something else but achieves the same goal. That is why ghost costs. They also have a development team… I know your heart is in the right place, but as long as you keep comparing FOG to another imaging solution that is maintained by a full team of devs, FOG is always going to seem to be lacking.
My corporation uses FOG because it is free and it is versatile.
Personally I tend to enjoy the fact of being able to over come my obstacles with my own knowledge of linux. I realize that not everyone has this experience, but if you continue to compare apples and oranges eventually your fruit will rot if you don’t eat it
