The officially official Devuan Forum!

tyder

Member

From: Oslo, Norway

Registered: 2016-12-19

Posts: 37  

Running virtual machines: Possible important difference Devuan/Debian

I used kvm a lot for system setup in Poor Man's Installs (PMI), but it hasn't worked well for the last 8 years - coinciding with the introduction of systemd in Debian.
Therefore, I was eager to try kvm with Devuan 6.1.1 for this purpose. The method is to use the squashfs base image, first version from the ISO, and then setup a new persistent image by running kvm with the same squashfs base image as the running version, but another persistent image, on another partition.
I add a new boot stanza in my good old legacy grub's menu lst, with a new persistence directory, and start this new version with kvm

The boot stanza for the booted, base version is

title Devuan 6.1.1 64 bits Xfce live sdb2 v0  persistence sdb3 
      root(hd0,0) 
      kernel  (hd0,0)/boot/dev611/vmlinuz boot=live config quiet splash initrd=(hd0,0)/boot/dev611/initrd.img  bootfrom=/dev/sdb2 live-media-path=dev611/live0 persistence persistence-path=dev611s/pers0 keyboard-layouts=no noautologin 
      initrd (hd0,0)/boot/dev611/initrd.img
 

The boot stanza for the setup version is almost identical, only specifying a different persistence directory

title Devuan 6.1.1 64 bits Xfce live sdb2 v0  persistence sdb5 
      root(hd0,0) 
      kernel  (hd0,0)/boot/dev611/vmlinuz boot=live config quiet splash initrd=(hd0,0)/boot/dev611/initrd.img  bootfrom=/dev/sdb2 live-media-path=dev611/live0 persistence persistence-path=dev611Xs/pers0 keyboard-layouts=no noautologin 
      initrd (hd0,0)/boot/dev611/initrd.img
 

Then I simply start the new version by having kvm run the pc's basic boot menu:

 sudo kvm -m 2048 /dev/sdb &

This may be viewed as kind of 'super-charged chroot', for the same squashfs is run in the pc and the vm, it is just merged with two different overlays.
In PMI, the base image is mounted read-only, so there is no problem with that. And the persistent images are mounted on different partitons, with no interference between them. There are of course lots of reasons for making different versions - for different users, with or without Docker, with or without R, to mention some of my own reasons. And setting them up in a vm is very practical, at least for me. Very primitive version handling as it may be, it works well for me with scripted package install lists.
When trying this with Debian 13.3.0 Lxqt, running under Devuan, I'm not able to make it work. I can start the vm with a base image from the boot menu, but it's not possible to make persistence work in any simple way. The persistence structure is exactly like the Devuan case, and booting natively with it, there are no problems.
Is this a systemd limitation? I suspect so.

Last edited by tyder (2026-03-05 13:45:29)

fsmithred

Administrator

Registered: 2016-11-25

Posts: 2,865  

Re: Running virtual machines: Possible important difference Devuan/Debian

I didn't know I could do this, but it works. I think it's basically the same as what you're trying to do.

Live-usb, first partition is fat32 and has filesystem.squashfs, kernel and initrd, syslinux and grub files with boot menus.

Second partition is linux partition and I made a loopback file for the persistent filesystem. I kept the default username of devuan, so I didn't have to do anything special on first boot.

With nottyautologin I'm able to drop to console with ctrl-alt-Fn and there's a login prompt (n=1-6). Without nottyautologin, tty1 shows the end of the boot messages and no login prompt or command prompt. And tty2-6 are just black.

This is the boot command for user 'devuan'

BOOT_IMAGE=/excal_6.1.1/live/vmlinuz initrd=/excal_6.1.1/live/initrd.img boot=live live-media-path=/excal_6.1.1/live persistence persistence-media=removable-usb persistence-path=/loopfiles/ persistence-label=dev1 username=devuan  nottyautologin apparmor=0 

Second loopback file for alternate persistence. For the first boot, I added nox11autologin and S to boot to single user. As root, I deleted the primary user (devuan) and deleted all of /home/devuan, then created phred. (deluser and adduser). When I exited the root console, the desktop came up without having to log in.

On subsequent boot, I removed the nox11autologin, and phred's desktop came up without a login.

This is the boot command for user 'phred'

BOOT_IMAGE=/excal_6.1.1/live/vmlinuz initrd=/excal_6.1.1/live/initrd.img boot=live live-media-path=/excal_6.1.1/live persistence persistence-media=removable-usb persistence-path=/loopfiles/ persistence-label=dev1b username=phred nottyautologin apparmor=0

If your user's name is 'user' then it doesn't need to be set it in the boot command.

tyder

Member

From: Oslo, Norway

Registered: 2016-12-19

Posts: 37  

Re: Running virtual machines: Possible important difference Devuan/Debian

Small update:
It turns out that the method also works with a fresh Debian 13.3.0 Lxqt-version. I could use the same squashfs image there both for the native basis and the kvm instance, working on an overlay at another partition. So while this may have been systemd-related in the past, it doesn't seem to be now.
And it does of course not have to be the same squashfs image. Running Devuan under Debian or vice versa works just fine when starting with a clean 13.3.0-Debian version.

For administration and development, I can mount other drives read-only in the vm. For example, I have a large ext4 SATA partition  usually mounted on /store, and I can mount it read-only and use it for reading. For writing, I have the partition where the persistence volume is mounted. Which can be mounted read-only on the host to provide data traffic both ways in a simple and controlled manner.

I think this may be a useful environment for live development.
And there is no 'basic install' here. At the next boot, 'host' and 'vm' may swap roles. It is basically symmetric ;-)

dzz

Member

From: Exmouth, South West England

Registered: 2016-12-01

Posts: 112  

Re: Running virtual machines: Possible important difference Devuan/Debian

I'm instinctively concerned about loading my mounted and running system in a vm as a 'raw disk' even if only to access the boot menu. However:

Thanks to @tyder and @fsmithred, I finally worked out how to get persistence in qemu.

I tried a variation of fsmithred's usb method, having already a 'test' usb with grub(2) as bootloader. I shrunk it's fat32 partition, made a ext2 in the space, put 3x selectable persistence files there. Works, great potential for testing new stuff.

Booting as usb 'raw disk', in qemu, the unmounted usb device.

(convenience) 'devuan.iso' is 6.1.1 . One cmdline edit to select a different persistence-label=*

It's grub.cfg:

menuentry "Devuan Persistence" {
  set isofile="(hd0,1)/devuan/devuan.iso"
  loopback loop $isofile
  linux    (loop)/live/vmlinuz boot=live findiso=/devuan/devuan.iso username=devuan nottyautologin apparmor=0 keyboard-layouts=gb noeject persistence persistence-path=/devuan-pers persistence-label=pers0
  initrd   (loop)/live/initrd.img
}

I got some fsck errors on the persistence partition later but no clue yet to the cause. Maybe ailing disk. But this one is expendable and at least my running system is not involved.

This is interesting, now I can investigate the live-config process more closely.

I was slow to switch from grub-legacy because grub2 was released only half baked. But grub2 later improved, has it's own basic cli, can loop mount ISO's and works well for a boot usb.

I see no evidence, so far, of a systemd issue here, Debian's live-boot/live-config support systemd but do not demand it.

btw @tyder: Why do you need to run kvm/qemu as root?

Last edited by dzz (2026-03-07 04:44:30)

tyder

Member

From: Oslo, Norway

Registered: 2016-12-19

Posts: 37  

Re: Running virtual machines: Possible important difference Devuan/Debian

btw @tyder: Why do you need to run kvm/qemu as root?

I don't think I have to. But this is something i normally do more intensively every fourth year or so. So I don't think it hurts too much.

Regaring systemd, I think it may have been impllicit in the problems earlier, but clearly not with the latest Debian release. I just gave up using kvm for setup work ca 2016, after encountering new, strange problems. Have used it mostly for checking booting menus, testing ISOs etc the last ten years.
So I was quite surprised to find that it worked so well wirh Devuan 6.1.1. Following your advice with 'new' (mostly freshly cleaned) persistence volumes, it starts to look like a method for me. (As we have learnt, a method is a trick that you use twice.)

I use Qemu-kvm in the simplest way possible for me, and I try to avoid attempts at extending or educating it. Currently, that means it is mostly useful for SATA drives. I did not tell the whole story, for this kind of work I use older HP Probook laptops with both m2 and SATA drives. Normally, I run natively from m2 partitions, right now - my workload instance of Devuan 6.1.1 -  from /dev/nvme0n1p6 (squashfs) and /dev/nvme0n1p7 (persistence). The SATA partitions are used for storage (e.g. Docker images), development and testing.  And because of Qemu-kvm's good command of MBR SATA volumes, it is possible to proceed in very straightforward ways. For example, copying over to SATA partitions, I can run my older system versions, like Debian 9.1, in kvm under Devuan 6.1.1..
The only thing to  accomodate, is what I consider an age-old Linux bug: Caches may be re-used even if the cached content has changed on disk. The most visible effect in my case, is that kvm may not change legacy Grub's boot menu, even if menu.lst is changed. Fixed by dropping caches after syncing, a 'You Should Not'-procedure I only use when I have to.

Last edited by tyder (2026-03-08 00:04:43)

tyder

Member

From: Oslo, Norway

Registered: 2016-12-19

Posts: 37  

Re: Running virtual machines: Possible important difference Devuan/Debian

Small update:

I see no evidence, so far, of a systemd issue here, Debian's live-boot/live-config support systemd but do not demand it.

Nor did I, when Debian 13.3.0 and Devuan 6.1.1 behaved the same way.
But I couldn't get Debian 11.2.0 to work, it came up with the squashfs image, persistence was ignored running kvm.
This might, though, be an effect of the five remasterings done. So I started out with the squashfs from the ISO and a new persistence store.
Still didn't use the persistence volume, so here I have a  clear contrast between new 11.2.0 and 13.3.0 installs. Might still be unrelated to systemd, but scope creep always makes me suspicious when unexplainable errors occur.
For the purpose of running older versions in a vm, the obvious remedy is to squash the overlay file system into a new image.  Then it is enough to keep that, a few GBs disk space is saved, too.

BTW, here is the booting stanza for the Devuan instance I am running now:

title Devuan 6.1.1 64 bits Xfce live /dev/nvme0n1p6  v0  persistence/dev/nvme0n1p7  
      root(hd0,0) 
      kernel  (hd0,1)/boot/dev611/vmlinuz boot=live config quiet splash initrd=(hd0,1)/boot/dev611/initrd.img  bootfrom=/dev/nvme0n1p6  live-media-path=dev611/live0 persistence persistence-path=dev611nvme7/pers0 keyboard-layouts=no noautologin 
      initrd (hd0,1)/boot/dev611/initrd.img

Re bootloaders: Legacy grub was installed on the SATA disk by an OS version long gone. No need for any updating, I just add new directories with kernel&initrd images, and edit menu.lst. As long as I can run a version with legacy grub installed, I can repeat the procedure with new disks, and I do - it works with types of USB media and nvme-disks it had no idea about when first developed.
That's how a GRand Unified Bootloader should behave, in my head. So I wish for a GRUB-reinc (reincarnated legacy GRUB) with knowledge of GPT and loadable modules for UEFI navigations etc when absolutely necessary, kernel-style :-)