MBR over 100mb ?? SVN3710
-
@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.