Where are they running the upgrade from?
Have they copied any files under / but not under the other mount points? There shouldn't be much of anything written to / so find out what the customer has copied onto the appliance and where.
du -xh /
This will give you the size of all directories on only the / partition. It will help narrow down where the issue is.
No, upgrade file was copied under /usr/tideway/tmp/
1 of 1 people found this helpful
OK, then check the du output to determine what it using the space.
Since your problem is with the /usr partition and it's unlikely anything has grown under /usr above /usr/tideway, I recommend starting with "du -ms /usr/tideway/*", then recursing to hog subdirectories like "du -ms /usr/tideway/var/*", until you find the space hog. If you're doing comprehensive scans with some logging limits at debug, it could be /usr/tideway/log filling your disk.
I usually use /tmp or /var/tmp for the upgrade, and they don't have room for both the gzipped and extracted installer, so I have to move one. If the installer is the culprit for you, move it to a partition that has room for it.
Did you find what the issue was. We have legacy 9.0.2 and working on upgrade but just to test, installed another 9.0.2 and when started backup and restore to the new one, it stopped with error and just like your issue, /dev/sda7 is 100% and not sure how to clear this out. Can you share what you found?
figured it out...