Sorting a stalled Windows Update service

Following a recent family death, I have ended up with the laptop belonging to the deceased and, since it has been offline most of its life, I set to getting it updated. The McAfee security suite was straightforward enough but trying Windows Update produced errors suggesting that it was not working that a system restart was needed. Doing that did nothing so a little further investigation was needed.

The solution turned out to be stopping the Windows Update service and clearing a certain folder before starting it again. To stop the service, I typed in services.msc into the search box on the Start Menu and clicked on the Services entry that appeared. Then I sought out the Windows Update entry, selected it and clicked on the Stop link on the left hand side. After that, I used Windows Explorer to navigate C:\Windows\SoftwareDistribution and deleted everything in there. The, I went back to the Services window and started Windows Update again. That sorted the problem and the system began to be updated as needed.

All of this was on Windows 7, hence the mention of the Start Menu, and the machine is Toshiba Satellite C660 from 2011 with an AMD E-300 APU, 4 GB of RAM and a 320 GB hard drive. Those specs may not be the most impressive but it feels spritely enough and is far better than the lethargic Toshiba Equium A200-1VO that I acquired in 2008 though the HP Pavilion dm4 that I bought in November 2011 probably will travel more often than either of these, if truth be told. After all, it now has 8 GB of RAM and a 1 TB Samsung SSHD along with its Core i3 CPU so it should last a while yet.

Copying only updated new or updated files by command line in Linux or Windows

With a growing collection of photographic images, I often find myself making backups of files using copy commands and the data volumes are such that I don’t want to keep copying the same files over and over again so incremental file transfers are what I need. So commands like the following often get issued from a Linux command line:

cp -pruv [source] [destination]

Because this is in Linux, it the bash shell that I use so the switches may not apply to others like ssh, fish or ksh. For my case, p preserves file properties such as its time and date and the cp command does not do this always so it needs adding. The r switch is useful because the copy then in recursive so only a directory needs to specified as the source and the destination needs to be one level up from a folder with the same name there so as to avoid file duplication. It is the u switch that makes the file copy incremental and the v one issues messages to the shell that show how the copying is going. Seeing a file name issued by the latter does tell you how much more needs to be copied and that the files are going where they should.

What inspired this post though is my need to do the same in a Windows session and issuing xcopy commands will achieve the same end. Here are two that will do the needful:

xcopy [source] [destination] /d /s

xcopy [source] [destination] /d /e

In both cases, it is the d switch that ensures that the copy is incremental and you can add a date too, with a colon between it and the /d, if you see fit. The s switch copies only directories that contain files while the e one copies even empty directories. Using the d switch without either of those did not trigger any copying action when I tried so I reckon that you cannot do without either of them. By default, both of these commands issue output to the command line so you can keep an eye on what is happening and this especially is useful when ensuring that files are going to the right destination because the behaviour differs from that of the bash shell in Linux.

Suppressing Update Notifier messages in Ubuntu GNOME 14.04

Though I use only the command line to do system updates, I still got system restart messages every time a new kernel version was installed. While they can be helpful, I actually prefer to be left to my own devices when it comes to restarting a system and I may have a something running at the time that I do not wish to interrupt.

In Ubuntu GNOME 13.10 and before, there was no sign of these messages so I decided to see if I could go nag free again. The responsible application is called Update Notifier and I tried seeing if I could remove it but that act has a major impact of the system so it was not a useful way to go.

As it happens, it is an application that starts up automatically at computer boot time but there was no sign of an entry for it in the Startup Applications Preferences screen (started using from the command line using gnome-session-properties). The for this is that there is flag called NoDisplay in the relevant autostart shortcut in /etc/xdg/autostart/ that stops it appearing in the aforementioned settings screen when set to true. The trick then is to set it to false and the following command (broken over two lines for sake of display and quotes could need replacing when you issue the command too) does the trick for all such hidden start-up applications:

sudo sed -i ‘s/NoDisplay=true/NoDisplay=false/g’
/etc/xdg/autostart/*.desktop

What the above does is that sed goes into every file and changes NoDisplay=true to NoDisplay=false in each file with the desktop extension. When that has completed, there are more entries in Startup Applications Preferences and Update Notifier can be deselected in order to stop it starting. Removing the relevant .desktop file would be a more permanent change but this one will do me, especially since no more of those pesky restart messages appear anymore. My regularity when it came to system updates meant that the update messages never appeared anyway and I tend to shut down my system at the end of every day so the updates will be picked up too so all should be well.

ERROR: Can’t find the archive-keyring

When I recently did my usual system update for the stable version Ubuntu GNOME, there were some updates pertaining to apt and the process failed when I executed the following command:

sudo apt-get upgrade

Usefully, some messages were issued and here’s a flavour:

Setting up apt (0.9.9.1~ubuntu3.1) …
ERROR: Can’t find the archive-keyring
Is the ubuntu-keyring package installed?
dpkg: error processing apt (--configure):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
apt
E: Sub-process /usr/bin/dpkg returned an error code (1)

Some searching on the web revealed that the problem was that there were no files in /usr/share/keyring when there should have been and I had not removed them myself so I have no idea how they disappeared. Various remedies were tried and any that needed software installed were non-starters because apt was disabled by the lack of keyring files. The workaround that restored things for me was to take a copy of the files in /usr/share/keyring from an Ubuntu GNOME 14.04 installation in a VirtualBox VM and copy them in to the same location in its Ubuntu GNOME 13.10 host. For those without such resources, I have packaged them in a zip file below. Other remedies like Y PPA also were suggested where I was reading but that software package needed installing beforehand so it was little use to me when the likes of Synaptic were disabled. If there are other remedies that do not involve an operating system re-installation, I would like to know about them too as well as possible causes for the file loss in the first place and how to avoid these.

Ubuntu Keyrings

Sorting out a system update failure for FreeBSD

With my tendency to apply Linux updates using the command, I was happy to see that something similar was possible in FreeBSD too. The first step is to fire up a terminal session and drop into root using the su command. That needs the root superuser password in order to continue and the next step is to update the local repositories using the following command:

pkg update

After that, it is time download updated packages and install these by issuing this command:

pkg upgrade

Most of the time, that is sufficient but I discovered that there are times when the above fails and additional interventions are needed. What I had uncovered were dependency error messages and I set to looking around the web for remedies to this. One forum question that was similar to what I had met with the suggestion of consulting the file called UPDATING in /usr/ports/. An answer like that looks unhelpful but for the inclusion of advice where extra actions were needed. Also, there is a useful article on updating FreeBSD ports that gives more in the way of background knowledge so you understand the more about what needs doing.

Following both that and the UPDATING  file resulted in my taking the following sequence of steps. The first act was to download and initialise the Ports Collection, a set of build instructions.

portsnap fetch extract

The above is a one time only action so future updates are done as follows:

portsnap fetch update

With an up to date Ports Collection in place, it was time to install portman:

pkg install portman

A look through /usr/ports/UPDTAING revealed the commands I needed for updating Python and Perl to address the dependency problem that I was having:

portmaster -o devel/py-setuptools27 devel/py-setuptools
portmaster -r py\*setuptools

With those completed, I re-ran pkg update again and all was well. The extra actions needed to get that result will not get forgotten and I am sharing them on here so I know where they are. If anyone else has use for them, that would be even better.