Posts made by george1421

This user ID and password is listed in the storage node configuration.

We typically see errors in this area when people change the password for the linux user account fog. We have seen people attempt to use the linux user account fog for system management. This linux account fog is an internal account used by the FOG system.

If you have changed this user account password you will need to resync the system. The current value FOG keeps in the file /opt/fog/.fogsettings. Take this value and reset the password for the linux user fog. Then go into the storage node settings for the fog server and ensure the management password matches the .fogsettings file. Once that is done, rerun the FOG installer installfog.sh to fix the rest of the bits.

For the next test I spun up a 50GB ubuntu image (knowing the default layout is on lvm) and captured that. We all know since the disk layout is LVM FOG will capture the lvm partition as raw even for single disk resizable. That means the LVM partition is not resizable from within FOS at this point.

Here is the ubuntu reference image layout

Here is the ubuntu image deployed to a larger hard drive (65GB target vs 50GB reference image) target computer.

Here is the results of trying to deploy a 50GB captured image to a 25GB target computer:

@tom-elliott While I’m not using a LVM disk deploying a 50GB image to a 25GB target computer seemed to work. I still have a 1.4.4 build on my fog server. I just copied over the inits.

jondoe@jondoe-VirtualBox ~ $ lsblk
NAME   MAJ:MIN RM    SIZE RO TYPE MOUNTPOINT
sr0     11:0    1   1024M  0 rom  
sda      8:0    0     25G  0 disk 
├─sda2   8:2    0      1K  0 part 
├─sda5   8:5    0 1021.8M  0 part 
└─sda1   8:1    0     24G  0 part /
jondoe@jondoe-VirtualBox ~ $ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            474M     0  474M   0% /dev
tmpfs           100M  3.6M   96M   4% /run
/dev/sda1        24G  5.3G   18G  24% /
tmpfs           496M   92K  496M   1% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           496M     0  496M   0% /sys/fs/cgroup
cgmfs           100K     0  100K   0% /run/cgmanager/fs
tmpfs           100M   20K  100M   1% /run/user/1000
jondoe@jondoe-VirtualBox ~ $ 

@george1421 Well setting the image to a smaller drive than the source DID successfully replicate the OP’s issue.

jondoe@jondoe-VirtualBox ~ $ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            474M     0  474M   0% /dev
tmpfs           100M  3.6M   96M   4% /run
/dev/sda1       5.9G  5.3G  296M  95% /
tmpfs           496M  112K  496M   1% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           496M     0  496M   0% /sys/fs/cgroup
cgmfs           100K     0  100K   0% /run/cgmanager/fs
tmpfs           100M   20K  100M   1% /run/user/1000
jondoe@jondoe-VirtualBox ~ $ lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sr0     11:0    1 1024M  0 rom  
sda      8:0    0   25G  0 disk 
└─sda1   8:1    0    6G  0 part /
jondoe@jondoe-VirtualBox ~ $ 

Note there are missing partitions too.

@tom-elliott Whoops I missed that bit about going smaller than the source disk. Let me queue up the test environment and see if I can duplicate that condition too.

During testing I also confirmed that shrinking the source image didn’t mess up the source computer. Everything appear to run ok on the source image.

Whelp, I can’t seem to duplicate your error. That doesn’t mean anything other than I can’t duplicate your errors in my lab. I tested on both vSphere and also virtual box on my LM laptop.

I simply downloaded a fresh iso of LM 18.2 Mate (I needed that iso for a home project anyway) and installed on the source VM. My source VM I created a 50GB hard drive and installed Mint 18.2 on it. I used all default settings, just an easy and quick install without making any decisions other than password. Once installed I pxe booted the target, registered with my FOG-Pi server and captured the image.

I created a new VM with a 65GB hard drive (different size than source disk by design), pxe booted, registered and then deployed at the end of registration.

Here is what I have the image definition setup as

lm_source

Here is the output df and lsblk of the source virtual machine.

jondoe@jondoe-VirtualBox ~ $ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            474M     0  474M   0% /dev
tmpfs           100M  3.6M   96M   4% /run
/dev/sda1        49G  5.3G   41G  12% /
tmpfs           496M   92K  496M   1% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           496M     0  496M   0% /sys/fs/cgroup
cgmfs           100K     0  100K   0% /run/cgmanager/fs
tmpfs           100M  4.0K  100M   1% /run/user/108
tmpfs           100M   20K  100M   1% /run/user/1000
jondoe@jondoe-VirtualBox ~ $ lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sr0     11:0    1 1024M  0 rom  
sda      8:0    0   50G  0 disk 
├─sda2   8:2    0    1K  0 part 
├─sda5   8:5    0 1021M  0 part [SWAP]
└─sda1   8:1    0   49G  0 part /
jondoe@jondoe-VirtualBox ~ $ 

lm_target

jondoe@jondoe-VirtualBox ~ $ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            474M     0  474M   0% /dev
tmpfs           100M  3.6M   96M   4% /run
/dev/sda1        63G  5.3G   55G   9% /
tmpfs           496M   92K  496M   1% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           496M     0  496M   0% /sys/fs/cgroup
cgmfs           100K     0  100K   0% /run/cgmanager/fs
tmpfs           100M  4.0K  100M   1% /run/user/108
tmpfs           100M   20K  100M   1% /run/user/1000
jondoe@jondoe-VirtualBox ~ $ 

ndoe@jondoe-VirtualBox ~ $ lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sr0     11:0    1 1024M  0 rom  
sda      8:0    0   65G  0 disk 
├─sda2   8:2    0    1K  0 part 
├─sda5   8:5    0 1021M  0 part 
└─sda1   8:1    0 63.7G  0 part /

As you can see on the target computer, its hard drive did expand to fit the size of the physical disk, which happens to be larger than the source disk.

From looking at the output of lsblk you an see that LM didn’t use LVM when creating the disk.

@xipher said in Failure to expand shrunken resizeable image from Linux machines:

The only commonality at the moment is that it’s Linux Mint 18.2 x64 being captured, and always with a swap at the start of the drive, then two logical partitions on a single extent after that

I will spin this test up in my home VM lab. I’m actually writing this post on on a LM 18.2 OS. I should be able to confirm that this is an issue later tonight.

@xipher said in Failure to expand shrunken resizeable image from Linux machines:

@george1421 your Windows centric response actually begs a question.

Since I’m deploying Linux images, is there less support for doing this than there is for Windows?

I’ve built images with and without using lvm on the captured host, thinking it was that, but now I’m starting to think that the support for this feature and people talking about it are deploying Windows, not Linux…?

Well my apologies, since 90% of the people deploy windows computers, I assumed without verifying.

@xipher Have you confirmed that both your reference image and the target hard drive are in good shape? If by chance your reference image was corrupted because of bad sectors on the master hard drive, or the target drive has errors the deployment could fail.

Do you have a virtualization environment available. The idea is just create a 30GB disk, dump a 1 or 2 gb file on it and then capture and deploy that image to another vm. You don’t need a huge disk for the capture.

FOG does work and it works great.

@xipher There has to be something unique with your configuration since image resizing on deployment does work very well. We just need to identify what is unique about your configuration that is keeping expansion from working.

While this isn’t a solution only a stop gap measure. Before FOG supported single disk resizable we would build our image on a 40GB vm. This size was picked because it was smaller than any disks we would deploy to. Then when we deployed to a 60GB drive (for example) the image would deploy at 40GB, and then we used the windows diskpart command to expand the drive to the size of the physical disk. This ‘expand’ command would be called from the setupcomplete.cmd batch file. This worked very, very well with fog 1.2.0 (the same could be said with 1.4.4).

@hugo OK I wanted to make sure you had the no_proxy in there. Typically you would put your proxy settings in like this

export http_proxy="http://<IP_Addr>:<Port>"
export https_proxy="http://<IP_Addr>:<Port>"
export ftp_proxy="http://<IP_Addr>:<Port>"
no_proxy="127.0.0.1, <fog_server_ip>"

For the proxy ones you need to ensure you have http:// in front of the proxy server address, and for no_proxy the loopback ip address and the network interface for the FOG server.

@hugo said in Storage node disk usage missing:

whereas my proxy settings are correctly set in wgetrc file and in bashrc environment variables (with “export” command)

Ok lets focus on this statement then.

So your fog server is behind a proxy server right?

If you key in the following command, please post the results here: set |grep proxy

you have me a bit confused on where your original issue is. You are linking settings that should not be linked.

First lets review your .fogsettings file (I don’t need to see it).

What I need you to do is confirm a few things.

1. You can log into mysql using the user id and passwords found in snmysqluser and snmysqlpass. These values need to be correct or fog will fall on its face. You just need to log into mysql using mysql -u <snmysqluser> -p and then enter snmysqlpass for the password. If that works then go on to the next step.
2. Confirm that you can login to the FOG server linux OS using the user account referenced by user id fog and the password listed in the field password in /opt/fog/.fogsettings file.

If those are set correctly then rerun the installer.

After that is done look at the storage node setting for this fog server. Ensure that Management Username == fog and Management Password matches the password found in the password field in /opt/fog/.fogsettings.

Don’t edit any other files.

@ariederer26 Yeah, for right now I would say upgrade to 1.4.4 and hold off on the 1.5.0RC series a bit (the new gui looks really nice though). There has been a lot of fixes between 1.3.5 and 1.4.1 around single disk resizable that you will need. The developers fixed a few nasty bugs in 1.3.5 and then polished the resizable functions in 1.4.1.

Will you check to see if this article applies: https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy

If you have unattended upgrades from ubuntu, that probably helped/broke your install.

@smartyparts Just be aware that legacy (bios mode) needs the undionly.kpxe iPXE kernel and uefi mode needs ipxe.efi. If you have a linux or windows 2012 or newer dhcp server you can have the dhcp server automatically send out the right file name based on the pxe booting target computer.

For uefi mode, secure boot must be off to boot into iPXE.

And we have seen (historically) lenovo systems running in uefi mode need firmware updates to fix the buggy uefi firmware. So typically we recommend you update your firmware first before chasing other issues.

I’m glad you are able to fog now!!

If the firmware updates don’t help (I really hope they do for you), then we will probably need to see a pcap of the pxe booting process. This pcap will tell us what is flowing down the wire between the target computer, fog server and dhcp server. This process only works really well when the fog server, target computer and dhcp server are on the same subnet. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

Upload the pcap to a cloud sharing service (google drive, dropbox, etc) and post the link here and we will take a look at it.

@smartyparts It sounds like you have all of the bits in allignment.

First of all what hardware are you trying to pxe boot (mfg model)?
Is this hardware in uefi or bios (legacy) mode. Knowing this will determine what iPXE kernel name you need to set in dhcp option 67.

You said you can download undionly.kpxe vi tftp client on a windows computer, right?

[Edit] after a quick google-fu search I have to ask is this pxe booting device a uefi hyper-v virtual machine? This error seems to pop up the most in references to uefi mode in addition to hpyer-v.

Is there any reason why you are running such an old release (in fog terms). The current release is 1.4.4 stable. There has been quite a bit of work put into disk imaging and resizing subsystem with FOG. I’m not going to suggest that upgrading will resolve your issue, but I question chasing something that may have already been addresses?

(this is just my personal opinion) At this time the developers are pushing hard to get 1.5.0 (stable) released. I don’t think they have a lot of interest in reviewing older 1.3.0 RC release code.

@crixx Ideally we’d like to get this working with iPXE, with Sebastian’s help we should be able to get things working.
If debugging iPXE fails, we do have a fall back method to boot FOS from a usb drive. There are a few caveats to do it this way, but it is an option. Lets try to discover what hardware the iPXE kernel is having issues with first.