TOPIC: OPERATING SYSTEMS
Restoring GRUB for dual booting of Linux and Windows
11th April 2015
Once you end up with Windows overwriting your master boot record (MBR), you have lost the ability to use GRUB. Therefore, it would be handy to get it back if you want to start up Linux again. Though the loss of GRUB from the MBR was a deliberate act of mine, I knew that I'd have to restore GRUB to get Linux working again. So, I have been addressing the situation with a Live DVD for the likes of Ubuntu or Linux Mint. Once one of those had loaded its copy of the distribution, issuing the following command in a terminal session gets things back again:
sudo grub-install --root-directory=/media/0d104aff-ec8c-44c8-b811-92b993823444 /dev/sda
When there were error messages, I tried this one to see if I could get additional information:
sudo grub-install --root-directory=/media/0d104aff-ec8c-44c8-b811-92b993823444 /dev/sda --recheck
Also, it is possible to mount a partition on the boot drive and use that in the command to restore GRUB. Here is the required combination:
sudo mount /dev/sda1 /mnt
sudo grub-install --root-directory=/mnt /dev/sda
Either of these will get GRUB working without a hitch, and they are far more snappy than downloading Boot-Repair and using that; I was doing that for a while until a feature on triple booting appeared in an issue of Linux User & Developer that reminded me of the more readily available option. Once, there was a need to manually add an entry for Windows 7 to the GRUB menu too and, with that instated, I was able to dual-boot Ubuntu and Windows using GRUB to select which one was to start for me. Since then, I have been able to dual boot Linux Mint and Windows 8.1, with GRUB finding the latter all by itself. Since your experiences too may show this variation, it's worth bearing in mind.
Dropping back to a full screen terminal session from a desktop one in Linux
29th May 2014
There are times when you might need to access a full screen terminal from a Linux graphical desktop. For example, I have needed this when installing Nvidia's graphics drivers on Ubuntu or Linux Mint. Another instance occurred on Arch Linux when a Cinnamon desktop update prevented me from opening a terminal window. The full screen command let me install an alternative terminal emulator, with Tech Drive-in's list proving helpful. Similar issues might need fixing on FreeBSD installations. These latter examples happened within VirtualBox, which has special requirements for accessing full screen command line sessions, which I'll explain later.
When running Linux on a physical PC, press CTRL + ALT + F1 to enter a full screen terminal and CTRL + ALT + F7 to return to the graphical desktop. In a Linux VirtualBox guest with a Linux host, these shortcuts affect the host instead. For the guest OS, use [Host Key] + F1 to enter a full screen terminal and [Host Key] + F7 to return to the graphical desktop. The default Host Key is the right CTRL key, unless you've changed it.
X sessions in GNOME and Cinnamon desktop environments support this functionality, but I can't confirm it works with alternatives like Wayland. Hopefully, this feature extends to other setups, as terminal sessions are occasionally needed for system recovery. Such mishaps are thankfully rare and should be virtually non-existent for most users.
The bold gamble behind Linux Voice magazine
1st March 2014
During the latter part of last year, the magazine Linux Format suffered a staff clear-out, and I was left wondering why. It was as if a load of folk left at once and, even if I have seen that sort of thing happening at my current place of work, I was asking if something went wrong at Future Publishing. Instead, I had missed the fact that the former Linux Format staff were starting their own magazine. They crowdfunded it on Indiegogo. It took the appearance of Linux Voice on a shelf in the Macclesfield WHSmith's for me to become enlightened about this.
It seems risky for a whole team from one publisher's magazine to leave and create their own similar publication, especially given the current instability of magazine publishing in the digital age. The mention of a non-compete agreement reminded me of my own workplace. Their former employers' reaction would be interesting to know, as mine might consider legal action if I did something similar, assuming it were possible; I too would be bound by a six-month non-compete clause after leaving.
Regarding the magazine's content, it is appropriately good. While occasional misspellings might occur, articles on OwnCloud and Arch Linux installation, along with reviews of Mageia 4 and FreeBSD 10, would interest me. Many familiar names from Linux Format are also present, creating a sense of continuity. The new magazine's design is less extravagant than its established competitor, and their coexistence will be worth observing.
New ideas take time to develop, and I wish the new magazine success. Its goals are positive: half of its profits will support open-source software, and articles will be openly accessible via a Creative Commons licence. However, its immediate financial stability is crucial, making the next few months significant. The experienced team behind the magazine is a strong asset and could prevent it from becoming like Walking World Ireland and Cycling World, which appear irregularly in stores. The support of an enthusiastic community is also beneficial. I might eventually have to choose between Linux Voice and Linux Format, similar to my choice between Linux Magazine and Linux User & Developer. Despite being a niche operating system, Linux users have a good selection of magazines.
Installing Citrix Receiver 13.0 in Ubuntu GNOME 13.10 64-bit
28th November 2013
Installing the latest version of Citrix Receiver (13.0 at the time of writing) on 64-bit Ubuntu should be as simple as downloading the required DEB package and double-clicking on the file so that Ubuntu Software Centre can work its magic. Unfortunately, the 64-bit DEB file is faulty, so that means that the Ubuntu community how-to guide for Citrix still is needed. In fact, any user of Linux Mint or another distro that uses Ubuntu as its base would do well to have a look at that Ubuntu link.
For the sake of completeness, I still am going to let you in on the process that worked for me. Once the DEB file has been downloaded, the first task is to create a temporary folder where the DEB file's contents can be extracted:
mkdir ica_temp
With that in place, it then is time to do the extraction, and it needs two commands with the second of these need to extract the control file while the first extracts everything else.
sudo dpkg-deb -x icaclient- ica_temp
sudo dpkg-deb --control icaclient- ica_temp/DEBIAN
It is the control file that has been the cause of all the bother because it refers to unavailable dependencies that it really doesn't need anyway. To open the file for editing, issue the following command:
sudo gedit ica_temp/DEBIAN/control
Then change line 7 (it should begin with Depends:) to: Depends: libc6-i386 (>= 2.7-1), lib32z1, nspluginwrapper. While there are other software packages in there that Ubuntu no longer supports, they are not needed anyway. With the edit made, and the file saved, the next step is to build a new DEB package with the corrected control file:
dpkg -b ica_temp icaclient-modified.deb
Once you have the package, the next step is to install it using the following command:
sudo dpkg -i icaclient-modified.deb
If it fails, then you have missing dependencies and the following command should sort these before a re-run of the above command again:
sudo apt-get install libmotif4:i386 nspluginwrapper lib32z1 libc6-i386
With Citrix Receiver installed, there is one more thing that is needed before you can use it freely. This is to put Thawte security certificate files into /opt/Citrix/ICAClient/keystore/cacerts. What I had not realised until recently was that many of these already are in /usr/share/ca-certificates/mozilla and linking to them with the following command makes them available to Citrix Receiver:
sudo ln -s /usr/share/ca-certificates/mozilla/* /opt/Citrix/ICAClient/keystore/cacerts/
Another approach is to download the Thawte certificates and extract the archive to /tmp/. From there they can be copied to /opt/Citrix/ICAClient/keystore/cacerts and I copied the Thawte Personal Premium certificate as follows:
sudo cp /tmp/Thawte Root Certificates/Thawte Personal Premium CA/Thawte Personal Premium CA.cer /opt/Citrix/ICAClient/keystore/cacerts/
Until I found out about what was in the Mozilla folder, I simply picked out the certificate mentioned in the Citrix error message and copied it over like the above. Of course, all of this may seem like a lot of work to those who are non-tinkerers and I have added a repaired 64-bit DEB package that incorporates all of the above and should not need any further intervention aside from installing it using GDebi, Ubuntu's Software Centre, dpkg or anything else that does what's needed.
Turning off seccomp sandbox in vsftpd
21st September 2013
Within the last week, I set up a virtual web server using Arch Linux to satisfy my own curiosity, since the DIY nature of Arch means that you can build up exactly what you need without having any real constraints put upon you. Something that didn't surprise me about this was that it took me more work than the virtual server that I created using Ubuntu Server, yet I didn't expect Proftpd to be missing from the main repositories. Though the package can be found in the AUR, I didn't fancy the prospect of dragging more work on myself, so I went with vsftpd (Very Secure FTP Daemon) instead. In contrast to Proftpd, this is available in the standard repositories and there is a guide to its use in the Arch user documentation.
However, while vsftpd worked well just after installation, connections to the virtual FTP soon failed with FileZilla began issuing uninformative messages. In fact, it was the standard command line FTP client on my Ubuntu machine that was more revealing. It issued the following message that let me to the cause after my engaging the services of Google:
500 OOPS: priv_sock_get_cmd
With version 3.0 of vsftpd, a new feature was introduced, and it appears that this has caused problems for a few people. That feature is seccomp_sandbox and it can be turned off by adding the following line in /etc/vsftpd.conf:
seccomp_sandbox=NO
That solved my problem, and version 3.0.2 of vsftpd should address the issue with seccomp sandboxing anyway. In case, this solution isn't as robust as it should be because seccomp is not supported in the Linux kernel that you are using, turning off the new feature still needs to be an option, though.
Sorting a kernel upgrade error in Linux Mint 13
30th November 2012
Linux Mint 14 may be out now, but I'll be sticking with its predecessor for now. Being a user of GNOME Shell instead of Cinnamon or Mate, I'll wait for extensions to get updated for 3.6 before making a move away from 3.4 where the ones that I use happily work. Given that Linux Mint 13 is set to get support until 2017, it's not as if there is any rush either. Adding the back-ported packages repository to my list of software sources means that I will not miss out on the latest versions of MDM, Cinnamon and Mate anyway. With Ubuntu set to stick to GNOME 3.6 until after 13.04 is released, adding the GNOME 3 Team PPA will be needed if 3.8 arrives with interesting goodies; there are interesting noises that suggest the approach taken in Linux Mint 12 may be used to give more of a GNOME 2 desktop experience. Options abound and there are developments in the pipeline that I hope to explore too.
However, there is one issue that I have had to fix which stymies upgrades within the 3.2 kernel branch. A configuration file (/etc/grub.d/10_linux) points to /usr/share/grub/grub-mkconfig_lib instead of /usr/lib/grub/grub-mkconfig_lib so I have been amending it every time I needed to do a kernel update. However, it just reverts to the previous state, so I thought of another solution: creating a symbolic link in the incorrect location that points to the correct one so that updates complete without manual intervention every time. The command that does the needful is below:
sudo ln -s /usr/lib/grub/grub-mkconfig_lib /usr/share/grub/grub-mkconfig_lib
Of course, figuring out what causes the reversion would be good too, but the symbolic link fix works so well that there's little point in exploring it further. Of course, if anyone can add how you'd do that, I'd welcome this advice too. New knowledge is always good.
Removing VMware Player from Linux Mint Debian Edition
4th August 2012
A whole slew of updates has appeared for my Linux Mint Debian Edition PC. However, to instate them, I needed to remove VMware Player and this is the command to do so:
sudo vmware-installer -u vmware-player
It worked in my case, and my system updates are in progress as I write this. The same command should work for other Linux distros where VMware Player was installed using the *.bundle installer. VMware Player remains in place on my main PC though, so I am not ditching it just yet, even if I have to be careful when running it on Linux Mint 13 so as not to freeze the system on myself.
Uninstalling VirtualBox Guest Additions on a Linux Guest OS
8th April 2012
Within the last few days, I updated my Linux Mint Debian Edition virtual machine installation to Update 4. Between not following the instructions so closely and problems with the update server, a re-installation preceded the update itself. When all was done, no desktop environment appeared, and issuing the startx command revealed that it was one of the VirtualBox drivers that was the cause of the problem. With my being unable to see any files on the VirtualBox virtual CD, something else needed doing and the executing following command (replacing [VboxAddonsFolder] with VBoxGuestAdditions-4.1.12 in my case, but it is different for each VirtualBox version) resolved the situation:
/opt/[VboxAddonsFolder]/uninstall.sh
When it was complete, a scrambled desktop began to appear, so a reboot was to set things to rights. Then, I could set to looking at what Update 4 had brought to Linux Mint Debian Edition.
Getting Gnome Shell going for Fedora 16 running in VirtualBox
5th December 2011
There are a number of complaints out there about how hard it is to get GNOME Shell running for a Fedora 16 installation in a VirtualBox virtual machine. As with earlier versions of Fedora, preparation remains a matter of having make, gcc and kernel-devel (kernel headers, in other words). While I have got away with just those, adding dkms (dynamic kernel module support) to the list might be no bad idea either. To get all of those instated, it is a matter of running the following command as root or using sudo:
yum -y install make gcc kernel-devel dkms
The -y switch ensures that any Y/N prompts that usually appear are suppressed and that the installation is completed. Just leave it out if you are inclined to get second thoughts. Another item that has been needed with a previous release of Fedora is libgomp, but I haven't had to add this for Fedora 16 if I recall correctly.
Once those are in place, it is time to install the VirtualBox Guest Additions. Going to Devices > Install Guest Additions... mounts a virtual CD that can be used for the installation of the various drivers that are needed. To do the installation, first go to where the installer is located using the following command:
cd /media/VBOXADDITIONS_4.1.6_74713/
Note that this location will change according to the release and build numbers of VirtualBox, yet the process essentially will be the same aside from this. Once in there, issue the following command as root or using sudo:
./VBoxLinuxAdditions.run
Hopefully, this will complete without errors now with the precursor software that has been added beforehand. However, there is one more thing that needs doing, or you will get the GNOME 3 fallback desktop instead. It pertains to SELinux, an old adversary of mine that got in the way when I was setting up a web server on a machine running Fedora. It doesn't recognise the new VirtualBox drivers as it should, so the following command needs executing as root or using sudo:
restorecon -R -v /opt
Doing this restores the SELinux contexts for the /opt directories within which the VirtualBox software directories are found. The -R switch tells it to act recursively and -v makes it verbose. When it has done its work, hopefully successfully, it is time to reboot the virtual machine, and you should have a GNOME Shell desktop interface when you log in.
Sorting out MySQL on Arch Linux
5th November 2011
Seeing Arch Linux running so solidly in a VirtualBox virtual box has me contemplating whether I should have it installed on a real PC. Saying that, recent announcements regarding the implementation of GNOME 3 in Linux Mint have caught my interest, even if the idea of using a rolling distribution as my main home operating system still has a lot of appeal for me. Having an upheaval come my way every six months when a new version of Linux Mint is released is the main cause of that.
While remaining undecided, I continue to evaluate the idea of Arch Linux acting as my main OS for day-to-day home computing. Towards that end, I have set up a working web server instance on there using the usual combination of Apache, Perl, PHP and MySQL. Of these, it was MySQL that went the least smoothly of all because the daemon wouldn't start for me.
It was then that I started to turn to Google for inspiration, and a range of actions resulted that combined to give the result that I wanted. One problem was a lack of disk space caused by months of software upgrades. Since tools like it in other Linux distros allow you to clear some disk space of obsolete installation files, I decided to see if it was possible to do the same with pacman, the Arch Linux command line package manager. The following command, executed as root, cleared about 2 GB of cruft for me:
pacman -Sc
The S in the switch tells pacman to perform package database synchronization, while the c instructs it to clear its cache of obsolete packages. In fact, using the following command as root every time an update is performed both updates software and removes redundant or outmoded packages:
pacman -Syuc
So I don't forget the needful housekeeping, this will be what I use from this point forward, with y being the switch for a refresh and u triggering a system upgrade. It's nice to have everything happen together without too much effort.
To do the required debugging that led me to the above along with other things, I issued the following command:
mysqld_safe --datadir=/var/lib/mysql/ &
This starts up the MySQL daemon in safe mode if all is working properly, and it wasn't in my case. Nevertheless, it creates a useful log file called myhost.err in /var/lib/mysql/. This gave me the messages that allowed the debugging of what was happening. It led me to installing net-tools and inettools using pacman; it was the latter of these that put hostname on my system and got the MySQL server startup a little further along. Other actions included unlocking the ibdata1 data file and removing the ib_logfile0 and ib_logfile1 files to gain something of a clean sheet. The kill command was used to shut down any lingering mysqld sessions too. To ensure that the ibdata1 file was unlocked, I executed the following commands:
mv ibdata1 ibdata1.bad
cp -a ibdata1.bad ibdata1
These renamed the original and then crafted a new duplicate of it, with the -a switch on the cp command forcing copying with greater integrity than normal. Along with the various file operations, I also created a link to my.cnf, the MySQL configuration file on Linux systems, in /etc using the following command executed by root:
ln -s /etc/mysql/ my.cnf /etc/my.cnf
While I am unsure if this made a real difference, uncommenting the lines in the same file that pertained to InnoDB tables. What directed me to these were complaints from mysqld_safe in the myhost.err log file. All I did was to uncomment the lines beginning with innodb and these were 116-118, 121-122 and 124-127 in my configuration file, but it may be different in yours.
After all the above, the MySQL daemon ran happily and, more importantly, started when I rebooted the virtual machine. Thinking about it now, I believe that it was a lack of disk space, the locking of a data file and the lack of InnoDB support that was stopping the MySQL service from running. Running commands like mysqld start weren't yielding useful messages, so a lot of digging was needed to get the result that I needed. In fact, that's one of the reasons why I am sharing my experiences here.
In the end, creating databases and loading them with data were all that was needed for me to start to see functioning websites on my (virtual) Arch Linux system. It turned out to be another step on the way to making it workable as a potential replacement for the Linux distributions that I use most often (Linux Mint, Fedora and Ubuntu).