Resizable issue with bootloader
We have just finished migrating to 1.2.0 and everything is working well except for one issue.
On any image we attempt to pull (windows 7 is what we have tested with), We create an image (single disk resizable) and upload the image and it uses PartClone and it uploads the image without any error messages. However, when we deploy the image…it sends it, says “done” for all steps and then “task complete”. The system then boots and hangs with “cmain()…” If you press F12 and tell it to boot manually from the SATA drive…black screen…nothing…will not boot at all. If we enter debug mode and mount the partition however, everything is there.
As far as we can tell, the bootloader/mbr is getting hosed with a resizable disk.
I’m just double checking as to if resizable is now working in FOG. I know it didn’t work in version .32 with 7 but i thought that it was working in this version.
[quote=“Cpasjuste, post: 39741, member: 25902”]Yep i confirm that the deployment is now working, thanks :) (without re-uploading)[/quote]
Yep i confirm that the deployment is now working, thanks :)
What Tom said is correct. Once the install is updated to current SVN, just upload and deploy.
I will say this. Getting to the lattest SVN will also fix ALOT of other issues too.
Sure ! I’m on it, i’ll report tomorw :)
Edit : i should come more on the forum as i’m on this problem since 3 days now :)
You “should” be able to update and redeploy. If you have any issues, please just let me know.
Hi, i have the same problem. I’m also willing to try the svn version, but how does it will work ? We should still rebuild a new image or should we be able to just update fog server then re-deploy ?
I was wondering about that. We saw the start boundry shift from 63 to 2048 and figured it was something with that but wasn’t sure how.
I’m willing to give SVN a shot. This is a feature we have been really wanting to use. Got a lot of people ready to upload new resizable images :D
Thanks for the help!
This is because my thoughts are correct.
Just in a different order.
In 1.2.0 back to 0.32 the resizable image makes assumptions of the layout of the image.
0.32 created all images starting on sector 63 of the hard disk.
1.x.x does not.
What’s causing the image to not work is because 1.x.x to 1.2.0, during download imaging, used at start sector of 2048. Your image, and I’m just guessing, is a single partition Windows 7 image. Meaning there’s no 100MB first partition, just the main data containing partition (or c:).
The image is starting to write data at a that point, while your boot manager (windows side) is expecting the data to be at sector 63.
There is a fix in SVN if you’d be willing to give that a shot. If you can’t, the best method to retain the operation of the image would be to use the non-resize or recreate the image from scratch and re-upload.
All of our images are from .32 but i am not trying to “re-upload” to an existing image. I’m trying to create a new one for the resize feature.
The thing is, I created a brand new image entry for the resizable feature and uploaded off our master machine to FOG. When i try to deploy that image, that’s where the problem happens. Here is the process i have tried.
.32 non-resizable image sent to dell 755 master
Create new 1.2.0 resizable image in FOG
Upload Dell 755 master to 1.2.0 resizable image
Once finished, download 1.2.0 resizable image to other Dell 755s
Not one of them will boot with the issue above.
We went back and fourth an tried a non-resizable 1.2.0 image and it works fine. It’s just when downloading the resizable image does it break something.
My guess, then, is you first deployed a 0.32 image and then attempted to reupload?
GPT fdisk (gdisk) version 0.8.6
Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: not present
Found invalid GPT and valid MBR; converting MBR to GPT format.
Disk /dev/sda: 156250000 sectors, 74.6GiB
Logical sector size: 512 bytes
Disk identifier (GUID): FB90AD12-7961-4862-A2E3-B10D08EC4769
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 156249966
Partition will be aligned on 1-sector boundaries
Total free space is 17871 sectors (8.7 MiB)
Number Start (sector) End (sector) Size Code Name
1 63 156232124 74.5 GiB 0700 Microsoft basic data
[root@10 /]# _
From the system that you uploaded the image from
can You go back in and run the upload task again but as a debug task?
Host Management -> list/search relevant host -> Basic Tasks -> Advanced -> Upload - Debug?
Then once in the terminal, type gdisk -l /dev/sda and give us the contents?