We'd love to hear about it! Click here to go to the product suggestion community
My software based Home UTM 9 is stuck on version 9.352-6 and pattern 94753. The dashboard says I have "3 Update(s) available for download". But when I go to the Up2Date page it says: "Current firmware version: 9.352-6" - "Your firmware is up to date." and "Current pattern version: 94753" - "Your patterns are up to date."
I tried to download and install manually the "u2d-sys-9.353004-354004.tgz.gpg" file from ftp.astaro.com/.../ but... after installation and reboot its still says I have v9.352-6 and pattern 94753 and that I have "I have "3 Update(s) available for download".
So I am wondering if there is a trick to getting up2date (or manual installations) to work again. They have always worked fine in the past on this box and I have been using UTM 9 for several years without issue.
Any help or suggestions would be great!!
"3 Update(s) available for download" indicates that you have configured "Manual" for 'Firmware Download Interval'. On the 'Firmware' tab, click on 'Check for Up2Date packages now'. If you had selected an interval, try toggling it to "Manual" and then back. Depending on your download speed, you'll need to wait awhile to see what happens.
Cheers - Bob
PS Up2Dates must be applied in order. 9.353004-354004 cannot be applied to a UTM running 9.352.
In reply to BAlfson:
Thanks for your reply.
Both of the "Firmware Download Interval" and the "Pattern Download/Installation Interval" are both set to "Every 15 minutes" and I have never changed those settings to manual. I can try the switching those to "manual" and back to "every 15 minutes". That would be great if it was that easy!!
Also, under the "Available Firmware Up2Dates" on the "Up2Date' page it says "There are no Up2Date packages available for installation" ... which is obviously is NOT correct.
As for manually attempting to update the firmware...I was aware that they need to be applied in order. I just missed that the patch number was not same on the 9.352 download file as what I my UTM has as the current version. I saw the 9.352006 just jumped to the next file after it. I see now I need to to try to install "u2d-sys-9.352006-353004" before I can try installing "9.353004-354004".
Thanks! I will give those two things a try.
In reply to fortress4:
Last resort is to clear everything in /var/up2date/sys folder with rm * command and to initiate manual up2date with auisys.plx.
"There are no Up2Date packages available for installation" means they haven't been downloaded into your UTM. The other message means they are available to be downloaded. I would try vilic's suggestion first and then download all of the newer UP2Dates - it seems that you have some bad juju.
Before I saw both of your replies .... I tried to do a manual upload of "u2d-sys-9.352006-353004.tgz.gpg' (an earlier version from what I tried before). But during the file processing after a few minutes its throws an "Internal Server Error message".
As for the suggestion from "vilic"... could either of you give me more step by step details on how to do this? I have not done a very much non-UI style trouble shooting of my UTM9 box.
1. Enable UTM SSH access in Management -> System Settings -> Shell Access. Define login user and root passwords and put "Internal (Network)" object in Allowed Networks box.2. Connect to UTM LAN IP address using PUTTY tool. First login as loginuser, and then type su command and provide root password.3. Navigate to /var/up2date/sys folder and check it's content with ls command. Remove everything in it with rm * command.4. Run auisys.plx command to force up2date.
In reply to vilic:
vilic, Thanks so much for the step-by-step!! That really helped.
Well I have some more info now.... looks like I am having storage problem. When I ran auisys.plx --verbose I got some out of space errors.
How do I clear up the needed space for up2date?
Install u2d packages <avira3>Starting installing up2date packages for type 'avira3'Installing up2date package: /var/up2date/avira3/u2d-avira3-9.14302.tgz.gpgVerifying up2date package signatureUp2Date failed: Not enough free space for '/var/up2date/avira3-install'. Required space: 314187 KB Available space: 205020 KB; inodes: 304307Install u2d packages <savi>Starting installing up2date packages for type 'savi'Installing up2date package: /var/up2date/savi/u2d-savi-9.8633.tgz.gpgVerifying up2date package signatureUp2Date failed: Not enough free space for '/var/up2date/savi-install'. Required space: 268122 KB Available space: 205020 KB; inodes: 304307A serious error occured during installation! (40)
But the dashboard says I have plenty of space:
Log Disk: 9% of 53.3 GB
Data Disk 11% of 40.7 GB
When I did a DF from the ssh command window... looks like /dev/sda6 is almost completely full. Use% = 96%. All the other directories are are 1% or 0% with /dev/sda5 being the next highest at 12%.... so it must be that /sda6 is too full.
What can I delete from /sda6?
Thanks again for you help with this.
Update: i guess /sda6 is the root / directory
Update 2: In the hardware log I found that the root partition over the last year went from a fairly steady 50-60% usage to 90-93% usage between the 1st of the year and 1/10/2016... and now has stayed there. Which is most likely why my up2date will no longer work.I deleted most of the auto backups... which has helped get me a small amount extra space on root (checked with the df command as I deleted them).But is there anything more I can do to recover some of that 30% of space it used to have before the 1st of the year?Thanks again!
Sorry for all the back to back posts.... but I am kind of struggling here. I haven't been able to figure out what files to clean up/remove to regain the lost space.
So I was wondering since I have plenty of space on some of the other partitions does anyone know if I can use something like gParted (partition editor) to just reallocate enough space so up2date can start running again?
Try, from the command line: du -shx /var/storage/*
What does that give you?
Bob, when I ran that command I got back this:
/root # du -shx /var/storage/*16K /var/storage/agent88M /var/storage/chroot-clientlessvpn4.0M /var/storage/chroot-ftp148M /var/storage/chroot-http17M /var/storage/chroot-pop326M /var/storage/chroot-reverseproxy69M /var/storage/chroot-smtp271M /var/storage/cores16K /var/storage/lost+found32K /var/storage/pgsql1.8G /var/storage/pgsql922.1G /var/storage/swapfile
So it looks like the pgsql92 and the swapfile are hogging up most of the space.
First, it looks like you have this installed on a disk that is too small.
You probably can remove all of the core dumps in /var/storage/cores. Be careful in /var/storage/pgsql92/data/pg_xlog that you don't delete anything with a time stamp equal to or newer that on archive_status.
Thanks Bob for the info.
My UTM box has been running fine with the 120 GB drive for a couple years now. And the HD size wasn't an issue until the 1st of the year (Jan 2016) when some files started growing very fast and chewing up space.
Also your statement about the size of my HDD is kind of surprising since the "UTM 9.3 quick start guide" PDF states in the "Minimum Hardware Requirements" section that "20 GB hard disk drive (40 GB recommended)"... and my drive 3x the "recommended" size.
Maybe its time to rebuild using a bigger disk... so if 120 GB is too small what size HDD would be "REALLY" recommended??
But until I have a chance to do that...
Here is the output from the "/var/storage/cores/*"... so can I just do a "rm*" command in that "cores" directory?
/var/storage/cores # du -shx /var/storage/cores/*24M /var/storage/cores/admin-reporter..4233215M /var/storage/cores/cssd.1281712M /var/storage/cores/ips-reporter.pl.264401.8M /var/storage/cores/ipv6_watchdog.425620M /var/storage/cores/ulogd.4058
If so, looks like I will gain back a couple hundred MBs at least...
Thanks again for sticking with me on this!!!
I would first do ls -l /var/storage/cores to check that you don't have a recent core dump you might want to keep for Support.
You say, "And the HD size wasn't an issue until the 1st of the year (Jan 2016) when some files started growing very fast and chewing up space." Do you know where that was? Do you have any Reporting on when the partition started to grow? Can you show us the graph?
Again, you'll probably want to delete some of the pgsql92 files as I mentioned above, but do so carefully with my warning above in mind.