Category Archives: *NIX

Stuff relating to the only real OS currently kicking around out there :)


Last night I did what I imagine a lot of people do, click the OK on the Ubuntu package updater, let it do it’s thing and then restart later. I was only doing a bit of late night work and off to bed. This morning… well fire up VMWare Player, start my Ubuntu VM, and it gets as far as where the Login prompt would appear, if I squint I can see the “Ubuntu” logo VERY faintly at the bottom and the dark purplish tint to the screen. The VM is fully unresponsive :/

I have however managed to recover from this. Initially I thought it could be related to the nVidia drivers on the host being updated (Windows 10 Host), tried disabling 3D etc found and followed this helpful guide (not the fix for me) Fix Ubuntu freezing with nVidia but that did at least get me into the system by adding nomodeset to the kernel boot in GRUB.

So at least now I am able to boot, but everything is a bit sluggish, and I cannot enable full screen on the VM. I then found this very helpful page, Rolling back recent updates specifically the 1st answer by “user unknown”.

What I did was to use the info in that page to find what has been updated, and then roll things back in the order that I guessed could be the most likely candidates and attempt to boot again afterwards.

 find /var/lib/dpkg/info/ -name \*.list -mtime -1 | sed 's#.list$##;s#.*/##'

Got me a list of packages that were updated in the last 24 hours. I copied this list to a text editor on the host machine and removed the unlikely candidates (pretty confident LibreOffice is not involved in the graphics drivers or login process in any way 😉 )

With my list of suspects I gathered the install versions with policy

apt-cache policy libgles2:

Which gives an output along the lines of

Installed: 1.0.0-2ubuntu2
Candidate: 1.0.0-2ubuntu2.3
Version table:
*** 1.0.0-2ubuntu2.3 500
500 bionic-updates/main amd64 Packages
1.0.0-2ubuntu2 500
500 bionic/main amd64 Packages
100 /var/lib/dpkg/status

From this I can see that the installed version of libgles2 is 1.0.0-2ubuntu2.3 and there is an older version of 1.0.0-2ubuntu2 available (be wary, there may be security packages between major releases, this may have longer versions with the word git in the version, probably wise to try and go for these.

Now, I attempted to roll this one package back but as it has dependencies with other packages this could upset a great many things. Pay EXTRA special attention to the output from apt-get install You don’t want to be removing your whole desktop system!!! To perform a downgrade

apt-get install libgles=1.0.0-2ubuntu2

This will spit out a whole bunch of dependency errors and things that will be removed. So each needs to be inspected in turn, at one point apt was kindly offering to downgrade some packages and remove most of my system! just say no kids! find the extra missing dependency and you should just see apt DOWNGRADE the packages you have listed.

In my case it took me 4 attempts, it may only have required me downgrading the final set of packages (in my instance mutter) but I haven’t tested combinations so I suggest people check with their own systems and carefully read the outputs. I did also revert the kernel to a previous version too (didn’t work) so this may be part of the issue. By all means attempt the downgrade of mutter first, hopefully that is all it was. Anyway, the full list of downgrades I did in order were as follows:

apt-get install libgles2=1.0.0-2ubuntu2 libegl1=1.0.0-2ubuntu2 libglx0=1.0.0-2ubuntu2 libglvnd0=1.0.0-2ubuntu2 libgl1=1.0.0-2ubuntu2
#Attempt 2:
apt-get install linux-image-generic=
#Attempt 3:
apt-get install mutter=3.28.1-1ubuntu1 gnome-shell=3.28.3+git20190124-0ubuntu18.04.2 gnome-shell-common=3.28.3+git20190124-0ubuntu18.04.2
#Attempt 4:
apt-get install mutter-common=3.28.1-1ubuntu1 gir1.2-mutter-2=3.28.1-1ubuntu1 libmutter-2-0=3.28.1-1ubuntu1

Obviously, check your own install and versions.. this worked for me, and hopefully the details of how I did it will help others (or myself if it happens again 😉 ) I am not responsible if following these steps you trash your system, this is what *I* did to fix *MY* install 🙂

Courier IMAP problems with STARTTLS (Checking mail server capabilities)

I have recently upgraded my mail server from Debian Wheezy to Debian Jessie, which along with it brings new versions of software, including Courier. For the most part this hasn’t been an issue except when it came to the IMAP service. On Thunderbird clients you would see “Checking mail server capabilities” and nothing more when connecting to the server, other clients I assume would have differing error messages, or just flat fail to connect. A quick fix was to switch the clients to SSL, BUT this I don’t think is a good fix as it requires your users to have to make a change. I have thankfully after much googling discovered what seems to be a fix (works for me ™ ).

Courier now uses dhparams.pem (Generate Diffie-Hellman Parameters – OpenSSL Wiki article). Now my fresh new courier install already had one of these present, but I suspect this may be too small. Regenerating this with a nice big 2048bit version rectified my STARTTLS issues instantly (well I did restart courier-imap and courier-imap-ssl too 🙂 )

The command I used is :

openssl dhparam -out dhparams.pem 2048

(This WILL take a fair amount of time, don’t worry it does finish 🙂 )
whilst within the /etc/courier path, followed by a restart of the imap services. My original dhparams.pem file was 201 bytes, after generating a new one it is 424 bytes 🙂

Hopefully this will help save someone’s hair 🙂

GRUB physical volume pv0 not found – one fix

I have had one of those days today…

One of the mount points on my server had gotten a little tight for space, so I decided to grow it before it became a problem. Naturally I use LVM so that’s not an issue.. well assuming you have free space on the LVM physical volume that is.. Thankfully this is a server running under virtualisation, so adding an additional physical volume was a simple task and the expansion went as you would expect, flawlessly.

Whilst I was at it, I thought I’d upgrade this box from Debian Squeeze to Wheezy too. Already running Wheezy elsewhere and an upgrade I have done plenty of times to trust (mostly 😉 ). That went well, but there were a few little grumbles around grub complaining about a missing PV that worried me. So I took a snapshot (including VMs memory) before running the magical restart. I am VERY glad I did!

Alas it seems there is a bug in GRUB 1.99 that from my Googling seems to have been around a while! It seems as though it isn’t too happy with an LVM configuration with multiple PVs. Reverting my non-booting box back to it’s running snapshot I was able to attempt ‘update-grub’ and be greeted with a long list of errors regards PV0 not being found.

Thankfully, I think I have found a work around! Although it’s not pretty and a bit time consuming. Essentially present a new PV to the box that is large enough to accommodate all existing PVs data (and probably a little extra growth room), then move your data to this new PV from all the original PVs with pvmove. This will take some time, running pvmove -v in another session/terminal you can at least see progress of the migration.

Once all the data is in your new PV, remove the old PVs from the active VG, then remove them from the system with pvremove. (They can still be connected and show as disks, just not PVs). With that done, run update-grub again, and fingers crossed you should have a bootable system once more.

I would certainly recommend you fire off a new snapshot including memory before rebooting, it’s an excellent safety net to get you back on the box.

Hopefully this will help someone else get out of this situation if they are unlucky to find themselves in it.

Curse you CPAN! (LIBXML2_2.6.0 not defined)

If you have seen the following error, possibly starting up Apache2 on your Linux box and you can’t for the life of you figure out why.. it MIGHT just be CPAN as the ultimate culprit. There is a good chance you may have a conflicting version of libxml2 in /usr/local/lib probably with a bunch of other libs too. As I didn’t install these myself, the only tool I can think of that will have done will be CPAN when a package has been installed via it.

Thankfully the fix is simple, remove the libs from /usr/local/lib that are conflicting, and don’t use CPAN 🙂

This may break your Perl module it installed, but hopefully will restore the usability of your system. My recommendation would be to only use packaged versions of your Perl modules to ensure system integrity, save you some headaches later in life.

Debian and VMware server “The path /usr/src/linux/include is a kernel header file directory, but it is not part of kernel source tree.”

Yeah a long name I know, but trying to get it stuck in Google so it will be most helpful.

I hit this snag and did a lot of trawling with little luck. Previously had no issues installing VMWare server, upgrade to Lenny, swap some hardware, decide to get it up and running and POOF! no dice!

Anyway I have solved it (huzzah!) and can finally goto bed 🙂

It seems that the error message is related to the lack of .config and or Makefile in the headers. So a .config or Makefile in /usr/src/linux/.

if you have installed your headers :

apt-get install linux-headers-$(uname -r)

have build-essential installed have set CC to be gcc-4.1 yet still you get grief, heres what I found.

If you look in the headers path, you will see .config and Makefile. Yet no joy!, look closer, the Makefile is a damn pesky SymLink!!! this goes for most if not all of the buggers. What you need along with the headers is:


which should reside in the same directory as your headers:


The SymLinks point into files in there, for some reason (possibly my own stupidity) I didn’t have it, possibly deleted it in a fit of disk space recovery before starting the build.

Hopefully that will be of use for someone out there, if not, I am sure I will find it useful when I next cause myself grief 🙂