Do I need to add a new disk to increase the size of partitions?

[fjulianom]

Hi guys,

According to sk94671 we need to add a new disk to increase the size of the partitions. My firewall is installed on a VM on Nutanix, my customer has expanded the firewall current disk, I have reboot the firewall, but I cannot see the firewall recognizes the new expanded space:

[Expert@AGRFW-CPX01:0]# fdisk -l

Disk /dev/sda: 85.9 GB, 85899345920 bytes, 167772160 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 1048576 bytes
Disk label type: dos
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1   104857599    52428799+  ee  GPT
Partition 1 does not start on physical sector boundary.

LVM overview
============
                  Size(GB)   Used(GB)   Configurable    Description
    lv_current    12         8          yes             Check Point OS and products
    lv_log        20         12         yes             Logs volume
    upgrade       14         N/A        no              Reserved for version upgrade
    swap          3          N/A        no              Swap volume size
    free          0          N/A        no              Unused space
    -------       ----
    total         49         N/A        no              Total size

Is it necessary to add a new disk instead of increasing the size of the actual disk?

Regards,

Julián

[the_rock · Accepted solution]

Hey @fjulianom . Yes, I believe thats where lots of people sadly make a mistake : (. Its always recommended to ADD new hdd, rather than increasing existing one, as that can result in things not working according to that sk. I had customer once increase current disk and we could never get this going, not even with TAC help, but 3 times I helped people doing this when adding new hdd, worked like a charm.

Not saying its impossible to make it work with existing hdd, but I never found a way, but maybe someone else can chime in.

Andy

[PhoneBoy]

Yes.
We do not support using the disk expansion capabilities in VMware or other virtualization platforms.
The only supported method (short of a complete reinstall) is to add a volume and follow the procedures in https://support.checkpoint.com/results/sk/sk94671 

[the_rock]

I know sk says not to use disk expansion, but I know a customer that made it work. Does not explicitly say its not supported, but its pain to get it working, so better stick with adding new one : - )

[Sorin_Gogean]

Hello @fjulianom ,

Not sure what is different on Nutanix, but every disk extension, on a linux system, needs to be treated accordingly.

So, on that box in Expert mode, can you come back with the results of :

• parted -l
• pvdisplay
• vgdisplay
• lvm_manager (the print/view option)

We've extended partitions on our VM appliances - either GW or Management/Log server - numerous times, you just need to treat them as an Linux box up to a point.

Thank you,

PS: also in your notes, we're seeing that the SDA is 86Gb now but the system had allocated 50Gb - so was the SDA extended already or ?

Disk /dev/sda: 85.9 GB, 85899345920 bytes, 167772160 sectors

total         49         N/A        no              Total size

PS2: since it's a VM, DO A SNAPSHOT before doing anything, or whatever option Nutanix offers

[Blason_R]

That is not an issue and I did so many times where customers have increased the hard disk partition. Here is the simple procedure to get you started.

Follow this thread and it will get you sorted out.

https://community.checkpoint.com/t5/Management/Resizing-Disk-After-Increasing-Disk-Size-in-VMware-on...

[fjulianom]

Hi guys and thank you to everyone,

I asked to customer to add a new disk some days ago (to be sure to get it working), and he did it, and now I do see the new disk when running "fdisk -l". Tomorrow I will follow sk94671 to distribute the new disk space among partitions. We'll see...

Regards,

Julián

[the_rock]

Let us know if any issues, we can help...good job btw!

Andy

[fjulianom]

Hi,

Today I was following sk94671 and after resizing one partition, I rebooted and entered in maintenance mode to resize other partition. Then when the prompt asked for admin password, I entered the password as I did the first time, and the prompt said “failed”. I repeated several times unsuccessfully, but I am sure I was typing the correct password, as I did before resizing the first partition. Does it happen to you sometime? Is there a default password for maintenance mode? Finally I gave up and reverted to the snapshot I made.

Regards,

Julian

[the_rock]

Thats odd, as last few times I did this with customers, we never had to go into maintenance mode. What was last step you did BEFORE it went into maint. mode?

Andy

[fjulianom]

Hi Andy,

I went into maintenance mode because sk94671 says that in point 5 "You will need to reboot the server, so that Gaia will recognize the new disk. Enter Maintenance Mode from grub (if grub countdown does not show up, refer to sk164893)." My last step was step 21 "When the resizing process completes successfully, you will see... Press "Enter" for reboot."

After rebooting I went into maintenance mode again because I wanted to resize the other partition, then I had the password problem.

Then isn't needed to go into maintenance mode? Can I do the process just doing SSH to the firewall?

Regards,

Julián

[the_rock]

Thats how I always did it, simply from ssh, never needed maintenance mode. Happy to do remote tomorrow if you are free and we can check.

[fjulianom]

Hi Andy,

This is very strange. Now doing the process by SSH works pretty well, but the problem is the following. The first time, when I run the verifier in Gaia, it showed this:

So, I only needed to put more space to lv_current. Then, after adding the new volume (30 GB) and so on, here you can see the disk partition before resizing and how I put 22 GB to lv_current:

After resizing and rebooting, I accessed the firewall again and the lvm_manager showed 22 GB to lv_current, and 20 GB in free (I didn't take a snapshot). Then, I run the verifier on Gaia again and then showed this:

Now it turns out that I need much more space in /var/log (which wasn't shown when I run the verifier the first time), and now the lvm_manager shows this:

Now free is only 9GB, the missing 11 GB has gone to the upgrade line! (before upgrade was 14 GB, now is 25 GB). I was thinking to put just 20 GB to lv_current (what it showed the verifier the first time) and assigning to /var/log this 2GB which I rescued plus the free 9 GB, but anyway I can't reach the 20.140 GB which shows the verifier. What can I do? Ask for new disks to customer? Who knows what will show the verifier next time?

Regards,

Julián

[the_rock]

Its really hard to say 100% why it does that, makes no sense to me either, based on your screenshots. If you are willing to do remote, happy to check, or you can contact TAC and see what they say. I feel confident having done this 5 times before that I can figure it out.

[fjulianom · Accepted solution]

Hi,

I open a TAC case about why the verifier said the first time the space requirement for the root partition but not for the /var/log partition, and they just told me:

Regarding the error messages, they are displayed in a specific order, starting from the top and progressing downwards to indicate the one that triggered the issue. This explains why the lv_current partition error was displayed before the lv_log partition error.

I asked for new disks, and after I got them I managed to partition and add the required space to /var/log. Now the verifier doesn't throw me any error message for the upgrade.

Regards,

Julián

[the_rock]

Good job!