Resizable issue with bootloader
-
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?
-
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 /]# _ -
My guess, then, is you first deployed a 0.32 image and then attempted to reupload?
-
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.
Adam
-
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.
-
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
Thanks for the help!
Adam
-
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 ?
-
You “should” be able to update and redeploy. If you have any issues, please just let me know.
-
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
-
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.
-
Yep i confirm that the deployment is now working, thanks
-
[quote=“Cpasjuste, post: 39741, member: 25902”]Yep i confirm that the deployment is now working, thanks
(without re-uploading)[/quote]
