The officially official Devuan Forum!

tyder

Member

From: Oslo, Norway

Registered: 2016-12-19

Posts: 34  

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,863  

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: 34  

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: 109  

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 (Today 04:44:30)