This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

v19 VMware disk usage, reporting full

I've deployed VI-19.0.0_GA.VMW-317.zip last Sunday and migrated SFOS 19.0.0 GA-Build317 from old SFV4C6 to this new one (because of swap problems). Veeam ONE Monitor starts to send Guest disk space "/var" alarms today. It looks like SFOS v. 19 image has much less space for /var than v. 18.5. (along to https://community.sophos.com/sophos-xg-firewall/sfos-v19-early-access-program/f/discussions/133616/v19-hyperv-disk-usage-reporting-full).

SFV4C6_VM01_SFOS 19.0.0 GA-Build317# fdisk -l
Disk /dev/sda: 16 GB, 17179869184 bytes, 33554432 sectors
2088 cylinders, 255 heads, 63 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Device  Boot StartCHS    EndCHS        StartLBA     EndLBA    Sectors  Size Id Type
/dev/sda1    1023,254,63 1023,254,63   33144832   33423359     278528  136M 83 Linux
/dev/sda2    1023,254,63 1023,254,63   33423360   33554431     131072 64.0M 83 Linux
Disk /dev/sdb: 80 GB, 85899345920 bytes, 167772160 sectors
10443 cylinders, 255 heads, 63 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Disk /dev/sdb doesn't contain a valid partition table

SFV4C6_VM01_SFOS 19.0.0 GA-Build317# df -h
Filesystem                Size      Used Available Use% Mounted on
none                    640.6M     11.6M    582.3M   2% /
none                      2.9G     24.0K      2.9G   0% /dev
none                      2.9G     16.9M      2.9G   1% /tmp
none                      2.9G     14.7M      2.9G   0% /dev/shm
/dev/boot               127.7M     26.6M     98.4M  21% /boot
/dev/mapper/mountconf
                       560.3M     93.4M    462.9M  17% /conf
/dev/content             11.8G    493.4M     11.3G   4% /content
/dev/var                  3.7G      3.5G    174.5M  95% /var

SFV4C6_VM01_SFOS 19.0.0 GA-Build317# df -m /var
Filesystem           1M-blocks      Used Available Use% Mounted on
/dev/var                  3776      3589       170  95% /var

SFV4C6_VM01_SFOS 19.0.0 GA-Build317# du -d 1 -m /var/|sort -nr|head
2995    /var/
945     /var/tslog
742     /var/newdb
565     /var/eventlogs
218     /var/savi
204     /var/tmp
192     /var/avira4
46      /var/sasi
24      /var/conan_new
24      /var/conan

BTW I have no idea why "df -m /var" differs from "du =ms /var".

SFV4C6_VM01_SFOS 19.0.0 GA-Build317# df -m /var/ && du -ms /var/
Filesystem           1M-blocks      Used Available Use% Mounted on
/dev/var                  3776      3561       199  95% /var
2967    /var/

It could be resolved on v19 MR-1 but I can't see it in Resolved issues. Anyway I get "No records found" if I check for new firmware.

I've tried to find how to purge report logs but firewall help is not very instructive. What is the recommended procedure?



This thread was automatically locked due to age.
Parents
  • This could be:  NC-94291

    Fixed in MR1. 

    __________________________________________________________________________________________________________________

  • I think and believe that this problem (NC-94291) is fixed in build 350. But it is possible to correct this problem on a "live system"? When we updated another firewall, the /var filesystem REMAIN small. I have found some info about "increasing /var size" in https://support.sophos.com/support/s/article/KB-000036775?language=en_US. It is worth trying this after update? Or do we have reinstall XG firewall again and restore config from backup?

  • Hi Luca,

    I don't want to be offensive, but do you read your own posts?
    A large manufacturer only offers solutions at the expense of the customer????

    You can read all about it here!
    Just once more.

    - Sophos distributes a faulty installer.
    - Solution is the new MR1 version, which is not available! (checked just one Minute ago!)
    (That means faulty new installs every day!).
    - Solution 2 "just install the old 18.5.x ! (which is officially no longer available!)

    Hi Luca, who bears the costs if this measure has to happen at a customer 500 km away????
    I know it like this: Whoever makes the mistake has to pay.

    I am currently leaning towards solution 2, but with a firmware from another manufacturer.....


    Unfortunately, this is not the first time I have experienced something like this at SOPHOS!

    When will you finally wake up?

    Greetings Gerd

  • ... and Luca,

    stop minimising the problem, even though you're getting paid for it.

    Sometimes it's better to admit your mistakes!

    Greetings Gerd

  • It´s a BUG from Sophos but they ignore it until today!

    BR Gerd

  • I will not respond to this thread anymore, as i cannot help you any further. 

    All information are available. The bug is fixed. You need to reinstall with the new V19.0 MR1 installer or an old installer. 

    __________________________________________________________________________________________________________________

  • Hi Lucar,

    I can understand your despair. But there is still no acceptable solution from your employer SOPHOS!

    Your last solution approach in unacceptable, as now really described several times!

    Sorry dear community members, but actually this time I wanted to give Sophos a chance to really admit mistakes and generate a sound solution.
    BR Gerd

  • All information are available. The bug is fixed. You need to reinstall with the new V19.0 MR1 installer or an old installer. 

    this one is not available!

    As I write now for several post!
    What is this solution approach??

  • We are working on publishing the MR1 installers as we speak, I'll update this when they're available. 

  • Hello guys,

    as long as we don't get a solution from Sophos, the only steps you can take are as follows:

    1. reduce the report holding time to the lowest possible value
    2. flush report data on the shell.

    I unfortunately have to do this every 2nd day now because our customer appliance is more than 500 km away.

    @Sophos great bug, keeps us at work

    SOLVE IT!

  • Gerd, 

    I do apologize for the trouble & extra work this issue has caused you & your customer. It was our fault this bug was introduced in v19.0 GA, and we are doing a full RCA to figure out how it happened and what we can improve internally to prevent this type of issue from happening again. 

    Generally we only publish the installer of a version to MySophos when we fully GA, but I am working with the team now to publish the MR1 installer ASAP to provide you (& others affected) a viable solution. 

  • Bobby,

    thanks for your answer, which sounds a bit more reliable to me.

    Please remember the many installations that were made with 19.0.x.

    A new installation costs you reputation and us money.
    There must be another solution.

    BR Gerd

Reply Children