target partition size is smaller than source
-
When did you update to trunk? How old are these images?
-
this morning and 09/2014
-
Does this seem to be sporadic? Or limited to a specific set of machines? How long as this been occurring, or was today the first you saw of it?
-
only today, this machines work well before.
I’ll try on Fujitsu S710 (image create 09/2014) and Dell E6400 (08/2014)
I’ll try on Dell E5500 (image create 04/2015) and work fine
-
@TheKoR I only ask what I ask because, if all was working last week, I haven’t changed the inits. So for today to be having the problem indicates to me that the disk that was in that system maybe much smaller than what the original image disk was? It’s only a guess.
Of course I don’t know all the details which is part of why I ask the questions I do.
-
it’s the mbr partition who fail /dev/sda1
Last time i’ll try on a s710 was 27 april.
-
I don’t remember when it all happened, but if the image is of “resizable” nature and was uploaded form around mid 3200’s of SVN until 3396, it likely didn’t not truly upload in resizable format. While the disks did resize, the mbr was not copied in the shrunken state. This is likley the cause of the problem you’re seeing?
-
can you put the rev on the image information ? i don’t remembre which rev was installed when i create my image
-
@TheKoR said:
can you put the rev on the image information ? i don’t remembre which rev was installed when i create my image
I second that.
I already am labeling my images with the revision information after the resize issue was discovered.
-
Can you look at this?
https://wiki.fogproject.org/wiki/index.php/Known_FOG_Bugs#The_Image_Resize_Bug -
@TheKoR Can you verify if you have an SSD and regular HDD on this system? It seems that it’s trying to write to the ssd, which I’m guessing is smaller than the original source disk.
-
Hi, it’s regular HDD.
160Go and 160Go on the one image load.
I have download a standard win 7 and remake my image
-
Up to 3480 : no problem anymore
-
