Ok updated to SVN 3348 still seeing the resize issue it is still intermittent and may or may not affect the same machine twice in a row. I ran a debug task on one that failed and manually ran the resize command as you can see in the pic attached the command not so much fails as sees the partition as already ok even though its still at the deployed size.
[url=“/_imported_xf_attachments/1/1956_2015-05-04 08.24.04.jpg?:”]2015-05-04 08.24.04.jpg[/url]
The newest SVN has a new field for the new fog client that auto populates it may have defaulted to that one over the legacy client or cleared the legacy client password check the settings for both.
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.
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.
Wouldn’t full registration do the same thing?
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?
Check your permissions sample command below.
ls -laR /images
Double check image type and os.
It is possible but you need to run SVN and DHCP user classes as described in this thread. [url]http://fogproject.org/forum/threads/fog-ver-1-2-0-uefi-legacy-boot.11566/[/url]
Maybe check and make sure firewall is disabled?
sudo ufw disable
Try the following commands.
sudo chown -R fog.root /images
sudo chmod 777 -R /images
SVN 3317 seems to have fixed the issue on my test machine will test further today but I think that’s got it.
Option 67 on your DHCP server.
Still not resizing even after changing ownership on both the main server and the storage group.
The most common cause for reboot loops after imaging that I’ve seen is that the bios has a different drive type set then the one you uploaded from ACPI vs ide ect…
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
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.
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.
Not recently according to webmin I have 6 updates pending.