Error uploading and download fog 1.0.0
-
It’s a fresh install of 1.0.0 updated today to 1.0.1 under Ubuntu server 14.04 LTS 64 bits.
I have uploaded the same VM two days ago under a version 0.32 without problem with partimage.
But I try now to update it for the futur version of FOG by backup it with partclone. -
So the image itself is working? Meaning if you reboot the system, Windows Comes up?
-
I think it’s a bit a mess to understand since i have spoke about two problems in this topic.
Right now, i try to make working an image upload from a syspreped VM to the server.
So, the error display in the screenshot is to backup my VM.
If your question is also about the image i try to upload to the server, yes, it reboots fine after displaying the error.About the download (deploy) of the image made with partimage under fog 0.32, i’ll look later since i have the 0.32 server still running.
-
I have try to use partimage to upload my image but it keeps putting back the “image manager” to partclone during the upload task on the VM.
Even create a new image do the same thing. -
1.0.1 does not upload any images in partimage format. I was under the original impression that you were trying to download an already created 0.32 image to the system. You will not be able to upload an image using partimage, unless you do it via command line.
-
I focus on the upload for now since i use my syspreded VM as base for all my computers (around 600).
To sum up, i have the “open /dev/sda1 error” when i try to upload it.
Windows cleaning (pagefile and other things removed) before upload works fine so why after it doesn’t.Any idea or test to make ?
-
I’ll try to think of something but do you have gpt or mbr disk? Don’t trust windows get into a debug task and run the command [code]gdisk -l /dev/sda[/code]
-
I have MBR disk.
I tried to free space at the end of the partition with gparted.
It remove the warning return by you command but the error about the open of the /dev/sda1 remain.Is the screenshot helping you more than me ?
Any solution to that ?[IMG]http://img4.hostingpics.net/pics/353491Windows7x6420140516151428.png[/IMG]
-
I don’t understand well why there is a warning since i have only one partition of 40 Go.
-
Here is the result after partition resized and with 2mo removed at the end.
[IMG]http://img4.hostingpics.net/pics/862378Windows7x6420140519105005.png[/IMG]
but here is was i get from sda1 and this is strange :
[IMG]http://img4.hostingpics.net/pics/595807Windows7x6420140519110159.png[/IMG] -
This is because the device is setup under gpt and not mbr. You’ll likely need to recreate the image but first run the commands gdisk -Z /dev/sda so all portioning information is removed. Doing this will erase all acess to the partitions and you will have the ability to make this an mbr image. Just ensure Uefi is disabled as well.
-
I’m not sure i understand what you want me to do.
I am working on the image since nearly a year.
There is more than 1Gb of data and many script on it.
I could clone the disk but this will also backup the wrong stuff.So, will i keep the data using your command or is there a way to do it ?
I can create a new disk but i don’t know what to do after that…I know my request is not link to FOG but if you can help me, i would appreciate a lot.
-
[quote=“jmeyer, post: 27406, member: 6537”]Here is the result after partition resized and with 2mo removed at the end.
[IMG]http://img4.hostingpics.net/pics/862378Windows7x6420140519105005.png[/IMG]
[/quote]The above picture is showing the data for what I imagine to be a Windows XP image? And it contains one partition worth of data. That said, the second partition table looks like it’s a partition table for a linux OS. Is this correct? Based on what I’m seeing, there’s a GPT partitioning table present, but only on the logical partition of /dev/sda1, this does not appear to be setup correctly and no amount of information I can give is going to fix that.
[quote=“jmeyer, post: 27406, member: 6537”]but here is was i get from sda1 and this is strange :
[IMG]http://img4.hostingpics.net/pics/595807Windows7x6420140519110159.png[/IMG][/quote]Based on what I see here, If you don’t want to make any changes and this current setup is working for you, then maybe create the image as RAW type rather than Multipart Single Disk, or Multipart All disk, or Single Disk (resizable).
Things to check, I guess, would be a couple of things.
[LIST=1]
[]Make sure the image type is correct. Go to the Image Management Page, and choose the image you’re trying to work on.
[]Make sure the OSID is assigned properly on the image. In V0.32 and below, the OSID was attached to the Host. Since 0.33 and up, the OSID is now assigned to the image. As the FOG System appears to be able to “operate” without issue, this is unlikely your issue, but just verify it is setup correctly, though if you do a RAW image it ultimately won’t matter what OS is assigned.
[]Make sure the image type is set correctly. Single Disk (resizable) should be sufficient for a sysprepped system, but that’s not to say this will still work. Chances, to me, seem more likely that my initial suspicions are correct. While gdisk -l /dev/sda isn’t showing that this is a GPT partition table, the gdisk -l /dev/sda1 appears to show that this IS a GPT partitioned disk image. Is the VM set to load up with EFI? If it is, this is likely the reason we’re seeing such “funniness” on the partition. If you want to not end up recreating the image you will probably want to try with the Image Type set to RAW. While it will take longer and will also copy all 40GB rather than just the data on the drive, it’s one method to ensure all the data stay’s in tact. If this is not the approach you want to take you could try step 4.
[]While in the debug task as you are here where you can type commands, try using the command fixparts and see if it can properly convert the system to MBR for you. I don’t know if it will fix the issue directly, but maybe it can help you (and me for that matter) correct or find the root of the issue.
[/LIST]
Hopefully this helps. -
Maybe you didn’t remember what i said in my previous messages but with all the work you do this is understandable.
This is Windows 7 64 so there is nothing of XP or Linux on it.
I made it under VMware with 40GB drive to be allowed to deploy it on any computer (old, current and future) on my network so raw format can be used.
The scripts in it handle drivers, fog client conf and windows licences.
So we call it “Windows 7 Generic”.Plus, i need to share the image file to co-workers and use it in other network so the less size it take, the best it will be to move it.
Maybe use your command then use the fixmbr could help in my case ?
-
[quote=“jmeyer, post: 27414, member: 6537”]Maybe you didn’t remember what i said in my previous messages but with all the work you do this is understandable.
This is Windows 7 64 so there is nothing of XP or Linux on it.
I made it under VMware with 40GB drive to be allowed to deploy it on any computer (old, current and future) on my network so raw format can be used.
The scripts in it handle drivers, fog client conf and windows licences.
So we call it “Windows 7 Generic”.Plus, i need to share the image file to co-workers and use it in other network so the less size it take, the best it will be to move it.
Maybe use your command then use the fixmbr could help in my case ?[/quote]
I hope so. I don’t know though. There’s too many variables to play around with the generation of an image. The easiest I could imagine for your case would be to re-download the image as a PartImage then try pushing it back up. I know you’ve already tried this, but maybe you could create a new VM that is specifically setup for MBR/Legacy means? I’m sure you didn’t set EFI before, but something has give this system GPT partition tables to the /dev/sda1 partition.
I do realize it’s Windows 7, but the gdisk -l /dev/sda picture resembles that of a Windows XP partition table. A base install of Windows 7 usually creates two partitions.
/dev/sda1 will usually be a 100 MB partition that contains the Windows boot recovery information.
/dev/sda2 is usually the main “data” partition that we all usually see displayed on our Windows systems as the “C:” drive. -
We have remove the usual 100Mb partition to be able to upload it as single partition.
And the sector boo not made at the 63th sector by windows was already a problem to solve.
I’ll try use the fixmbr in windows since i work under a VM with snapshot, i can revert it at anytime if it doesn’t work.
I’ll also see with the old co-worker that made the original version to see if we find out something.Could this GPT problem could also bring a problem for download ?
As said in the few first message, I have saved an edit of this image and after deploy using partimage, Windows doesn’t boot.Thank you for your help and advises, i’ll look further on my side.
-
The problem with the boot, seems to me, not anything you’re doing wrong but how FOG interprets Windows 7 style imaging especially on the creation of partition tables.
FOG makes a few assumptions based on the OSID even under 0.32 and higher.
Single Disk resizable with Windows 7 doesn’t use any backed up MBR. So if you create a “fresh” image of Windows 7 but remove the 100MB partition, but doesn’t know that this is the case. FOG is making the assumption that the Base install of Windows 7 is what was performed. So, with all of that said, it generates the 100MB partition and the second partition no matter how you ACTUALLY created the image. I hope that makes sense and may shed light as to why you’re unable to boot. If you want to remove the 100MB partition, that’s fine, but DO NOT use Single Disk Resizable for the image type under this method as it will NOT work.
-
From my memories, we don’t “remove” the 100MB after the install but we create the partition before installing Windows to avoid Windows handle it itself and create that 100MB.
-
I have check with the creator of the image i used to build my VM.
He never created this strange partitions.
I’ll make a “fresh” install and keep the 100MB partition then try again to back it up as single partition. -
Sorry, I forgot to reply.
Upload works fine with the normal windows installation.
Now, i’ll look for the problem of downloading old image.
