[How To] VirtualBox in Bunsen Update Be>Bo (Debian 12). Debian repos.

Bearded_Blunder · 2022-04-18 17:21:40

We'll be doing this without 3rd party repos.

Yes, VirtualBox is still available from Debian, but it's a little more involved than a simple apt-get since it's not available in testing or stable directly owing to problems backporting security fixes to older versions the way Debian usually operate. Users of Buster (Lithium) older versions can adapt this, users of Sid can simply install using apt-get, no extra repos.

We must enable the fasttrack repo, which will also keep VirtualBox more current than it ever was from the main repos, though sometimes a little behind Oracle even so.

Setting up VitualBox on the host.

We'll need the fasttrack keyring:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install fasttrack-archive-keyring

Fasttrack requires backports also, so enable that [edit updated bullseye -> bookworm]:

echo "deb https://deb.debian.org/debian bookworm-backports main contrib non-free" | sudo tee /etc/apt/sources.list.d/debian-bookworm-backports.list

Fastrack is two lines:

echo "deb https://fasttrack.debian.net/debian-fasttrack/ bookworm-fasttrack main contrib non-free" | sudo tee /etc/apt/sources.list.d/debian-bookworm-fasttrack.list

Note the -a to append below.

echo "deb https://fasttrack.debian.net/debian-fasttrack/ bookworm-backports-staging main contrib non-free" | sudo tee -a /etc/apt/sources.list.d/debian-bookworm-fasttrack.list

Our sources have now changed, so:

sudo apt-get update

Added - a little prep to make sure modules can be built & installed:

sudo apt-get install dkms build-essential dkms linux-headers-$(uname -r)

You may get already installed type messages on these.

Install the main application, I'd recommend the extension pack too, which is non-free software but adds USB 2 & 3 capabilities to VMs & a number of other handy features.

sudo apt-get install virtualbox virtualbox-ext-pack

You'll need to accept the extension pack licence during the install process if you install it.

We'll want the guest additions iso especially for Windows in a VM, but also any Linux distro that doesn't keep additions in their repoos.
Make sure to get the one from fasttrack & not stable, or VirtualBox will complain about old additions when used.

sudo apt-get install virtualbox-guest-additions-iso -t bookworm-fasttrack

We've been added to the vboxusers group, & some features won't work till we've logged out & back in, so logout & back in, or reboot.

Now we're nearly set, in fact VirtualBox is installed & working, but the default settings on the user interface are messed up with a dark theme set, so let's fix that too.

cp /usr/share/applications/virtualbox.desktop ~/.local/share/applications/

Substitute a different editor below if you like.

nano ~/.local/share/applications/virtualbox.desktop

We want to change:

Exec=VirtualBox %U

To

Exec=VirtualBox --style Fusion %U

Now it'll at least be readable when started from the menu (It puts itself under Applications > System), from a terminal you can also do:

VirtualBox --style Fusion &

Optionally to have one dark style available

sudo apt-get install adwaita-qt

After which you can replace Fusion above with Adwaita-Dark for a dark mode.

All that's left is then creating a VM & installing a guest OS.

Installing Guest additions on a Bunsen/Debian guest.

To install Guest Additions in a VM running Beryllium or Bullseye you have a choice:
[Added]
Sometime while I wasn't looking between buster & bookworm we've also grown a new step:
The additions install their own time daemon referencing time on the host machine, which systemd-timesyncd used to check for & disable itself if it found (along disabling for any other time daemon). This is now handled by the virtual package time-daemon for the other equivalent packages, but apt can't tell if you install additions from the provided additions iso on the host install (guest additions cd). VMWare may do something similar.
You shouldn't have two, they conflict. So:

sudo systemctl disable systemd-timesyncd.service
sudo systemctl mask systemd-timesyncd.service

That ought to be enough but systemd has fooled me before by ignoring settings or reverting them, ignoring config files, etc. which is why I hate it passionately. I'm the system administrator, not that Microsoft inspired "Our way or the highway" garbage.
So to make damned sure:

sudo apt-get remove systemd-timesyncd

Don't purge, by not purging, the configuration that it's masked might stick if something tries yo pull it back onto the system.
[/Added]

Either also add the repos as above inside the guest and then also in the guest:
Now:

sudo-apt-get-install virtualbox-guest-utils virtualbox-guest-x11

For a CLI only system you don't need the second one.

previously wrote:

sudo apt-get install virtualbox-guest-x11 virtualbox-guest-dkms

Or:
Insert the additions iso from the VirtualBox Devices menu on the host & then inside the guest:
install some prequequiites.

sudo apt-get install build-essential dkms linux-headers-$(uname -r)

Install the additions themselves

cd /media/cdrom0
sudo sh ./VBoxLinuxAdditions.run

I usually reboot guests after additions installs, things can be a bit flaky if you don't.

That's pretty much it. Tweak things like clipboard sharing etc. to suit.

The discussion in Beryllium theming was getting a bit disjointed, so I thought I'd put the info I have all in one place.

Last edited by Bearded_Blunder (2024-06-21 02:31:21)

johnraff · 2022-04-19 05:37:43

Many thanks for this B_B!
It will be a good resource to have on the forum.

sleekmason · 2022-04-19 23:40:09

Indeed! Really good info! The Fast Track repo's are pretty cool to just have Virtualbox if nothing else. I've been using the oracle edition for a while now but look forward to giving this a go proper.

Bearded_Blunder · 2024-06-06 01:41:57

Some technical notes regarding systemd-timesyncd changes, for anyone interested.

On Buster it implemented a check:

systemctl cat systemd-timesyncd

Included a section that read thus:

# /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf
[Unit]
# don't run timesyncd if we have another NTP daemon installed
ConditionFileIsExecutable=!/usr/sbin/ntpd
ConditionFileIsExecutable=!/usr/sbin/openntpd
ConditionFileIsExecutable=!/usr/sbin/chronyd
ConditionFileIsExecutable=!/usr/sbin/VBoxService

In Bookworm that entire section is gone, & all but the last case handled by apt & the virtual package time-daemon with appropriate Provides Replaces & Conflicts etc. in the control files to ensure only one of the first 3 OR systemd-timesyncd itself get installed. Unfortunately apt can't track stuff which people install from external sources, though perhaps the package in fasttrack should also declare appropriate Provides, Replaces, & Conflicts. Not that it'd help much when most users who use VirtualBox install from Oracle, & use the provided iso to install additions completely bypassing the package manager...

Frankly this is a bigger mess now than it was before they split it out into its own package, at least a check was run then.

Packages that depend on having an NTP daemon installed, theoretically (by the rules) ought to depend on the virtual package time-daemon Looking @ you bunsen-meta-all/lite with the exception of things that need a specific one.. e.g graphical-front-end type stuff.

Frankly this is a bigger mess now than it was before they split systemd-timesyncd out into its own package.

Blasted systemd, always gots to be changing & breaking stuff.. It's reminding me lots of Windows 10 & 11 in that regard. Windows drives me to want Linux, systemd drives me to want to go back to Windows.

Grrrrrr.

johnraff · 2024-06-06 03:36:18

^Peace, peace... I think your anger is directed in the wrong direction. Splitting out systemd-timesyncd into a separate package was done precisely to give people freedom to use other timesync daemons of their choice.

Bearded_Blunder wrote:

Some technical notes regarding systemd-timesyncd changes:
On Buster it implemented a check:

systemctl cat systemd-timesyncd

Included a section that read thus:

# /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf
[Unit]
# don't run timesyncd if we have another NTP daemon installed
ConditionFileIsExecutable=!/usr/sbin/ntpd
ConditionFileIsExecutable=!/usr/sbin/openntpd
ConditionFileIsExecutable=!/usr/sbin/chronyd
ConditionFileIsExecutable=!/usr/sbin/VBoxService

That looks like a hack to me - choosing four specific NTP daemons to check against. (But how does VBoxService get involved?)

In Bookworm that entire section is gone, & all but the last case handled by apt & the virtual package time-daemon with appropriate Provides Replaces & Conflicts etc. in the control files to ensure only one of the first 3 OR systemd-timesyncd itself get installed.

Which looks like the right way to do it. Any new NTP daemon packages which join Debian can have the appropriate relationships declared in their debian/control files. I just checked systemd-timesyncd and chrony, and in d/c they both have:

Conflicts: time-daemon
Provides: time-daemon
Replaces: time-daemon

Presumably ntpsec and openntpd do the same.

Unfortunately, that approach doesn't please everyone, there is at least one user who'd like to be able to install ntp and chrony together:
https://bugs.debian.org/cgi-bin/bugrepo … bug=995213

Unfortunately apt can't track stuff which people install from external sources...

Unless they use apt to install their downloaded or compiled .deb file, which they should of course if they want to keep control over their system.

...though perhaps the package in fasttrack should also declare appropriate Provides, Replaces, & Conflicts. Not that it'd help much when most users who use VirtualBox install from Oracle, & use the provided iso to install additions completely bypassing the package manager...

In which case the responsibility to keep things organized rests with Oracle and the user.

Frankly this is a bigger mess now than it was before they split it out into its own package, at least a check was run then.

If an illegal immigrant is conflicting with a package installed the legit way, can't one of them just be removed?

Packages that depend on having an NTP daemon installed, theoretically (by the rules) ought to depend on the virtual package time-daemon Looking @ you bunsen-meta-all/lite

OK finally getting down to a serious suggestion. Are you proposing that the BL metapackages should depend on time-daemon instead of systemd-timesyncd? The latter was chosen for these desktop collections simply because it's the smallest choice, and is Good Enough for most users. Anyone who'd rather have eg chrony can just install it and the apt declarations will make sure systemd-timesyncd is removed. BL doesn't specifically need systemd-timesyncd but users definitely should have some time daemon installed. Even if they uninstall it though, nothing will happen because our metapackages are declared as such and removing one dependency hasn't caused the remaining ones to be marked for removal for some years now.

I suppose

Depends: systemd-timesyncd

could be replaced with

Depends: systemd-timesyncd | time-daemon

if you thought it would be an advantage.

Frankly this is a bigger mess now than it was before they split systemd-timesyncd out into its own package.
Blasted systemd, always gots to be changing & breaking stuff..

I don't think this has got anything to do with systemd to be honest.

Bearded_Blunder · 2024-06-06 10:11:48

Oh I'm peaceful enough, was very tired, hours down a rabbit hole, before I went to sleep. Though I also have an annoying cough, which isn't helping.

johnraff wrote:

That looks like a hack to me - choosing four specific NTP daemons to check against. (But how does VBoxService get involved?)

It is indeed a hack, but a very pragmatic one, it covers all the bases for anything in the main Debian repos (Including Sid, which is the only of the main branches which has guest additions for VirtualBox packaged as a deb). What it also covers is Windows/Intel Mac users spinning up a VM to give Debian a try, who grab the included additions image, mount it, & run the included script to build their additions, which are not shipped as debs, rpms, or packaged at all by Oracle, simply built on the target machine.

My guess being the majority don't even know fasttrack exists & assume that the CD image is the only way to install additions.

In either case, that experimenter with Linux has no clue that they now have two time daemons running, one referencing an NTP server, & one referencing the host machine (which in the case of any recent host OS also does periodic checks against ntp servers), the two fight if there's a discrepancy.
Nor any clue that they should remove systemd-timesyncd (which they got as part of standard system utilities all unknowing), & not replace it with openntpd, ntpsec, or chrony (all that's available in Debian) without removing said additions.

If an illegal immigrant is conflicting with a package installed the legit way, can't one of them just be removed?

One should ideally do exactly that, but your typical VirtualBox user on Windows, or an Intel Mac only finds out if their intermittently internet connected rarely used laptop suffers clock drift which leads to new issues which didn't previously happen, then there's many hours with Google wasted finding out why. I'll give you three guesses why I'm frustrated.

There's only so much "fun" extra learning I wanted right now. I'd never given time daemons a second thought before.

OK finally getting down to a serious suggestion. Are you proposing that the BL metapackages should depend on time-daemon instead of systemd-timesyncd?

That'd probably be the polite thing for it to do, given on a standard install 99%+ have standard system utils installed, which installs systemd-timesyncd, so if one of the other (known ones as opposed to virtualbox-guest-utils) is there it's almost completely certain they changed it on purpose.

I suppose
Depends: systemd-timesyncd
could be replaced with
Depends: systemd-timesyncd | time-daemon
if you thought it would be an advantage.

Errr.. That might work, or it might switch a user who'd deliberately switched to chrony or ntpsec for the increased features, I can't remember where I ran across apt's logic on such things explained before.

I know it prefers whatever's earlier in the list of "this | that". I think, but can't remember positively, it does nothing if any of the options are already satisfied, I seem to remember that with my long time ago testing with dbus-user-session & the explanation of apt's logic i read. In which case it'd be absolutely fine, whilst ensuring which one apt picked preferentially.

My guess is just time-daemon would pull in systemd-timesyncd anyway on any normal install with nothing.

Apart from I think I'm additionally going to have to spin up an install of sid just to report a bug on virtualbox-guest-utils for providing a time daemon without declaring it.. to sidestep the very first response of most maintainers "Does this happen in sid?".

Won't solve the issue for anyone using the VBox additions cd image but at least it'll fix anyone who gets their additions via fasttrack the offical way eventually. More time chasing my tail, over something that never affected most users.

Doubt I'll be looking at much today, I believe I've been volunteered to help clearing / getting stuff from my sister's late ex's flat. Which, as a sufferer of chronic fatigue syndrome, is likely to leave me physically drained for days.

Last edited by Bearded_Blunder (2024-06-06 10:15:35)

johnraff · 2024-06-07 02:52:53

Bearded_Blunder wrote:

Oh I'm peaceful enough, was very tired, hours down a rabbit hole, before I went to sleep. Though I also have an annoying cough, which isn't helping.
...
Doubt I'll be looking at much today, I believe I've been volunteered to help clearing / getting stuff from my sister's late ex's flat. Which, as a sufferer of chronic fatigue syndrome, is likely to leave me physically drained for days.

I'm sorry to hear that - please take things as easy as possible. Your contributions to BL are much appreciated, but your health must come first. I've been lucky in that at 74 I still don't seem to have any major issues. That could change of course...

In either case, that experimenter with Linux has no clue that they now have two time daemons running, one referencing an NTP server, & one referencing the host machine (which in the case of any recent host OS also does periodic checks against ntp servers), the two fight if there's a discrepancy.
Nor any clue that they should remove systemd-timesyncd (which they got as part of standard system utilities all unknowing), & not replace it with openntpd, ntpsec, or chrony (all that's available in Debian) without removing said additions.

Oracle ought to inform users of this. I suppose this could be one of the reasons Virtualbox is not available in the regular Debian repos, although the main one is to do with Oracle's policy with security updates. They make it very difficult or impossible for Debian maintainers to provide security patches for earlier VB installs.

I suppose
Depends: systemd-timesyncd
could be replaced with
Depends: systemd-timesyncd | time-daemon
if you thought it would be an advantage.
Errr.. That might work, or it might switch a user who'd deliberately switched to chrony or ntpsec for the increased features, I can't remember where I ran across apt's logic on such things explained before.

Just re-did some searching on this and I think it would be OK. If a package providing the virtual timesync-daemon is already installed then apt will leave things as they are. If none are installed then the real package (systemd-timesyncd in this case) will be installed, unless some other constraint pushes towards one of the others.
https://unix.stackexchange.com/question … al-package

My guess is just time-daemon would pull in systemd-timesyncd anyway on any normal install with nothing.

Quite possibly, but the consensus seems to be that it's best for a package to declare a real dependency first, rather than leave it up to apt to choose.

Maybe there are some other dependencies in bunsen-meta-all where an optional virtual package is available?

johnraff · 2024-06-07 03:12:18

johnraff wrote:

...Are you proposing that the BL metapackages should depend on time-daemon instead of systemd-timesyncd? The latter was chosen for these desktop collections simply because it's the smallest choice, and is Good Enough for most users.

I forgot to mention that the presence of systemd-timesyncd is really a transitional fix, because it's now in the Debian standard system utilities. It was needed because the functionality used to be built-in to systemd, and users who upgraded to the version where systemd-timesyncd became a separate package suddenly found themselves without any time daemon.
https://forums.bunsenlabs.org/viewtopic.php?id=8300
https://forums.bunsenlabs.org/viewtopic … 23#p125323

Bearded_Blunder · 2024-06-07 05:28:40

My guess is just time-daemon would pull in systemd-timesyncd anyway on any normal install with nothing.
Quite possibly, but the consensus seems to be that it's best for a package to declare a real dependency first, rather than leave it up to apt to choose.

In which case (and if so):

Depends: systemd-timesyncd | time-daemon

Looks fine, or to be init agnostic & still get consistent results (and the smallest install) given the alternatives which satisfy time-daemon one would do:

Depends: systemd-timesyncd | openntpd | time-daemon

However, being init agnostic requires finding an acceptable solution regarding dbus-user-session & dbus-x11, I'm not sure there's one you'll find acceptable getting off that particular merry-go round, no matter how I've played with the depends & the associated virtual packages (dbus-session-bus, which both satisfy, & default-debus-session-bus ,which only dbus-user-session does) using unpacked edited & repacked debs, it always ends up possible to end up with a systemd install with dbus-user-session missing, though my experience testing is you either have to skip standard system utilities (it gets pulled in by tasksel as a recommend on libpam-systemd which is included in s-s-u), or deliberately remove it between installing the system & installing the meta to do so.

If you install on a bare system with s-s-u omitted libpam-systemd gets pulled in, but not d-u-s because of --no-install-recommends

Maybe there are some other dependencies in bunsen-meta-all where an optional virtual package is available?

There are, but a quick skim of the official virtual packages list here leads me to suspect they're ones where we actually do depend on specific packages, you wouldn't want e.g. firefox-esr skipped because someone's cli system had elinks or links installed & thus "satisfied" the www-browser virtual, which either would.

I forgot to mention that the presence of systemd-timesyncd is really a transitional fix, because it's now in the Debian standard system utilities. It was needed because the functionality used to be built-in to systemd, and users who upgraded to the version where systemd-timesyncd became a separate package suddenly found themselves without any time daemon.
https://forums.bunsenlabs.org/viewtopic.php?id=8300
https://forums.bunsenlabs.org/viewtopic … 23#p125323

I completely missed that little situation, seems it happened while I was MIA, though it would explain why historically it'd have had no choice but to rely on that "hack" of checking for others & disabling itself as a built-in function.

Last edited by Bearded_Blunder (2024-06-07 05:30:39)

johnraff · 2024-06-07 09:53:18

Bearded_Blunder wrote:

Maybe there are some other dependencies in bunsen-meta-all where an optional virtual package is available?
There are, but a quick skim of the official virtual packages list here leads me to suspect they're ones where we actually do depend on specific packages, you wouldn't want e.g. firefox-esr skipped because someone's cli system had elinks or links installed & thus "satisfied" the www-browser virtual, which either would.

Interesting that while x-www-browser is a Debian alternative, it doesn't seem to be a virtual package. That would have been acceptable and allowed people to use eg Chromium.

Bearded_Blunder · 2024-06-07 10:37:05

I believe it used to be, in Jessie & earlier, well, there actually was still sort-of one in Buster, but it only had qtebrowser listed.

Now if only I could get my memory to work that well for the password on my laptop's Self Encrypting SSD, I wouldn't be contemplating downloading sedutil-cli & resetting it to completely blank & having to build back up from nothing...

Last edited by Bearded_Blunder (2024-06-07 10:42:02)

#1 2022-04-18 17:21:40