Upgrade to OS 8.1.3

[jdprovine]

I am currently on OS 7.1.19 and am planning my upgrade path to the best version of 8 sometime soon. In order to upgrade do I have to install the base 8 version or just download it? 

[jdprovine]

@OtakarKlier

Yeah I am not sure how much clean up I can do

[jdprovine]

@OtakarKlier @BPry

I took a couple unused OS out of the software,  I am on 7.1.19 and still have 7.1.16 on it so once I take that off I should regain another 391 megabytes but that is still close since I need 1.3 GB to ugrade to 8.1.x

Filesystem Size Used Avail Use% Mounted on
/dev/md3 3.8G 2.8G 833M 78% /
/dev/md5 7.6G 3.7G 3.6G 51% /opt/pancfg
/dev/md6 3.8G 2.4G 1.2G 67% /opt/panrepo
tmpfs 2.0G 116M 1.9G 6% /dev/shm
cgroup_root 2.0G 0 2.0G 0% /cgroup
/dev/md8 198G 118G 70G 63% /opt/panlogs

[OtakarKlier]

Hello,

I would say delete everything except the version you are currently on. 

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClimCAC

Regards,

[jdprovine]

@OtakarKlier@BPry

Yeah even with that it just gives me 1.5 GB of free space and I need 1.3GB just to do the upgrade.  Are these the best links for freeing up space

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClatCAC

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClaJCAS

[OtakarKlier]

Hello,

I guess you could always open a case and have them take a look? 

Just a thought.

[jdprovine]

@OtakarKlier @BPry @reaper

Yeah I did that a month or two ago and it filled up again. I think these are the main partitions I need to free up 

/dev/md6              3.8G  2.4G  1.2G  67% /opt/panrepo  - PAN-OS Image repository.(Device/Software)

/dev/md3 3.8G 2.8G 831M 78% /  -  OperatingSystem and it's logs ('daemon' logs)

[BPry]

@jdprovine,

Partitions would continue to fill up as you continue to utilize the device and perform normal maintenance such as keeping the PAN-OS version up to date. Until the time comes that you're a few days out from doing the upgrade, I wouldn't put much time into space management. 

When it comes to /opt/panrepo you'll have plenty of space when you start doing the upgrade. At that point in time; the only software images that you should have would be whatever the latest maintenance release is at the time, and the base version that you wish to move to. Upon the completion of the base image install you would remove the last maintenance release and start the upgrade to your target maintenance release. This should always see you having enough space to upgrade everything. 

[jdprovine]

@BPry

I don't understand this comment - "When it comes to /opt/panrepo you'll have plenty of space when you start doing the upgrade" Are you counting the space of the one I am upgrading from? Right now I have  7.1.16 (391mb)  & 7.1.19 (391 mb) and my estimates are based on removing 7.1.16 before I start the upgrade and I don't usually remove the previous OS files until I have had enough time to be sure that I don't need to roll back. I am working on this now while I have time so when I do have to upgrade I have all the information that I need to cleanup a few days before the upgrade..

I was really surprised how fast, just a couple days, for the cleaning done by TAC to be filled again.

[reaper]

I agree with @BPrys comment

panrepo doesn't need to be empty for you to be able to perform upgrades or to be able to roll back

There is the secondary system volume that contains the previously installed PAN-OS. so in case you need to roll back ,you actually don't need install files (a simple >debug swm rever > request system restart, will do the trick)

Just keeping the previous version's base image around will save time and space also (downloading a maint version you want to go back to, in case the swm version is not far enough back, is pretty quick)

In case you don't want to rely on download speeds etc, you can also keep a local copy of the OSs you want to be able to roll back to

[jdprovine]

@reaper @BPry @OtakarKlier

That makes sense that it does not have to be empty to do the upgade but what if the size of the files exceeds the space available? I calculated that downloading the base 8 OS (no install) was 800mb and the 8.1.13 incremental upgrade was 500 MB, a total of 1.3GB.Currently I only have  1.2GB on the panrepo partition. I have toggle between the two partition you are talking about and I have done that neat little revert trick, but I have a big fear of running out of space, since the space is finite and the OS's keep getting bigger. Download speeds are good here never had any issues.

My goal is to make sure I understand the space issues on the PA and how those are affected by upgrades. I have a guideline of what partition does what, thanks to you guys, I know about the partion with the  current os installed and that the previous OS is on another partition and it is possible to toggle between the two unless you have removed the previous OS. But I am a little confused when I see a limited or lesser amount of space available than what I am downloading/installing and how all that works.  

Filesystem    Size        Used     Avail      Use%       Mounted on
/dev/md3     3.8G      2.8G     820M     78%         /
/dev/md5     7.6G      3.7G     3.6G       51%         /opt/pancfg
/dev/md6     3.8G      2.4G     1.2G       67%        /opt/panrepo
tmpfs            2.0G      116M   1.9G       6%          /dev/shm
cgroup_root 2.0G 0   2.0G     0%                         /cgroup
/dev/md8    198G     118G    71G        63%       /opt/panlogs

[BPry]

@jdprovine,

You'll want to follow the current install recommendations, which since you are using 7.1 and wishing to go to 8.1 means your install path would look like the following: 

7.1.* (whatever version you are on) -> 7.1.* (Latest Maintenance release)

7.1.* -> 8.0.0 (Install the base image)

8.0.0 -> 8.0.* (Latestes Maintenance Release)

8.0.* -> 8.1.0 (Install the base image)

8.1.0 -> 8.1.3 (Target)

Throughout the upgrade path you'll be downloading/uploading the images as needed, and then removing the images you no longer require. So once you have installed 8.0.0 remove all 7.1 images; when you are on the 8.0.* maintenance release remove the 8.0 base image so you have the space for 8.1.0 if needed, and continue to utilize that method. 

If you go down that path there should never be a time where you are unable to download a new image due to storage restrictions. 

[jdprovine]

@BPry

Don't I eliminate a quick roll back by deleting the 7.1 image, course if I don't have the space what choice do I have LOL?  So I do have to install 8 not just download it?

[BPry]

@jdprovine,

Since you're jumping multiple versions you kind of ruin the whole quick rollback scheme even if you had the space for all of the images. 

Yes, you would want to install 8.0.0 instead of just downloading it. A new recommendation was released a while back that has all base images installed instead of just downloaded due to space limitations on some of the older boxes. When you have to explode both the images on disk and pick and choose pieces of them to build a working install image you start to run out of disk space rather quickly. 

[jdprovine]

@BPry

So I guess I have to download and install 8, delete 7.1.19 and then download and install 8.1.3 :P. Rollback would be to download and reinstall 7.1.19 or is there no roll back. This is probably going to be one of my trickier upgrades, its always so nerve racking working on the gateway to the whole network LOL, luckily we have an HA pair

[reaper]

@jdprovine

there are 2 roll-back options:

The clean one is to reload the previous partition, which in the case of major upgrade only requires the base image for that major code train to exist in the repository (as the maintenance version is installed on the disk)

the dirty one is a reinstall of an older version, which requires both base and maintenance release in the repository

hope this helps

(the recommended steps are to download, install and reboot into the base version first, then download install and reboot into the latest/recommended maintenance version

after that last step rolling back to your starting version becomes the dirty solution, as you overwrote the secondary partition with the base image)

chances are very slim you'll actually want to roll all the way back to your initial version, especially if you've taken precautions to prepare an upgrade plan using recommended releases and during a maintenance window (and keeping a cool head 😉 )

We also have professional services gals and guys you could hire to come do the upgrade for you, if you're in the market for risk mitigation

(I'd come over but my wife won't let me 😉 )