Images not expanding

[Wayne Workman]

Try a different kernel? 3.18.5 x86_x64

Just a stab in the dark, easily reversible.

[Joseph Hales]

Kernel 3.18.5 same issue.

[Wayne Workman]

Is this Ubuntu 14.04 ?

[Joseph Hales]

12.04

[Wayne Workman]

Have you ran any updates lately on the OS? did you update when you updated FOG?

I’m not asking you to, I’m just asking if you did or not.

[Wayne Workman]

Also, because I’ve got the day off today and have time, I’m going to update the home FOG server to the latest revision and then run a test download image.

I’ve got 1 image at home (lol) and it is set to re-sizable. We’ll see if it works or not…

[Joseph Hales]

Not recently according to webmin I have 6 updates pending.

[Joseph Hales]

The server install is less then a month old. but no os updates have been done since it was setup and the issue showed up at SVN 3293 for me.

[Wayne Workman]

I updated my FOG server & OS.

I just successfully imaged using r3315.

This was a resizable image, however it is WinXP.

It was a 5GB image, deployed in about 4 minutes and expanded to fit an 80GB drive.

I’m not sure if the mechanisms are different for Win7/8 but it does work for XP.

[Wayne Workman]

Can you check the permissions on your /images directory?

[CODE]ls -laR /images[/CODE]

They should be uniform and owned by FOG and the group FOG. OR the user root and the group root (at home, it’s root for me).

[Joseph Hales]

Mine are owned by user jhales which is a sudo user but the resize command is independent of the image deployment permissions on the server shouldn’t have any effect on the resize operation.

[Joseph Hales]

Ok fixed ownership I think will test example of new permissions below.
/images/HPCompaq8100EliteSmallFormFactor160Gig:
total 6880348
drwxrwxrwx 2 fog root 4096 Apr 21 16:18 .
drwxrwxrwx 50 fog root 4096 Apr 22 10:42 …
-rwxrwxrwx 1 fog root 2 Apr 21 16:18 d1.fixed_size_partitions
-rwxrwxrwx 1 fog root 512 Apr 21 16:18 d1.mbr
-rwxrwxrwx 1 fog root 259 Apr 21 16:18 d1.minimum.partitions
-rwxrwxrwx 1 fog root 30 Apr 21 16:18 d1.original.fstypes
-rwxrwxrwx 1 fog root 259 Apr 21 16:18 d1.original.partitions
-rwxrwxrwx 1 fog root 0 Apr 21 16:18 d1.original.swapuuids
-rwxrwxrwx 1 fog root 8498875 Apr 21 16:18 d1p1.img
-rwxrwxrwx 1 fog root 7030049063 Apr 21 16:18 d1p2.img

[Joseph Hales]

Still not resizing even after changing ownership on both the main server and the storage group.

[Wolfbane8653]

r-3316 – Has a bit of a change to the [SIZE=15px][FONT=Lato][COLOR=#3d3c40]expandPartition information. Maybe try to update to latest revision???[/COLOR][/FONT][/SIZE]

[Joseph Hales]

SVN 3317 seems to have fixed the issue on my test machine will test further today but I think that’s got it.

[Wayne Workman]

[quote=“Joseph Hales, post: 46369, member: 18131”]SVN 3317 seems to have fixed the issue on my test machine will test further today but I think that’s got it.[/quote]

Awesome! updating NOW!

[Joseph Hales]

Ok so far I have a report of one PC at a campus not resizing but the same image and model here works fine anything come to mind that might just affect the resize command the farther you get from the server?

[Tom Elliott]

Nope, my guess is it didn’t get hit with the image command after your update.

[Joseph Hales]

Removed the storage node still seeing random occurrances of not resizing for example 2 identical machines at a campus same hardware, same image, same location one resized the other did not. Looking to see if networking issues could account for this.

[Joseph Hales]

Three questions how is the resize command sent to the host and if I interrupt the debug task right where the the command is sent what command would I type exactly to send the command manually and what command would display the partion’s size after to determine if it worked correctly.