linux

A short trip through dependencies hell

With my recent embracing of Linux for my desktop PC, and my tendency to want to install various software that’s not necessarily ready for primetime, it was inevitable that I would run into the dreaded “dependencies hell” situation where something gets broken and ends up breaking other things. Well, I’m still typing this on my now-fixed Linux desktop, so this is definitely not one of these “screw Linux, I’m going back to Windows” post, and I’ll walk everyone through this incident in detail so that if by some chance you find yourself having a problem such as this, you will not panic and be able to repair things.

So yesterday I was going through some of my old archives and saw a big fonts package. We’re talking 1000+ fonts. I don’t want to install all of those, but I wanted to have a fonts manager app so I can have a visual preview of all of them and enable/disable some of them without wanting to move files around directly. One of the apps I saw listed as available for Linux was fontbase, and from the web site I thought it looked really interesting. It is distributed as an appImage, which I don’t like — we Linux users have to deal with multiple software packaging methods already — but it’s supposed to be a way software can be installed without requiring a separate app (like apt, flatpak, etc.) so I gave it a try.

Usually the way to install an appImage file is to make it executable and double-click it, so I do that… and nothing happens. I bring it up in Nautilus (“Files”), right-click and select run, and again, nothing. So I grumble and open a terminal from my Downloads folder and run it (with ./[file]), and get an error message:

dlopen(): error loading libfuse.so.2

AppImages require FUSE to run.
You might still be able to extract the contents of this AppImage
if you run it with the –appimage-extract option.

This error occurs because Ubuntu switched from FUSE2 to FUSE3. A long time ago. However I did not know that, and foolishly did not research this ahead of time. So I assumed that FUSE was not installed at all, and that’s how this all started.

Naturally I went to a terminal and entered “apt install fuse”. Apt warned me it would have to install a lot of packages and, more importantly, remove a lot of packages. However I was in the middle of playing a game and was not paying sufficient attention. If I had been paying attention I would have noticed that the packages to be removed included things like “ubuntu-desktop”, which is pretty important on a working Ubuntu desktop system!

Unfortunately I just hit enter to start the process. This did not have any impact on running applications so I kept doing what I was doing, playing the game (it was “Car Mechanic Simulator” on Steam, if you’re curious), and then I watched the Japanese Grand Prix, and went to bed.

When I woke up is when I realized how badly I had screwed this up. I woke my computer from sleep, but I couldn’t enter my password. So, I reluctantly did a hard reboot on the system — hold down the power key for 5+ seconds, then restart — and that’s when I became aware that I had made a huge mistake.

I made a huge mistake

So the computer restarts, I get the initial Ubuntu screen… and then it disappears and shows me the console output of the system startup. That’s not a good sign. Also the last message I saw was that gdm had failed. That’s really great, I thought sarcastically. And that’s when it hit me that installing the “fuse” package was the origin of the problem. I looked up whether the apt system has a rollback system, and it does not — maybe that’s why Ubuntu now uses snap. However it gave me a starting point. Fortunately I still had my phone working so I looked up fuse and realized that I had inadvertently rolled back FUSE3. So I switched to a terminal in text mode by pressing “Alt + F2”, logged in, and reinstalled FUSE3. However I also noticed that it didn’t involve installing a huge number of other packages but one thing at a time. I rebooted.

Of course I was still left in the system console after rebooting, with gdm loading but me not seeing a GUI. So again I switched to a terminal, and thought about what my next step was going to be, and fortunately I found that apt has a flag you can use to reinstall some parts of the system (–reinstall). So at that point I started looking for a “desktop” meta-package and immediately saw “ubuntu-desktop”, so I went for it with this command:

“sudo apt install –reinstall ubuntu-desktop”

and this operation took care of all the dependencies. I crossed my fingers, rebooted, and Hallelujah! I got my desktop back, and my first thought was “I gotta write this down”, that’s the technical writer in me I guess.

Fortunately Ubuntu has the ubuntu-desktop metapackage available. Had this happened with another distro I think recovery would not have been nearly as easy  And fortunately I remembered exactly what I had done at the system level which could have caused this problem. Because, make no mistake, I am the only person who caused that problem.

However it might be a good idea to “blacklist” the fuse package from getting installed by apt, as this really shouldn’t be done by anyone who’s running the Ubuntu desktop. I’m not exactly sure how this could be done, but it’d be a good idea.

That being said, and even better idea is to be careful AS ONE SHOULD BE when installing packages using sudo and apt, and to not just breeze through stuff because of a foolish sense of self-assurance that “I know what I’m doing”. And that’s ultimately the lesson from this — sudo as a tool is powerful, and the way it works on Linux is to add a step (authentication) that’s literally there to stop you from doing something stupid. In Breaking Bad the expression “respect the chemistry” keeps coming up. Well, if you’re using Linux, remember to “respect the permissions”. But, if you do get yourself into trouble, at least Linux is made in such a way that it’s possible to walk back your errors and get back to a working system, which is more than I can say for Windows.

Running a Windows virtual machine on Linux using an Existing Windows Installation

I’ve been a Linux user for years. At home I’ve kept a file server which runs off Linux, but that was “classic Linux” — without a graphical user interface, using the command line, and doing things the “hard way”. My main desktop PC was still running Windows, and had to because the one game I play regularly, Fortnite, was not available on Linux.

Well, someone recommended that I check out GeFORCE NOW, which is a virtualized environment you can use within Linux to play a large number of games in the cloud. I’ve always been skeptical about that type of play, largely because the capacity of the system to provide a good gaming experience had not previously been available. However since I live alone and have a good broadband connection I tried it out and loved it. It’s indistinguishable from playing the game from your own computer.

So, since most of the apps I use are open-source or otherwise available for Linux, I decided to switch from Windows to Ubuntu 24.04. My PC has two hard drives as well as a NVME drive which hosts the Windows system, so I decided to delete and transfer what I could from a 1TB drive and installed Ubuntu on there. It was a breeze and I was quickly up and running. Ubuntu has very good hardware support so most things just worked, and the only thing I had to hunt down was a driver for the Logitech G13 gamepad I constantly use. I’ve been running this for about 3 weeks now and I have no desire to go back.

However, today I came up against an obstacle. On Windows I used Bitvise SSH client to connect to this server, and Bitvise saves its files in its own binary format. I found myself in a situation where I would have to go back to Windows to use Bitvise to connect to my server. Also while my current situation does not require that I have access to a Windows machine, that can change all too easily. So I decided to create a Windows virtual machine (VM from now on), but instead of using a virtual hard drive file, I would simply use the disk on which Windows is already installed. That makes a lot more sense. It’s just more efficient.

I found one set of instructions to help me do that, but it dates back to 2021 and hasn’t been updated more recently, so I spend some time figuring out the more current way to go about it.

How to run a Windows VM from an existing Windows disk

For this you will naturally need a computer running Linux, preferably something Debian-based like Ubuntu. You will also need to install VirtualBox on that computer (downloads here). You should also disable Bitlocker encryption from your Windows drive before proceeding. I didn’t have it enabled on my drive so I don’t know how that would affect the installation.

Set up your user

Your user will need to be part of two groups: “disk” (to enable raw disk access) and “vboxusers”.

sudo usermod -aG disk,vboxusers [user]

Also let’s create a folder “vms” in your home directory in which you will keep your VMs:

mkdir vms

Set up your Windows disk

First, find out where your Windows drive is mounted. By default when you install Ubuntu on a computer with FAT32 or NTFS drives, they will be accessible to Linux.

lshw -short -class disk,volume

This will show you a list of your hard disks and their partitions. Look for a disk that contains a “Windows FAT volume”, a “reserved partition” and one or more “Windows NTFS volumes” and note the entry in the Device column for the disk (not partition). Usually this will be “/dev/nvme0” (if you have a NVME disk) or “/dev/sda”.

Next, we’re going to create a special file that points to that disk using a utility that is installed with VirtualBox. Enter this as your regular user (not root):

VBoxManage createmedium disk --filename=vms/[disk file].vmdk --variant=RawDisk --format=VMDK --property RawDrive=[Windows drive]

This file points at the location of the Windows drive.

Create a VM

Now we’ll start using VirtualBox itself. But before we do, let’s install the VirtualBox Extension Pack (download from here). To install the file just double-click on it on the file. It will launch VirtualBox and the installation will take place.

In the VirtualBox dashboard, click on the Create a new virtual machine (VM) link.

  1. In the VM Name field, enter a name for the virtual machine
  2. The VM Folder should be “/home/[user]/vms”
  3. In the OS field select Microsoft Windows
  4. In the OS Version field select the version of Windows installed on your Windows disk.Win12
  5. Click on the Next button at the bottom right of the New Virtual Machine window.
  6. Under Specify virtual hardware, adjust the Base Memory and Number of CPUs. Bring the Disk Size slider to the lowest value. Note that using 16GB (or more) of RAM is highly recommended otherwise you’ll find the VM experience very taxing, but keep in mind that this memory will not be available to your Linux apps while the VM is running.
  7. Select Use EFI
  8. Click on the Next button.
  9. Click on the Finish button.

Attach The Windows Disk to the VM

Now we’ll attach the pointer file we created in step 1 to the VM.

  1. In the Machines tab of VirtualBox Manager, right-click on the new VM and click on Settings.
  2. In the [VM]-Settings window, select the Storage tab.
  3. You’ll see a .vdi file which we won’t be using. Click on the Add Attachment button at the bottom right of the Devices box (see below) and select Hard disk from the dropdown menu. Attach Disk
  4. In the Hard Disk selector window, click the Add button.
  5. Select the .vmdk file you created earlier in the file selection dialog box.
  6. With the .vmdk file selected, click on the Choose button.
  7. In the [VM]-Settings window, select the .vdi file, and click on the Remove Attachment button (next to the Add Attachment button).
  8. Click OK to save your VM configuration.

Run Your VM

Nothing left to do but to run the VM and make sure it works, so in the Machines tab of VirtualBox Manager, right-click on the VM you just edited and select Start > Start with GUI.

You should be able to log into your Windows installation.

If you have tried in the past to install Linux and modified the UEFI partition of your boot disk… well, you will then have to navigate around the disk using the GRUB CLI to fix your boot sequence. This is beyond the scope of this particular tutorial, but instructions are easily found online. I had to do this myself.

Something else that came to mind as I was writing this was to try and see if I can do the same thing using QEMU instead of VirtualBox, which I will also write a tutorial for if I can manage to do it.

Keep in mind that virtualization at the local level can be a bit tricky and resource-intensive. It’s also one of the rare things that can completely freeze up your system and force you to reboot it — that’s called a kernel panic.