Then I edited Grub to give me a fullscreen- 1920 x 1080.  You just edit /etc/default/grub with an editor run under sudo. I use Gedit but nano will do. Just change the line to this:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash video=hyperv_fb:1920x1080"

followed by

sudo update-grub

and that should be it. Only it didn’t work in my new Ubuntu 24.04 LTS VM. I installed ifconfig from net-tools, connected to it from my Windows PC and copied grub across. I did the same with my older 24.04 LTS VM and compared the two grub files. Both identical yet one works fullscreen and the newer one doesn’t. Any ideas?

So you’re trying to debug C# code on Linux, maybe Ubuntu. You’ve installed .NET 6 or 7, you’ve built your solution in Visual Studio on your Windows PC, published it then copied the files over to the Linux box. But when you run it, you get an error “Unable to find debugger script at”. It’s time to debug your Linux app from your Windows Visual Studio.

Now there is a Microsoft support issue for this and it’s less than helpful. Read below to see how I fixed it.

Only, as soon as it tries to attach over SSH (with username, password, IP etc), you get this popup on the left. “Computer says no”.

Looking in the VS Output folder you see the text below or something similar. For whatever reason, it failed to create a hidden folder in your home folder. To fix this, all you have to do is create that folder. It’s .vs-debugger under your home folder.

If you’re not familiar with .folders on Linux, note that the . at the front of the name means it’s a hidden folder. A simple ls command will not reveal it. If you use the File Manager, you can click the settings in the top right and tick the Show Hidden Files. Then you can do a cd ~ followed by a mkdir .vs-debugger. And View in files to confirm that it’s there.

Now the only pain with debugging is that the application must be running for Visual Studio to attach to it. I was debugging a utility that is run, does its business and closes. So to debug it, I added this as the first line in main() in program.cs

Console.ReadKey();

So run it, let it sit waiting for a key then attach visual studio’s debugger to your app over SSH, add your breakpoints and hit a key. Simples!

One of the big problems with Hyper-V and Ubuntu in particular is the clipboard or lack of it. I had 18.04 LTS installed with an X Org RDP login. This worked perfectly and I could have a full screen in my Monitor and could copy/paste.  Don’t underestimate copy/paste.

It’s a real PITA if you have to use say WinSCP to copy files over. I think WinSCP is excellent BTW but the amount of labour saving that copy/paste has done since some genius thought it up is immeasurable. That and allowing the full screen of the monitor are two highly important things.

Sadly the 20.04 LTS didn’t seem to allow it. Copy/paste didn’t work between my Windows PC (host) and Ubuntu (guest). There’s nothing worse than losing a feature you’ve grown fond of.

If you follow these instructions for creating a Hyper-V 18.04, you get the screen size popup but not with 20.04 LTS. For that you have to follow these instructions!

It’s things like this that suggest why Linux Desktop has never been that successful. You can waste many hours getting simple things working and sometimes like Copy/Paste they break between versions. And this is with Ubuntu, probably the biggest and best known and supported Distro.

Most Linux development is done on Ubuntu running under Hyper-V on my Windows 10 PC. If you have lots of RAM (and I have a full 64 GB), it’s very convenient. I run Snagit on Windows and this makes it very easy to grab screenshots of the Ubuntu window.

I also have a “Raspberry-pi” running under Hyper-V.  There’s a Raspbian desktop that you can download and run in Hyper-V, VirtualBox or VMWare though I’ve only done Hyper-V. Don’t forget when you are running a Raspberry Pi this way that its x86 based not ARM. That does affect the available software, so it doesn’t behave exactly like a real Pi though often close enough.

Today though I started getting low disk space from my virtual Ubuntu. That’s the problem with virtual machines. When you first setup a Virtual hard disk, you never know just how much disk space you will need.

There’s a terminal command that shows how much space you have left.

df -h --total

This produced this

david@david-Virtual-Machine:~$ df -h --total
Filesystem      Size  Used Avail Use% Mounted on
udev            942M     0  942M   0% /dev
tmpfs           193M  1.4M  192M   1% /run
/dev/sda1        11G  9.9G  603M  95% /
tmpfs           964M     0  964M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           964M     0  964M   0% /sys/fs/cgroup
/dev/sda15      105M  3.6M  101M   4% /boot/efi
tmpfs           193M   16K  193M   1% /run/user/121
tmpfs           193M   24K  193M   1% /run/user/1000
total            14G  9.9G  4.1G  71% -

This was after I’d extended my virtual hard disk.  You can see I now have 4.1 GB free.

The pretty picture is from a utility filelight. You install it in the usual way

sudo apt install filelight

Or if you prefer a more visual insight, install qdirstat.

sudo apt install qdirstat

This is like WinDirStat on Windows but qdirstat seems to run many times faster. It took a couple of seconds to produce this image below. WinDirStat would take 10-30 minutes.

So how did I expand my Hyper-V hard drive?

First you have to get rid of any checkpoints. Save your Hyper-V session if open then delete the checkpoint.

Right click on the checkpoint for the selected VM and click delete. This will take a minute or two and you’ll see it have a Merging status. You may need to shutdown the VM.

After that you can go into the settings and it will let you edit the virtual hard drive and change the size.

The version of Code::Blocks on the 18.04LTS Ubuntu  was 16.01 and on Ubuntu 20.04 LTS it’s Code::Blocks 20.03. I keep my Ubuntus up to date but the 18.04 LTS hasn’t switched to the newer Code::Blocks which surprised me. I’m guessing that the maintainers of the 18.04 LTS Ubuntu repositories just haven’t updated their copy of Code::Blocks.

One thing I hadn’t explored in Code::Blocks is the debugging and this seems a lot more powerful than what you get in Visual Studio Code.   This screenshot below from version 20 shows it is more akin to Visual Studio debugging rather than Visual Studio Code debugging what with CPU registers, stack, memory dump and threads.