How to Create a Lean Debian Virtual Machine

Legal Notices

Copyright (c) 2018-2021 Dr. Thomas Redelberger, redethogmx.de. All rights reserved. You may quote and copy this publication provided you link back to this original web-site. Suggestions for amendments and improvements are welcome.

This information is provided as-is. I do not take any responsibility and do not grant any warranty nor do I imply any fitness for any purpose or kind, nor shall I be liable for any issues when using it.

The original version of this document was in English language. I might do a German version. People are invited to do translations to other languages. But they shall properly cite me and link back to this original web-site.

Introduction

I had created a TinyCore virtual machine for browsing the Internet. As from Windows 10 1803, the performance was degraded substantially, as CPU load was close to 100% most of the time. I decided to not investigate this, but rather build a new VM. I chose Debian, because I wanted to go standard and was curious how small a "minimal" VM would be, using the standard Debian distribution.

Hyper-V Set-Up

In Hyper-V I used the same settings I had used for my TinyCore VM. I went for a 5 GB VHD as per Debian sizing guidelines.

From the Hyper-V Integration Services, I switched on:

Shutdown of the operating system
Time Synchronisation

Debian Installation

I went for the Debian 9 (aka Stretch) 64-bit iso. I had tried Debian 9 32-bit, but it would not work, presumably for the same reason I could not get TinyCore v7 to work (issue with hard disk access).

In the Debian installer, I chose:

Expert Mode
Minimal Installation
One normal user in addition to user root

Expert Mode allowed me to set two important details right away:

a fixed IP address. This allows me to easily communicate with the VM using FTP (see /etc/network/interfaces)
use the ext2 file system rather than ext4. The benefits of ext4 are not relevant in a VHD. And ext4 does much more disk i/o than ext2, which negatively affects performance.

For the minimal install, I deselected everything:

[ ] Debian desktop environment
[ ] . GNOME
[ ] . Xfce
[ ] . KDE
[ ] . Cinnamon
[ ] . MATE
[ ] . LXDE
[ ] web server
[ ] print server
[ ] SSH server
[ ] Standard system utilities

As a simple file manager plus text editor I chose midnight commander (mc), because it can also be used in text mode:

$ apt install mc
$ apt clean

Finally, in terms of size

$ df -h

showed 906 MB.

As my PC is not running round the clock, I needed to add

$ apt install anacron

This makes sure that clean-up tasks like "rotating" log files are done properly. Otherwise the directory /var/log would grow to substantial size over time. anacron uses logrotate. Hence the details could be configured by changing etc/logrotate.conf.

For the X-Windows graphical system, the established standard is:

$ apt install xorg

I chose the minimal X-window manager flwm, the same as with TinyCore:

$ apt install flwm

flwm-topside, which is used in TinyCore, is not available in Debian. flwm-topside has the controls at the top of the window, whereas standard flwm has them on the left. Seems that flwm-topside requires compiling, which I am not (yet) ready to do.

To integrate the X-clipboard with mcedit - the text editor of mc - I installed xclip:

$ apt install xclip

$ apt install firefox

did not work. I had to do

$ apt install firefox-esr

This yielded version 52.5.2 which seemed quite behind the usual Firefox version. Maybe the "esr" is related to this.

For transferring files in and out of the VM, I use an FTP server running in the VM. There seem to be three choices in Debian:

proftpd which is a 5,644 KB package
pure-ftpd 1,157 KB
vsftpd 2,629 KB

I went for pure-ftpd, as it was smallest and seemed most easy to use:

$ apt install pure-ftpd

This enabled FTP access to my home directory right away, with no further configuration needed.

My Customisations

Screen Resolution

/etc/default/grub

there is

GRUB_CMDLINE_LINUX_DEFAULT="There is probably stuff here"

I changed it to read (1280x1024 is my choice on a 1920x1200 physical screen):

GRUB_CMDLINE_LINUX_DEFAULT="quiet elevator=noop splash video=hyperv_fb:1280x1024"

followed by

$ sudo update-grub

Customised Menu of the flwm Window-Manager

The standard way to launch programs from flwm is a right-click on the desktop. To customise that pop-up menu, I created the directory

~/.wmx

If ~/.wmx exists, it replaces the default menu, which is configured under

/var/lib/flwm/wmx

which is auto-generated. I used it as a reference.

~/.wmx shall contain another directory Applications, where I put four shell scripts called Firefox, MC, MCEdit and Terminal, containing:

#!/bin/sh
exec firefox

*#!/bin/sh
exec xterm -e mc

*#!/bin/sh
exec xterm -e mcedit

*#!/bin/sh
exec xterm

Customising my X-Session

I also created a file

~/.xsession

This file customises what happens, when I do a startx from the command line:

#!/bin/sh
xsetroot -solid \#0E5CA8
###xrdb .Xresources
# xset, xmodmap, other configuration programs
#
# flwm -x: menu will say Exit instead of Logout
flwm -x &
#
WindowManager=$!
#
# xterm, other automatically-launched programs
firefox &
/home/myusername/myClpbrdd.sh &
#
wait $WindowManager

xsetroot sets the desktop background to a colour I prefer.

flwm & starts the X-window manager. The -x will just bring me back to the terminal instead of logging me out, when I select the Exit pop-up menu item in flwm. Without -x the menu item will read Logout.

firefox & already fires up one browser window ready to be used.

myClpbrdd.sh is a small demon I wrote to accept Windows clipboard data in the VM, and populate the X-windows clipboard. There is a corresponding VBscript file on the Windows side.

Autologin as non-privileged user

I want the system to log me in as a non-privileged user automatically. I found the following solution on the Internet:

$ mkdir /etc/systemd/system/getty@tty1.service.d
$ mcedit /etc/systemd/system/getty@tty1.service.d/override.conf

The file override.conf contains:

[Service]
ExecStart=
ExecStart=-/sbin/agetty --autologin myusername --noclear %I $TERM

I am not clear, what the first ExecStart= line does.

Starting X-Windows automatically

I further add the following line to ~/.profile

[[ -z $DISPLAY && $XDG_VTNR -eq 1 ]] && exec startx

I could create further virtual text consoles (i.e. non-X-windows) with CTRL-ALT-F2, etc., for example to do shutdown or reboot, which only root can do. CTRL-ALT-F1 brings me back to my unprivileged desktop.

However, normally I do not need to shutdown the Debian system, as I have Hyper-V start and shutdown the VM automatically, when Windows starts and stops. However, I noticed that recent Windows versions do not seem to normally shutdown and start VMs, but rather put VMs to sleep and wake them up again, like Windows itself.

The Debian VM seems fine with this. For example, the system clock is always OK. I could not manage to get the clock synchronised in TinyCore.

Using the X-clipboard in mcedit

To be able to exchange text content between mcedit (the text editor component of mc) and the X-windows clipboard, I needed to edit the file

~/.config/mc/ini

For that I have to use the nano editor, which seems to be installed by default. I could not use mcedit itself for that task, because the file would be overwritten on exit and my changes lost.

$ nano ~/.config/mc/ini

I looked for lines

clipboard_store=
clipboard_paste=

and replaced them by

clipboard_store=xclip -i -selection clipboard
clipboard_paste=xclip -o -selection clipboard

For example, you could copy text in Firefox using CTRL-C. In mcedit you would paste it using SHFT-Insert.

In mcedit, CTRL-Insert does copy, SHFT-Del does cut.

In doubt do F9 "menu" to see the short-cuts.

X-Clipboard Integration with Windows

I created a VBscript Clpbrd-ftp-Deb.vbs to upload the Windows clipboard text content to a directory called Downloads under the home directory of my non-privileged account in the Debian VM.

In the VM the script myClpbrdd.sh

gets started from ~/.xsession
writes to the X-Clipboard using xclip

When I want to bring text from Windows into the VM, the steps are:

CTRL-C in Windows as usual
double-click the script Clpbrd-ftp-Deb.vbs in Windows
Go to the VM and do a CTRL-V, for example in the Firefox URL line

So it is only one more step as natively in Windows or X-Windows.

Comparison with my TinyCore VM

Effort to Set-Up

To compare the effort for setting up the TinyCore VM and the Debian VM, I use my subjective feeling how long it took and how much I needed to read, to get the tasks done:

Setting up the basic system I found easier in Debian. I had no issues with a non-US keyboard and xorg worked right away and there had been no issues with Hyper-V screen and mouse compatibility
Setting-up users, customising the desktop and make it appear automatically required much more work in Debian than with TinyCore
My basic integration with Windows, FTP and clipboard functionality required the same effort as with TinyCore
Maintaining the system and keeping it up-to-date, I find more convenient in Debian.

I also hope that Debian will keep being maintained and stable for the foreseeable future.

About Versatility

I had set-up the TinyCore VM solely as a secure environment to browse the web. The Debian VM as described above has exactly the same functionality.

However, the Debian VM is based on a standard set-up that can be extended to any use easily, using the well-established and documented apt tool. When you combine this with "cloning" VMs and with using Hyper-V Restore Points, you can easily generate flexible and powerful environments.

True, a TinyCore system can also be extended to any use with its built-in tools. But the delta will be much bigger and the effort higher, because you start from a "tiny" system.

Keeping the System Lean and Up-To-Date

All below needs to be done as root user.

I was curious to see how much space the Debian VM would require and I wanted to make sure I could control its size when maintaining it going forward. To see the effect, I first did

$ df -h

I removed unused packages by

$ apt autoremove

Reducing the apt Package Cache

First check how big:

$ du -sh /var/cache/apt

Then clean it up:

$ apt clean

Check Application Caches (e.g. Thunderbird, Firefox?)

$ du -sh ~/.cache

and then e.g.

$ rm -rf ~/.cache/mozilla/*

Only keep needed Language Locales

Check active /locale/ :

$ locale

See all installed /locales/ :

$ locales -a

This showed in my case:

C
C.UTF-8
en\_US.utf8
Posix

which looks lean to me. If needed, unused locales could be removed by using the localepurge package.

Check Size Finally

$ df -h

My VM uses about 2.0 GB. Hence there is some spare space left from the total 5 GB size of the VHD. That space is available for file up/download, as files first go to the Downloads directory and then get transferred to/from Windows using FTP.

Keeping the System Up-to-Date

Using

$ apt update
$ apt upgrade

keeps the system up-to-date. This has to be done as root.

A Debian Virtual Machine using xrdp

The VM described above could be run under any decent VM environment and operating system, not just Hyper-V on Windows. If you are going to access the VM from Windows, then there is another option to access the VM: Microsoft's RDP (remote desktop) protocol. This has the following advantages over the approach above:

Clipboard cut and paste between VM and Windows works out of the box
Screen resolution can be chosen at login time
Capability for sound

The approach to build such a VM is largely the same as above, with the following differences:

You do apt install xrdp instead of apt install xorg. When installed, xrdp gets started from systemd automatically, similar to xorg in the approach described above.
You need to edit the file /etc/X11/Xwrapper.config and change the line allowed_users=console to allowed_users=anybody
Otherwise the login will fail
No need to have you logged in as a user from systemd already and no need to issue startx from ./profile, because xrdp requires a separate login anyway.

Conceptually the xorg approach above generates one window that you access from Windows via Hyper-V's "Connect to VM" tool, either from the Hyper-V manager or using vmconnect.exe, which you can call from a shortcut or the command line. This window shows either a VM text console or an xorg/window manager desktop. You can switch between various consoles and the desktop via CTRL-ALT-F1, CTRL-ALT-F2, … as usual in Linux.

The xrdp approach will rather yield two windows:

The console window mentioned above, where you could log in to a Linux shell prompt (usually bash). I only use it to log in as root to maintain the VM. You control the screen size/resolution from GRUB_CMDLINE_LINUX_DEFAULT like mentioned above.
A separate window to present the xrdp login screen. You get access to this window from Windows using mstsc.exe. ("tsc" stands for "terminal services", the older name for RDP). You control the screen size/resolution with the .rdp file

mstsc.exe is by default launched from files with extension .rdp. An .rdp file allows to configure an RDP connection.

Under %USERPROFILE%\Documents, there is the hidden file Default.rdp. You might want to copy it, give it a meaningful name like myDebian.rdp and edit it on the command line like

mstsc /edit %USERPROFILE%\Documents\myDebian.rdp

Or you right click on it and select "Edit" from the pop-up menu. The most import setting is the IP address of the VM. Do not forget to do "Save" or "Save As…" on the first tab.

The .rdp file also allows to configure to direct sound output from the VM, but sound on the VM requires some more Linux software to be installed and presumably settings in the VM which I still have to figure out.

To configure whether or not root is allowed to login via xrdp, you might want to check the file /etc/xrdp/sesman.ini, where the default was

[Security]
AllowRootLogin=True

I changed it to False.