HOW-TO: Avast4Linux doesn't work with latest VPS ("cannot initialize, invalid")?

[zilog]

Starting with the 400.vps, version 100328-1, one of it's internal block reached the inner limit 33554432 bytes. It's a kernel variable which
is (quite artificially) limiting the maximum size of any SHM memory block - and 33554432 was a default for some kernels.

Solution? Set the limit to higher values (as root):

sysctl -w kernel.shmmax=128000000
OR
echo 128000000 >/proc/sys/kernel/shmmax

Place those lines to /etc/init.d/rcS or equivalent file (it's distribution-specific a bit - see /etc/inittab, the sysinit runlevel) to have them set automatically (just after boot).

regards,
pc

[spg SCOTT]

Hi zilog,

Not a linux user, but is this related to the post here:

http://forum.avast.com/index.php?topic=57772

-Scott-

[SAFENSECURE]

Hello,

I was able to get by the error message when trying to update my AVAST engine on Ubuntu 9.10.

Make sure you are in your home directory by typing pwd. Next, type ls -a; which should show all hidden files/directories.
Then navigate to the avast directory (cd .avast), you will see the following file name 400.VPS. Remove this file. There seems to be a size limitation or something. You may have to do this with root or sudo.

After removing the 400.vps file from the hard drive, I was then able to launch the Avast Application and run an update.

Thanks

[buffboy]

I did safensecure's trick as I was having the same problems as other posters. After, I could run the avast scanner. Unfortunately it seems the virus that destroyed my windows 2000 made it over to the gOS I put on this in my backup files. My worst fears have come to pass. When avast hit it again, avast crashed hard(I'm now running on the boot disk) just like it did with W2K. It has apparently taken my gOS startup files on the hard drive with it, again just like W2K. So much for the myth that viruses that infect windows won't hurt linux.  I'm going to try a few more things as I've got a bunch of hours in this install and I want to try isolate this bug so I can send it to you guys.

[zilog]

Hello,

I was able to get by the error message when trying to update my AVAST engine on Ubuntu 9.10.

Make sure you are in your home directory by typing pwd. Next, type ls -a; which should show all hidden files/directories.
Then navigate to the avast directory (cd .avast), you will see the following file name 400.VPS. Remove this file. There seems to be a size limitation or something. You may have to do this with root or sudo.

After removing the 400.vps file from the hard drive, I was then able to launch the Avast Application and run an update.

Thanks

As was written earlier, this won't help. So again, once more:

- in some kernels, there's a 32MB limitation for SHM block size by default (which can be altered in runtime, using sysctl)
- in latest VPS, this limit was reached by one part of the 400.vps. so at least in the future, you MUST alter the nonsensually-small default

(removing 400.vps causes the engine to use the spared older one, which will "work", but obviously doesn't solve the real cause)

regards,
pc

[Lazaro]

Zilog, your solution works perfectly. I'll translate it into spanish and publish it in some spanish linux forums.

To help linux newbies, as I am, go to the directory zilog says, then open a terminal, and use the command "sudo", for example in ubuntu would be "sudo gedit rcS" (once you are in the correct directory, probably in a main Terminal sudo gedit /etc/init.d/rcS will work too, but I've not proved). Put the line "echo 128000000 >/proc/sys/kernel/shmmax" before the "exec" one you have, and save it. Using the command sudo you will have to give your administrator password.

In kubunt it's "sudo kate rcS".

Sorry for my bad english.

[Mike Buxton]

Hi zilog,

I tried to apply your advice, but despite many different attempts I had no success.

As Lazaro managed to implement your advice the pictures below show my attempted replication:



I would be grateful for any further help.

My regards to all

PS Running Xubuntu desktop via Ubuntu 9.10

Addendum:

After many reboots (with no further changes except for multiple deletions of ¨stale lock¨ files - perhaps as a result of some incorrect adjustments I made) avast! has now worked normally. Thanks for your help.

[LoveTerri]

To zilog and Lazaro,

Thank you so much for your advice and explanations.

It worked perfectly on my Ubuntu 9.10 system.

Regards,
Terri (Linux Newbie!)

[zilog]

Hi zilog,

I tried to apply your advice, but despite many different attempts I had no success.

As Lazaro managed to implement your advice the pictures below show my attempted replication:



I would be grateful for any further help.

My regards to all

PS Running Xubuntu desktop via Ubuntu 9.10

Addendum:

After many reboots (with no further changes except for multiple deletions of ¨stale lock¨ files - perhaps as a result of some incorrect adjustments I made) avast! has now worked normally. Thanks for your help.

Probably wrong place, because your /proc filesystem isn't mounted yet (place it to the script which is executed when all FSs or at least procfs are mounted). But also, you can use /sbin/sysctl -w kernel.shmmax=128000000 - this version is procfs-independent.

regards,
pc

[Lisandro]

Appeared in my Kubuntu 10.04 Beta and the solution worked like a charm.
By the way, shouldn't the command be a part of the .deb package?

[zilog]

Appeared in my Kubuntu 10.04 Beta and the solution worked like a charm.
By the way, shouldn't the command be a part of the .deb package?

Hallo,
this variable is global, system specific. Other product, affected by this (databases especially), don't change this SHM limit by default. It's rather up on the distro developers, to raise this limit, or, better, on the kernel developers, to get rid of the years old default. The reason is that it's not very clean when an application customises silently system-global settings to fit its requirements in a persistent way.

But, as it seems, we'll have to add it in the unshot.

regards,
pc

[brianshel]

Zilog, your solution works perfectly. I'll translate it into spanish and publish it in some spanish linux forums.

To help linux newbies, as I am, go to the directory zilog says, then open a terminal, and use the command "sudo", for example in ubuntu would be "sudo gedit rcS" (once you are in the correct directory, probably in a main Terminal sudo gedit /etc/init.d/rcS will work too, but I've not proved). Put the line "echo 128000000 >/proc/sys/kernel/shmmax" before the "exec" one you have, and save it. Using the command sudo you will have to give your administrator password.

In kubunt it's "sudo kate rcS".

Sorry for my bad english.

Just for information, this also worked perfectly on Mint 8 Helena, as you would expect as it's based on Ubuntu 9.10.

Thanks for solving a frustrating problem!

[Lisandro]

But, as it seems, we'll have to add it in the unshot.

You can add a readme file and the information and/or disclaimer.

[Lisandro]

Upgrading the kernel, the problem comes back and the user needs to apply the limit again.

[YukonGuy]

Why do I have to something to make this product work with Ubuntu 9.10?  This is most annoying!  I didn't break the product but, in order to continue to use it, I now have the responsibility to fix it?  That's kind of screwed up don't you think?  I'm sure that there are those who would argue with me about this point.  Prior to consider doing so think about what this kind of problem does to and for newbie Linux users.

This solution is fine for those of us who are used to "playing around under the hood".  Fix the product not the user.

Regards,

YukonGuy