Tag Archive GNOME

Restoring the menu bar on GNOME Terminal in a GNOME Shell session

July 25th, 2020

By default, a GNOME Terminal instance does not display a menu bar and that applies not only in GNOME Shell but also on the Cinnamon Desktop environment. In the latter, it is easy enough to display the menu bar using the context menu produced by right clicking in the window before going to Edit > Preferences and ticking the box for Show menubar by default in new terminals in the General section. After closing the Preferences dialogue, every new GNOME Terminal session will show the menu bar.

Unfortunately, it is not so easy in GNOME Shell though the context menu route does allow you to unhide the menu bar on a temporary basis. That is because the requisite tickbox is missing from the Preferences dialogue box displayed after navigating to Edit > Preferences in the menus. To address, you need the execute the following command in a terminal session:

gsettings set org.gnome.Terminal.Legacy.Settings headerbar false

This not only adds the menu bar on a permanent basis but it also adds the missing tickbox, populated as required. GNOME Shell may be minimalist in some ways but making this action harder looks like going a little too far.

Removing obsolete libraries from Flatpak

February 1st, 2020

Along with various pieces of software, Flatpak also installs KDE and GNOME libraries needed to support them. However, it does not always remove obsolete versions of those libraries whenever software gets updated. One result is that messages regarding obsolete versions of GNOME may be issued and this has been known to cause confusion because there is the GNOME instance that is part of a Linux distro like Ubuntu and using Flatpak adds another one for its software packages to use. My use of Linux Mint may lesson the chances of misunderstanding.

Thankfully, executing a single command will remove any obsolete Flatpak libraries so the messages no longer appear and there then is no need to touch your actual Linux installation. This then is the command that sorted it for me:

flatpak uninstall --unused && sudo flatpak repair

The first part that removes any unused libraries is run as a normal user so there is no error in the above command. Administrative privileges are needed for the second section that does any repairs that are needed. It might be better if Flatpak did all this for you using the update command but that is not how the thing works. At least, there is a quick way to address this state of affairs and there might be some good reasons for having things work as they do.

Migrating a virtual machine from VirtualBox to VMware Player on Linux

February 1st, 2015

The progress of Windows 10 is something that I have been watching. Early signs have been promising and the most recent live event certainly contained its share of excitement. The subsequent build that was released was another step in the journey though the new Start Menu appears more of a work in progress than it did in previous builds. Keeping up with these advances sometimes steps ahead of VirtualBox support for them and I discovered that again in the last few days. VMware Player seems unaffected so I thought that I’d try a migration of the VirtualBox VM with Windows 10 onto there. In the past, I did something similar with a 32-bit instance of Windows 7 that subsequently got upgraded all the the way up to 8.1 but that may not have been as slick as the latest effort so I thought that I would share it here.

The first step was to export the virtual machine as an OVF appliance and I used File > Export Appliance… only to make a foolish choice regarding the version of OVF. The one that I picked was 2.0 and I subsequently discovered that 1.0 was the better option. The equivalent command line would look like the following (there are two dashes before the ovf10 option below):

VboxManage export [name of VM] -o [name of file].ova --ovf10

VMware have a tool for extracting virtual machines from OVF files that will generate a set of files that will work with Player and other similar products of theirs. It goes under the unsurprising name of OVF Tool and it usefully works from a command line session. When I first tried it with an OVF 2.0 files, I got the following error and it stopped doing anything as a result:

Line 2: Incorrect namespace http://schemas.dmtf.org/ovf/envelope/2 found.

The only solution was to create a version 1.0 file and use a command like the following (it’s a single line though it wraps over two here and there are two dashes before the lax switch):

ovftool --lax [name of file].ova [directory location of VM files]/[name of file].vmx

The --lax option is needed to ensure successful execution even with an OVF 1.0 file as the input. Once I had done this on my Ubuntu GNOME system, the virtual machine could be opened up on VMware Player and I could use the latest build of Windows 10 at full screen, something that was not possible with VirtualBox. This may be how I survey the various builds of the operating that appear before its final edition is launched later this year.

Automatically enabling your network connection at startup on CentOS 7

August 15th, 2014

The release of CentOS 7 stoked my curiosity so I gave it a go in a VirtualBox virtual machine. It uses GNOME Shell in classic mode so the feel is not too far removed from that of GNOME 2. One thing to watch though is that it needs at least version 4.3.14 of VirtualBox or the Guest Additions kernel drivers will not compile at all. That might sound surprising when you learn that the kernel version is 3.10.x and that for GNOME Shell is 3.8.4. Much like Debian production releases, more established versions are chosen for the sake of stability and that fits in with the enterprise nature of the intended user base. Even with that more conservative approach, the results still please the eye though attempting to change the desktop background picture managed to freeze the machine. Other than that, most things work fine.

Even so, there are unexpected things to be encountered and one that I spotted was that network connectivity needed to switched on every time the VM was started. The default installation gives rise to this state of affairs and it is a known situation with CentOS from at least version 6 of the distribution and is not so hard to fix once you know what to do.

What you need to do is look for the relevant configuration file in /etc/sysconfig/network-scripts/ and update that. Using the ifconfig command, I found that the name of the network interface. Usually, this is something like eth0 but it was enp0s3 in my case so I had to look for a file named ifcfg-enp0s3 and edit that. The text that is sought is ONBOOT=no and that needs to become ONBOOT=yes for network connections to start automatically. To do something similar from the command line, CentOS had suggested the following:

sed -i -e ‘[email protected]^ONBOOT=”[email protected]=”[email protected]’ ifcfg-enp0s3

The above uses sed to do an inline (and case insensitve) edit of the file to change the offending no to a yes, once you have dropped in the /etc/sysconfig/network-scripts/ directory. My edit was done manually with Gedit so that works too. One thing to add is that any file editing needs superuser privileges so switching to root with the su command and using sudo is in order here.

Suppressing Update Notifier messages in Ubuntu GNOME 14.04

July 18th, 2014

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.