I’m basically running in cycles of:
apt-get update (get the latest available in repositories)
apt-get upgrade -f (try to install it, attempt to install any dependencies, stuff blows up)
dpkg –configure -a (try to finish installation of as much stuff that blew up as possible)
apt-get autoremove (remove as much of the old stuff that is in the way as possible)
… rinse and repeat.
Each cycle more stuff gets installed and the number of broken dependencies decreases, but it is a slow painful process.
Debian has been upgraded to Jessie, however, there are quite a few broken packages at present. The upgrade did not go cleanly and I had to restart things numerous times.
There were quite a lot of unresolved dependency issues. I am still working on these. Not sure why Debian went so uncleanly relative to Ubuntu when they are both very similar.
I will be out of the office for approximately two hours. I neglected to change a couple of servers to use the new file server and as a result I can’t login. These servers can function without the file server as they provide radius authentication but I can not login to them to make changes which is necessary. I should be back around 1-2pm Pacific Time.
An operating system upgrade of debian.eskimo.com from wheezy (7) to jessie (8) is in progress. I started it last night but as typical for debian major release updates, the script blew up and I have had to restart things several times. As a result, the system is presently in an inconsistent state and it would be better to use mint.eskimo.com or ubuntu.eskimo.com if you need a debian based shell server while this upgrade is still in process.
Our Co-Location Provider, IsoFusion sent us this:
We are preforming network maintenance on October 8th, Thursday, at 12:00AM PDT and the maintenance window will be till 2:00AM PDT. This may cause outages for 10 to 20 minutes during this time window.
The command quota -v does not work because rpc.rquotad under Ubuntu 15.04 segfaults right away. I do not yet know what is causing this but it seems to be fairly unique to us because I’ve Google’d and DuckDuckGo’d and found nada.
It might be that it isn’t working right with RAID devices, or I’ve got something wrong in the fstab or maybe it doesn’t like the i7-7400k CPU (new CPU only out about a month), who knows. Initially quota -v also core dumped on the server but upgrading the kernel from 3.19.0 to 4.2.3 resolved this so at least the command works on the server.
If you believe you are running up against your quota, du -s ~ will at least give you an approximation. If it doesn’t give you enough e-mail support or create a ticket and I’ll look it up manually and e-mail the results.
This is not to say that I’ve given up, but it is a difficult problem. If anyone knows where to obtain source for an older version of rpc.rquotad, please let me know.
Lost another customer to death, found out today, but he Richard Arnold had passed away in March this year. I always hate to lose customers but especially this way.
There will be a brief interruption of all services around 4pm today in order to reboot what is now serving as the main file server. (mail spool will be moved back to another machine after it is configured with RAID10 file systems and better cooling).
This is necessary in order to install a kernel that fixes some interrupt latency issues that is causing a higher load than should exist given that CPU and I/O utilization are very low.
Normally I would be doing this late at night but because the last two reboots have had complications that required a trip to the co-location facility, I want to be on-site when I do this and I need to make a trip to Fry’s to pick up a cabinet and cooler for the machine being reconfigured.
The client mail server, mail.eskimo.com, has been moved to new hardware and is back online and available for use.
Shellx is moved to the new hardware, up and available for use.