Hard drive resize is not expanding
-
Description
Server
- FOG Version: 1.3.5 RC 7
- OS: RedHat
Client
- Service Version:
- OS: Windows 10 Enterprise
Description
We just noticed today that since updating to version 1.3.4 the hard drives are not expanding to use the rest of the HDD. I saw someone else had a similar issue, so I updated to 1.3.5 RC 7 and that did not fix the issue. Once the update did not fix the issue I thought maybe it was the image since I had uploaded it after updating to 1.3.4, but I used an older image and it had the same issue. As of this evening I’ve only been able to test this out with our UEFI image. I’ll try to see if we have the same issue with our BIOS image in the morning.
-
Moved to bugs and also pinging @Tom-Elliott so he’s aware.
@Doctrg please let us know about your BIOS tests in the morning.
Also, mechanical drives or SSD ? What version of Windows is the image? -
What size was the HDD you uploaded the image from compared to the drives you’re now deploying to? (Are the new drives smaller?)
I suspect this is due to partition start/end points not being shifted around, at least not easily.
-
Can you post the contents of one of this non-expanding images d1.partitions and d1.fixed_size_partitions and d1.minimum.partitions files?
-
I shall ask the obvious here too. The “older” image you used had no issues expanding in the past?
-
@Wayne-Workman The drive type is both spinning and solid state. The OS is Windows 10 Enterprise. The BIOS image resized without any problems.
@Tom-Elliott The size of the drives are below:
500GB HDD -> 256GB SSD
128GB SSD -> 256GB SSD (this is the older image that was created around August 2016; the drive showed up as a 128GB drive after imaging)The older image has not had any issues in the past as far as I can tell.
Here is the contents of the files:
I ran a Deploy Debug and it said that it resized sda4, but it did not.
Thank you for your help in advance.
-
@Doctrg Do you know when the “old” image worked?
Which image is the “old”? The pictures you posted, I’m guessing, are the “new” image correct?
-
Also, based on what I’m seeing, the original image is from a disk that was 1TB? I’m gathering this by the size of the 4th partition in d1.partitions file. It appears to be 975 GB (as just a guess).
-
@Tom-Elliott That is a newer image that I posted. You know, since you asked if it was created on a 1TB drive since it is showing the 4th partition, I’ve sorta decided to rebuild that image. I thought it was odd seeing that 4th partition since none of my other images have that.
-
Windows 10 defaults to a 4 partition layout typically. Particularly in the cause of U/EFI secure boot.
-
@Tom-Elliott I didn’t know that… Learn something new every day!
-
@Tom-Elliott I’ve also learned something new today as well. I installed Windows 10 on a PC with a 500GB hard drive and uploaded it to FOG. I then deployed it to another computer with a 256GB SSD and it came up as a 15GB drive. I’ll post the contents of that image.
-
@Doctrg Well the good news is data is “shrinking appropriately”, the bad news, I have no idea what’s wrong.
-
Can you download from a debug session again?
When the image completes, get us the output of
fdisk -l /dev/sda
-
@Tom-Elliott I did some testing before your last post, but I’ve got some outputs for ya. What I did is installed Windows 10 barebone to both machines and created a totally new image entry in FOG.
This output is from the 500GB HDD to 256GB SSD:
And this output is from the 256GB SSD to 500GB HDD:
-
@Doctrg We need to know what version you were on before you started having this issue. Please answer this question directly.
This command may help you figure out what version you came from. Please post the output.
ls -la /home
-
@Wayne-Workman We were on 1.3.2 and we were having issues uploading so we updated to an RC of 1.3.4. As far as I know everything was working at that point, but once I saw there was a stable version of 1.3.4, I updated to that.
-
@Doctrg It looks like you came from 1.3.0 previously. The 1.3.2 installer would have made a directory with 1.3.2 in the name had the 1.3.2 installer been ran - this is fine.
What I’m thinking, you probably won’t agree with. What I would want to do is ask you to setup a 1.3.0 server and manually transfer this broke image to it and see if it works on that setup or not. This would involve DHCP changes or an offline environment which can be challenging to setup if you’ve not done it before. It’s a lot of work. OR… you could share this known-good image with us (not via forums but via private messages and Mega or Dropbox or Google Drive) and let us test the image with the various fog versions and figure out what’s going on. Many of the active Developers and Moderators have test environments at home (like myself) that are setup to test whatever fog related stuff we want without any real work involved.
The reason why your thread has gotten the attention it has is because of how you are responding (professionally, with logic, soundly). I think that you know that this image really was a good image prior - so I really want to look into this to see if there’s anything at all wrong with fog. We’re trying to determine when it worked, and when it broke. For that, we need someone to do the testing. Either you with your own environment just for this thing, or you can share the image with someone here for testing.
-
@Wayne-Workman It would be helpful if I can send the image to one of you guys. I do not have control over our network so making DHCP changes would be out of my hands and we are in the middle of moving our offices so I do not have an offline environment setup yet to do testing. I’m downloading the image for the storage node now and will upload it to my Google drive once it is done.
-
@Wayne-Workman I’m still working on getting the files uploaded. Who do I need to PM to send the link to the shared folder? Also, what program is being used for the resizing? My co-worker that has been the FOG administrator since the beginning is wondering if we can try to do a debug deploy and do a verbose on the resize.