MBR over 100mb ?? SVN3710
-
Hello,
I have one computer with windows 7 installed on only ONE partition (the little 100mb don’t exist).
When cloning the computer with Clonezilla Server, no problem.
When downloading the computer with FOG -> Invalid Backup File.So i checked the files and noticed that the d1.mbr generated by fog was over 100mb !!! I guess that is the problem. If i only save the MBR in the image setting, same way -> over 100mb. All my others mbr are 32kb.
Anyone ever have this bug ? Is there a workaround ? Is this a FOG bug or is this a bad partitioning schema ?
-
@Jean-Jacques-Morda Hi, you have no problem in upload task ?
-
Absolutely none. The MBR/GPT upload taking lot of time because it upload 100mb but no warning, no error, it is very strange. I suppose i’ll have to install the computer from scratch if i don’t success to make it works correctly with fog
-
@Jean-Jacques-Morda I’ve a image with multiboot (without 100Mb reserved system), upload is fine, download failed (but not the same problem than you). Before reinstall, Tom can help you (maybe) in debug task.
Could you post your image configuration (screenshot of FOG web UI) ?
-
Yes i could but whatever i change in image configuration, it is the same :
Windows 7 - Multiple Partition - Single Disk
Everythingor
Windows 7 - Multiple Partition - Single Disk
Partition Table and MBR Onlyor
Windows 7 - Single Disk - Resizable
Everythingor
Windows 7 - Single Disk - Resizable
Partition Table and MBR Only…
![Capture d’écran 2015-07-07 14.00.30.png](uploading 100%)
-
@Jean-Jacques-Morda Did you delete the 100MB recovery partition? Is this a “from scratch” image or is it based upon a manufacturer’s image?
-
Is the d1.mbr file 100MB, or is the d1p1.img file 100MB?
-
Yes, i’ve deleted the recovery partition because i never use those recoveries plenty of craps but i don’t think the is a link with the mbr problem. My others computers are working well but partitioning scheme is not the same.
I found clues … :
On working images, first partition is starting at 32kb … but with this one, coincidence, partition starts at 106mb … I think the mbr procedure is backuping all before the start of the first partition, not only mbr.
-
I’m just guessing, based on information, that the Manufacturer of this system is Dell?
-
@Wayne-Workman said:
Is this a “from scratch” image or is it based upon a manufacturer’s image?
-
@Tom-Elliott d1.mbr : 103424K and it’s not a Dell but an HP. Honestly, i don’t remember wich type of install. I’ll try to “move” the main partition to avoid the problem i think (if i can…). But it’s interesting to test if the first partition of a disk begins a 10Mb, the mbr will be 10mb…
-
Capturing all data up to the first partition was intentional. For GRUB2 bootloaders, the space between the MBR and the first partition is used to store extra data.
I suppose we could put an upper limit on the size though… -
@fractal13 said:
Capturing all data up to the first partition was intentional. For GRUB2 bootloaders, the space between the MBR and the first partition is used to store extra data.
I suppose we could put an upper limit on the size though…I just added an upper limit of 2MiB. @Tom-Elliott will get back to you on what SVN that fix will be introduced by. If you’re impatient, try out the dev-branch of the git repo.
-
@cspence Aren’t some MBRs larger than 2 meg ?
-
In fact, i didn’t noticed before but i have a warning unploading in one disk resizeable mode :
After resize test … /usr/share/fog/lib/funcs.sh: line 167: warning: here-document at line 165 delimited by end-of-file (wanted ‘EOFNTFS’)
-
@cspence Thank you, i’ll wait I’m testing uploading an image with moved first partition to see if my problem was due to the size of the crap before the first partition… result in two hours… i would like to discover why this one does not restore !
-
SO…
After moving partition to reduce space between mbr and first partition, i success to restore my image. By the way, dev-branch add the constraint to reduce max mbr size… so, i suppose problem is solved.