Technology Tales

Creating a VirtualBox virtual disk image using the Linux command line

Much of the past weekend was spent getting a working Debian 10 installation up and running in a VirtualBox virtual machine. Because I chose the Cinnamon desktop environment, the process was not as smooth as I would have liked, so a minimal installation was performed before I started to embellish as I liked. Along the way, I got to wondering if I could create virtual hard drives using the command line, and I found that something like the following did what was needed:

VBoxManage createmedium disk --filename <full path including file name without extension> -size <size in MiB> --format VDI --variant Standard

Most of the options are self-explanatory, apart from the one named variant. This defines whether the VDI file expands to the maximum size specified using the size parameter or is reserved with the size defined in that parameter. Two VDI files were created in this way and I used these to replace their Debian 8 predecessors and even to save a bit of space too. If you want, you can find out more in the user documentation, but this post hopefully gets you started anyway.

Enlarging a VirtualBox VDI virtual disk

It is remarkable how the Windows folder manages to grow on your C drive, and one in a Windows 7 installation was the cause of my needing to expand the VirtualBox virtual machine VDI disk on which it was installed. After trying various ways to cut down the size, an enlargement could not be avoided. In all of this, it was handy that I had a recent backup for restoration after any damage.

The same thing meant that I could resort to enlarging the VDI file with more peace of mind than otherwise might have been the case. This needed use of the command line once the VM was shut down. The form of the command that I used was the following:

VBoxManage modifyhd <filepath/filename>.vdi --resize 102400

It appears that this also would work on a Windows host, but mine was Linux, and it did what I needed. The next step was to attach it to an Ubuntu VM and use GParted to expand the main partition to fill the newly available space. That does not mean that it takes up 100 GiB on my system just yet because these things can be left to grow over time and there is a way to shrink them too if you ever need to do just that. As ever, having a backup made before any such operation may have its uses if anything goes awry.

Lightening of desktop background images on Linux Mint Debian Edition running in Virtualbox

After a recent upgrade to Linux Mint Debian Edition 3 in a VirtualBox virtual machine that I had running its predecessor, I began to notice that background images were being loaded with more washed out or faded colours. This happened at startup, so selecting another background image worked as intended until the same thing happened to that after a system restart.

This problem is not new and has affected the Cinnamon desktop in the main Linux Mint variant (the one that is based on Ubuntu) and issuing the following command in a terminal session is a suggested solution:

gsettings set org.cinnamon.muffin background-transition fade-in

In my case, that solved the problem and the desktop background image display is as it should be since I executed the above. All it took was a change to a system setting.

Forcing an upgrade to Windows 10 Anniversary Update

There remain people who advise those on Windows 7 or 8.x to hold fire on upgrading to Windows 10. Now that the free upgrade no longer is available, that advice may hold more weight than it did. Even so, there are those among us who jumped ship who are open to having the latest versions of things at no monetary cost to see what is available, and I must admit to being one of those.

After all, I do have a virtual machine with a pre-release version of the next update to Windows 10 installed on there to see what might be coming our way and to get a sense of what changes that may bring so that I am ready for those. Otherwise, I am usually happy to wait, but I noticed that the Windows 10 Anniversary Update only came to my HP Pavilion dm4 laptop and not other machines with Windows 10 installed, so I started to wonder why there was a lag when it came to automatic upgrades.

So that these things do not arrive when it is least convenient, I took advantage of a manual method to choose my timing. This did not involve installation from a disk image, but was in-situ. The first part of the process is standard enough in that the Settings app was started and the Update & security item chosen. That dropped me onto the Windows Update, and I first clicked on the Check for updates button to see what would happen. When nothing came of that, the Learn more link was clicked to bring me onto part of the Microsoft support website where I found that the Windows 10 Anniversary Update installer could be downloaded, so I duly did just that.

Running it produced a screen asking whether I wanted to proceed. Since I wanted to go ahead, the appropriate button was clicked and the machine left alone until the process completed. Because the installer purely is a facilitator, the first stage is to download the rest of the files needed, and that will take a while on any connection. Once downloading was completed, the actual process of installation commenced with several restarts before a log-in screen was again on offer. On logging in to the machine, the last part of the process started.

Though the process took quite a while, it seemingly worked without a hitch. If there was anything that I needed to do, it was the re-installation of VirtualBox Guest Additions to restore access to shared folders, as well as dealing with a self-inflicted irritation. Otherwise, I have found that previously installed software worked as expected and no file has been missed. Waiting a while may have had its advantages too because initial issues with the Anniversary Update will have been addressed, though it is best not to leave it too long, or you could have the feeling of being forgotten. A happy balance needs striking.

Compressing a VirtualBox VDI file for a Linux guest

In a previous posting, I talked about compressing a virtual hard disk for a Windows guest system running in VirtualBox on a Linux system. Since then, I have needed to do the same for a Linux guest following some housekeeping. Because the Linux distribution used is Debian, the instructions are relevant to that and maybe its derivatives such as Ubuntu, Linux Mint and their like.

While there are other alternatives like dd, I am going to stick with a utility named zerofree to overwrite the newly freed up disk space with zeroes to aid compression later on in the process for this and the first step is to install it using the following command:

apt-get install zerofree

Once that has been completed, the next step is to unmount the relevant disk partition. Luckily for me, what I needed to compress was an area that I reserved for synchronisation with Dropbox. If it was the root area where the operating system files are kept, a live distro would be needed instead. In any event, the required command takes the following form, with the mount point being whatever it is on your system (/home, for instance):

sudo umount [mount point]

With the disk partition unmounted, zerofree can be run by issuing a command that looks like this:

zerofree -v /dev/sdxN

Above, the -v switch tells zerofree to display its progress and a continually updating percentage count tells you how it is going. The /dev/sdxN piece is generic with the x corresponding to the letter assigned to the disk on which the partition resides (a, b, c or whatever) and the N is the partition number (1, 2, 3 or whatever; before GPT, the maximum was 4). Putting all this together, we get an example like /dev/sdb2.

Once, that had completed, the next step is to shut down the VM and execute a command like the following on the host Linux system ([file location/file name] needs to be replaced with whatever applies on your system):

VBoxManage modifyhd [file location/file name].vdi --compact

With the zero filling in place, there was a lot of space released when I tried this. While it would be nice for dynamic virtual disks to reduce in size automatically, I accept that there may be data integrity risks with those, so the manual process will suffice for now. It has not been needed that often anyway.

Migrating to Windows 10

While I have had preview builds of Windows 10 in various virtual machines for the most of twelve months, actually upgrading physical and virtual devices that you use for more critical work is a very different matter. Also, Windows 10 is set to be a rolling release with enhancements coming on an occasional basis, so I would like to see what comes before it hits the actual machines that I need to use. That means that a VirtualBox instance of the preview build is being retained to see what happens to that over time.

While some might call it incautious, I have taken the plunge and completely moved from Windows 8.1 to Windows 10. The first machine that I upgraded was more expendable, and success with that encouraged me to move onto others before even including a Windows 7 machine to see how that went. The 30-day restoration period allows an added degree of comfort when doing all this. The list of machines that I upgraded were a VMware VM with 32-bit Windows 8.1 Pro (itself part of a 32-bit upgrade cascade involving Windows 7 Home and Windows 8 Pro), a VirtualBox VM with 64-bit Windows 8.1, a physical PC that dual booted Linux Mint 17.2 and 64-bit Windows 8.1 and an HP Pavilion dm4 laptop (Intel Core i3 with 8 GB RAM and a 1 TB SSHD) with Windows 7.

The main issue that I uncovered with the virtual machines is that the Windows 10 update tool that is downloaded onto Windows 7 and 8.x does not accept the graphics capability on there. This is a bug because the functionality works fine on the Windows Insider builds. The solution was to download the appropriate Windows 10 ISO image for use in the ensuing upgrade. There are 32-bit and 64-bit disk images with Windows 10 and Windows 10 Pro installation files on each. My own actions used both disk images.

During the virtual machine upgrades, most of the applications that considered important were carried over from Windows 8.1 to Windows without a bother. Anyone would expect Microsoft's own software like Word, Excel and others to make the transition, but others like Adobe's Photoshop and Lightroom made it too, as did Mozilla's Firefox, albeit requiring a trip to Settings to set it as the default option for opening web pages. Less well-known desktop applications like Zinio (digital magazines) or Mapyx Quo (maps for cycling, walking and the like) were the same. Classic Shell was an exception but the Windows 10 Start Menu suffices for now anyway. Also, there was a need to reinstate Bitdefender Antivirus Plus using its new Windows 10 compatible installation file. Still, the experience was a big change from the way things used to be in the days when you used to have to reinstall nearly all your software following a Windows upgrade.

The Windows 10 update tool worked well for the Windows 8.1 PC, so no installation disks were needed. Neither was the bootloader overwritten so the Windows option needed selecting from GRUB every time there was a system reboot as part of the installation process, a temporary nuisance that was tolerated since booting into Linux Mint was preserved. Again, no critical software was lost in the process apart from Kaspersky Internet Security, which needed the Windows 10 compatible version installed, much like Bitdefender, or Epson scanning software that I found was easy to reinstall anyway. Usefully, Anquet's Outdoor Map Navigator (again used for working with walking and cycling maps) continued to function properly after the changeover.

For the Windows 7 laptop, it was much the same story, albeit with the upgrade being delivered using Windows Update. Then, the main Windows account could be connected to my Outlook account to get everything tied up with the other machines for the first time. Before the obligatory change of background picture, the browns in the one that I was using were causing interface items to appear in red, not exactly my favourite colour for application menus and the like. Now they are in blue, and all the upheaval surrounding the operating system upgrade had no effect on the Dropbox or Kaspersky installations that I had in place before it all started. If there is any irritation, it is that unpinning of application tiles from the Start Menu or turning off live tiles is not always as instantaneous as I would have liked, and that is all done now anyway.

While writing the above, I could not help thinking that more observations on Windows 10 may follow, but these will do for now. Microsoft had to get this upgrade process right, and it does appear that they have, so credit is due to them for that. So far, I have Windows 10 to be stable and will be seeing how things develop from here, especially when those new features arrive occasionally as is the promise that has been made to us users. Hopefully, that will be as painless as it needs to be to ensure trust is retained.

Migrating a virtual machine from VirtualBox to VMware Player on Linux

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 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 only to subsequently discover 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 has 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 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:

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.

Initial impressions of Windows 10

Being ever curious on the technology front, the release of the first build of a Technical Preview of Windows 10 was enough to get me having a look at what was on offer. The furore regarding Windows 8.x added to the interest, so I went to the download page to get a 64-bit installation ISO image.

That got installed into a fresh VirtualBox virtual machine and the process worked smoothly to give something not so far removed from Windows 8.1. However, it took until release 4.3.18 of VirtualBox before the Guest additions had caught up with the Windows prototype, so I signed up for the Windows Insider program and got a 64-bit ISO image to install the Enterprise preview of Windows 10 into a VMware virtual machine since and that supported full screen display of the preview while VirtualBox caught up with it.

Of course, the most obvious development was the return of the Start Menu, and it works exactly as expected too. Initially, the apparent lack of an easy way to disable App panels had me going to Classic Shell for an acceptable Start Menu. It was only later that it dawned on me that unpinning these panels would deliver to me the undistracting result that I wanted.

Another feature that attracted my interest is the new virtual desktop functionality. Here I was expecting something like what I have used on Linux and UNIX. There, each workspace is a distinct desktop, with only the applications open in a given workspace showing on a panel in there. Windows does not work that way with all applications visible on the taskbar regardless of what workspace they occupy, which causes clutter. Another deficiency is not having a desktop indicator on the taskbar instead of the Task View button. On Windows 7 and 8.x, I have been a user of VirtuaWin and this still works largely in the way that I expect of it too, except for any application windows that have some persistence associated with them; the Task Manager is an example and I include some security software in the same category too.

Even so, here are some keyboard shortcuts for anyone who wants to take advantage of the Windows 10 virtual desktop feature:

• Create a new desktop: Windows key + Ctrl + D
• Switch to previous desktop: Windows key + Ctrl + Left arrow
• Switch to next desktop: Windows key + Ctrl + Right arrow

Otherwise, stability is excellent for a preview of a version of Windows that is early on its road to final release. An upgrade to a whole new build went smoothly when initiated following a prompt from the operating system itself. All installed applications were retained, and a new taskbar button for notifications made its appearance alongside the existing Action Centre icon. So far, I am unsure what this does and whether the Action Centre button will be replaced in the fullness of time, yet I am happy to await where things go with this.

All is polished up to now, and there is nothing to suggest that Windows 10 will not be to 8.x what 7 was to Vista. The Start Screen has been dispatched after what has proved to be a misadventure for Microsoft. Regardless of what was hyped a few years ago, the PC still is with us; touchscreen devices like tablets are augmenting it instead of replacing it for any tasks involving some sort of creation. If anything, we have seen the PC evolve with laptops perhaps becoming more like the Surface Pro, at least when it comes to hybrid devices. However, we are not as happy to smudge our PC screens quite like those on phones and tablets, so a return to a more keyboard and mouse centred approach for some devices is welcome.

What I have here are just a few observations; there are more elsewhere, including a useful article by Ed Bott on ZDNet. All in all, we are early in the process for Windows 10 and, though it looks favourable so far, I will continue to keep an eye on how it progresses. The need to be less experimental than Windows 8.x is being fulfilled: so far, it certainly is less schizophrenic and should not be a major jump for users of Windows 7.

Automatically enabling your network connection at startup on CentOS 7

CentOS 7's release sparked my curiosity, so I tried it in a VirtualBox virtual machine. It uses GNOME Shell in classic mode, making it feel similar to GNOME 2. One thing to note is that it requires at least VirtualBox version 4.3.14, or the Guest Additions kernel drivers won't compile. This might seem surprising when you learn it uses kernel version 3.10.x and GNOME Shell 3.8.4. Like Debian production releases, CentOS chooses established versions for stability, fitting its enterprise-focused user base. Despite this conservative approach, it still looks good, though trying to change the desktop background froze the machine. Otherwise, most things work well.

However, there are surprises, including one I noticed: network connectivity needed switching on every time the VM started. This occurs with the default installation and has been a known issue since at least CentOS 6. It's not difficult to fix once you know how.

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 's@^ONBOOT="no@ONBOOT="yes@' ifcfg-enp0s3

This uses sed for an inline (and case-insensitive) edit of the file to change 'no' to 'yes' after accessing the /etc/sysconfig/network-scripts/ directory. I edited manually with Gedit, which also works. Note that file editing needs superuser privileges, so switch to root with the su command or use sudo.

Dropping back to a full screen terminal session from a desktop one in Linux

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.