FOG is resizing the incorrect partition (/boot - /dev/sda1) on my CentOS 8 image deployments

[marcusjfloyd]

Hey everyone!

Using FOG 1.5.9 on CentOS 8.2.2004

I’ve been testing FOG. I created a 20GB CentOS 8 image. I was able to deploy this image just fine to another vm of the same 20GB size.

I ran a test to deploy it on a 40GB disk and it resizes the /boot - /dev/sda1 partition to take up the remaining 20GB of space:

What I really want is for /dev/sda2 to be resized to take the increased space. Is there a way to make that happen in FOG config or should I create a new image that doesn’t use LVM partitions?

Sorry if I missed something in the documentation. Any help is appreciated.

[Sebastian Roth]

@marcusjfloyd said in FOG is resizing the incorrect partition (/boot - /dev/sda1) on my CentOS 8 image deployments:

Is there a way to make that happen in FOG config or should I create a new image that doesn’t use LVM partitions?

FOG cannot handle LVM for in resizable image types. So you can either use non-resizeable image type and apply a post-deployment script to so the resizing for you or switch to a non-LVM setup.

In the other hand it’s interesting FOG did resize sda1 - being /boot in your case! Let’s take a look at this and make sure you don’t run into another tripping hazard with this. Can you please run parted -s /dev/sda print on your CentOS 8 VM and post a picture of the output here?

[marcusjfloyd]

You got it:

Here’s from the base image that it was created from:

Let me know if you need anything else or if there’s anything else I can do to help.

[Sebastian Roth]

@marcusjfloyd What I was looking for is the “Flags” column. We check for those flags do decide weather it makes sense to resize that partition or not. With the boot flag set it should not try to resize it. Looking through the code I found that the resize algorithm does not detect the boot partition if there is only one non-LVM partition on the disk (code reference). So it should work properly if you don’t use LVM.

Would you prefer to keep LVM and use post-deploy scripts or setup a new master VM without LVM?

[marcusjfloyd]

Thanks for the explanations.

Initially, I was thinking if I deploy to hardware, then I’ll stick with LVM and run a post-deploy script. And if I’m deploying to a vm then make another image that doesn’t use LVM to take advantage of autoresizing.

But I think the best solution for me is to be consistent and use LVM and a post-deploy script for both hardware and vm deployments. FOG would be handling ~95% of my hardware deployments.

[Sebastian Roth]

@marcusjfloyd The more I think about it the less I find it was wise to propose you have two options here. So far we told people to use normal partitioning because we never found the time to properly implement LVM support. Neither have I tested FOG with LVM setups in a long time. Now that I saw you had it deploy a LVM partitioning already I thought we might give this a try but I want to make sure you understand that using post-deploy scripts is more in your responsibility. While we will help you set it up and try to help when you have issues with this it’s not like FOG officially supports LVM out of the blue. Probably there are drawbacks with this as well.

Is there a good reason why you want to use LVM in those systems?

So if you still want to stick to using LVM we first need to fix the scripts to not resize /boot (sda1) in your setup. Then we’d need to add commands to expand the physical volumne (PV), logical volume (LV) as well as the partition and filesystem within the LVM container.

[marcusjfloyd]

Yeah I didn’t expect FOG to assume responsibility for that. My plan is to make the image non-resizable in FOG; have FOG deploy the OS; and then automate this process in my ansible awx setup and make it part of the deployment process there since I’m already using ansible to setup the OS anyways.

[Sebastian Roth]

@marcusjfloyd Alright, sounds like you don’t even need any help with the post-deploy scripting. Just in case this is of any use for you: FOG can run scripts right after the deployment while it’s still PXE booted. You might want to read George’s post on this topic.

Just let us know if you need a hand.

[marcusjfloyd]

Thanks. If this is something the community is interested in, then I don’t mind giving it a shot via FOG post-deploy scripting. Maybe it would be something that could be integrated into the code base eventually.

[george1421]

@marcusjfloyd said in FOG is resizing the incorrect partition (/boot - /dev/sda1) on my CentOS 8 image deployments:

I don’t mind giving it a shot via FOG post-deploy scripting

With post install scripts, they are bash scripts that are executed post image deployment but before FOG reboots the target computer.

How I would go about working out the script is this. Schedule a deployment to your target hardware, but before you press the schedule task button, check the debug checkbox. Now pxe boot the target computer. After several screens of text, that you need to clear with the enter key you will be dropped to the FOS Linux command prompt.

<sidebar> If you want to remote debug the target computer running FOS Linux do the following.

1. Key in ip a s and collect the IP address of the target computer.
2. Give root a password with passwd, give it a simple password like hello. Don’t worry on the next reboot the password will be reset.
3. Now use putty from a windows computer or ssh from a linux computer and remote into the target computer using the ip address, user root, and the password you set in 2.

Using a remote computer give you the ability to debug the computer and copy and paste commands into the target computer used during debugging. You can copy to and from the target computer using scp. </sidebar>

Now you have a linux console on the target computer work out the commands needed to expand the LVM Group and then the logical volume to the size of the physical disk. Once you have the commands worked out then you can start developing your bash script.

[Driver]

@Sebastian-Roth after 4 years I have the same issue. My golden image partitions look like this:

sda                         8:0    0    12G  0 disk 
├─sda1                      8:1    0   572M  0 part /boot/efi
├─sda2                      8:2    0   1.8G  0 part /boot
└─sda3                      8:3    0   9.7G  0 part 
  └─ubuntu--vg-ubuntu--lv 252:0    0   9.7G  0 lvm  /

After deployment the boot partition has been enlarged to the size of the entire disk instead of LVM:

nvme0n1                   259:0    0 465.8G  0 disk 
├─nvme0n1p1               259:1    0   572M  0 part /boot/efi
├─nvme0n1p2               259:2    0 455.5G  0 part /boot
└─nvme0n1p3               259:3    0   9.7G  0 part 
  └─ubuntu--vg-ubuntu--lv 252:0    0   9.7G  0 lvm  /

What should I do in this case?
A. Prepare new golden image without LVM (I want to avoid it)?
B. Change image type from Single Disk - Resizable - (1) to Multiple Partition Image - Single Disk (Not Resizable) - (2) ?

There is no big deal for me to extend LVM partition after deployment manually if FOG is unable to do this. I just don’t want it to resize other partition than LVM.

[Tom Elliott]

@Driver while I’d love to support resizing and working with LVM, we do not currently support it. There’s functions to try but I never got around to incorporating it or getting it tested and functioning. Maybe we could revisit but I can assure you I am completely at a loss on how to do it. That’s not to say it cannot be done, I just focused on all things else besides this and the fog client. All help/any help is appreciated especially if it makes fog that much more robust and usable.

[Driver]

@Tom-Elliott Thanks for the clarification, but please let me know if I can at least somehow avoid resizing the current partitions (especially boot partition), such as by checking Multiple Partition Image - Single Disk (Not Resizable) - (2)?