Lumina Desktop: the ISO (Part 2)

I have at last succeeded in placing my .iso file of the Lumina Desktop running in Void Linux on Sourceforge, where it will hopefully be available to anyone who wishes to download it.
The sourceforge link is

A few words about voidlumina.iso

  • it will boot from either DVD or USB drive
  • it will boot with either legacy boot, or uefi
  • two users root:voidlinux
  • it boots straight into the Lumina desktop, without a login, and you are user anon
  • if you logout, it drops back to the lxdm display manager. From there you can login as either root or anon
  • the Lumina config is the default, as installed, without any of the mods I describe in the document voidlumina.pdf found at
    Unix/voidlumina at main · nevillejackson/Unix · GitHub
  • the iso may also be used as an opportunity to view Void Linux or the Waterfox browser
  • it should automatically connect to the internet if you have an ethernet link with DHCP.
  • because the installer is part of the OS in Void Linux, this ISO will also act as an install disk. Just type void-installer and it will start the install script.
  • you may experience strangeness with power off. It will only power off as root. You can become root and use the power off GUI, or just su to root and do sync sync halt.

I have one issue: I do not understand why it boots into the Lumina screen without a login. It does not do that when booted from HDD. Something to do with starting the lxdm daemon when booting from an iso file?
If you find other issues, please inform me. I am still learning this .iso business.
Thanks to all who helped


I will surely try this on VBox!
And also, will tell you the things I like about it and the things which I think should be improved!


1 Like

Thanks for interest.
There is lots of room for improvement, both in Lumina, and in my .iso effort.
It is just meant as a live demo, where people can fiddle with Lumina configs.

Just gave it a spin in Boxes and there are definitely some items of interest! Nice work!

1 Like

I tried to spin up the live system in Hyper-V, however it did not go as smooth as I hoped it’d go.

Trying to boot into RAM yields the following result.

So, I tried booting normally, but that did not work, either.

It’s stuck like that. Won’t boot up.

Thank you Bill,
I needed to know it works, at least sometimes
@Akito is having problems

Try configuring Lumina… You can do it all with the GUI. See if you can make it somethong that suits you

Hi Akito,
That is disappipointing, it worked for @berninghausen in Gnome Boxes so there is not a total,failure. I tested it on a USB drive.
That message in first screen indicates it can not find root filesystem
I had that message while testing
In my case it was because I labelled the USB drive filesystem wrongly…it has to be labelled VOID_LIVE. It uses the label to find the filesystem.
I dont know what Hyper-V is? Are you doing a loop mount?
That second screen is blank?
What does booting normally mean?

Could you try a normal Void linux downloaded iso.?

just use base, live image for x86-64
It should be the same as mine, but that is how to check if problem is me or you or Void
Thanks for trying

@Akito ,
I tried for some hours booting directly from the .iso file on SSD. My 40_custom file is something like

exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry "VoidLumina ISO" {
        set isoname="voidlumina.iso"
	set isofile="/void-mklive/voidlumina.iso"
	echo "Using ${isoname}..."
	loopback loop (hd0,gpt3)$isofile
	linux (loop)/boot/vmlinuz isoscan/filename=$isofile root=live:(loop)/LiveOS/squashfs.img init=/sbin/init rd.luks=0 ro gpt vconsole.unicode=1 vconsole.keymap=us
	initrd (loop)/boot/initrd

It is the root=live:... parameter that fails
There is a message from dracut saying

Dont know how to handle 'root=...'

I have reached the tentative conclusion that dracut has not been configured (in Void) to support booting from a squashfs image.

To test that I have to add some modules to /etc/dracut.conf. At moment it is empty. I think I should add

add_dracutmodules+="dmsquash-live livenet nfs network base"

Then I have to remake the .iso file and test it.

On the issue of why it does autologin as user anon:
In the copy of Void on my SSD the file /etc/lxdm/lxdm.conf has the autologin statement commented out.
When I boot voidlumina.iso from a USB drive , and look in /etc/lxdm/lxdm.conf it has autologin anon.
So that has been added in the process of making the .iso file ???
Mystery. I cant see anything that would have added it. It should be a perfect copy of my original on hard disk.
Maybe it gets added as the USB drive is booted?

You said it was not easy.
Every distro makes their .iso files differently, so the amount of useful material on the internet is limited to articles on Void.

Note: The above 40_custom file is wrong.
See below for the correct way to boot Void Linux with grub from a .iso file on HD.

Just to clarify my experience, I’m running Kubuntu 22.04. Boxes ran the voidlumina file directly from my Downloads folder. Boxes can also run it from a USB stick running Ventoy. Should I generate a USB stick with an installable file? Would that be useful to you?

1 Like

It sounds to me like a sane default. Why should it be necessary to login when using a live system? It’s not persistent anyway, so why the extra step? It should be like what you describe: default to autologin.

As to where and when it gets added, leads probably to some startup script. Maybe even a custom Lumina/Void one.

Will do.

Void’s Base Live Image works perfectly fine, when booting from RAM.

1 Like

Hi Bill,
That is what I really wanted to know.
It means the voidlumina.iso file can be run directly from the hd copy
We just cant work out how to do it using grub? Boxes is more clever than me.
Try it from a Ventoy usb drive if you wish. I tested it from a usb drive made with the dreaded dd, that worked
Thank you

OK, thank you, I will stop worrying about autologin. It does make sense.

So the problem is mine
I think I have the answer… the program dracut is used to make the initramfs. It needs to find the root filesystem inside the .iso file. That is set in the grub.cfg line

linux (loop)/boot/vmlinuz isoscan/filename=$isofile root=live:(loop)/LiveOS

by the root = parameter
but dracut does not understand the parameter
because it is missing some modules
But how come the Void base live image is not also missing those modules, because it is made with the same script?

What I can do now is boot Void base live image from HD copy, and make sure I have the grub.cfg right.

When you said normal method of booting the iso, is that the same as what I am doing with grub?

There remains the mystery of how Gnome Boxes is able to boot the iso file from HD. See @berninghausen

Thank you

Note: The grub.cfg line shown above is wrong!!!
See below for correct way to boot Void Linux .iso file with grub


The first entry is normal, the second entry is booting into RAM.

It’s both more or less the same in the end, but the boot process differs between both methods.

Maybe it does some advanced stuff in the background. Never used Boxes, so I don’t know how it works.

Hyper-V specialises in running Windows images in the most recommended way possible, but also may run Linux, BSD, etc.

I guess, Hyper-V has the simplest emulation method, so a tiny misconfiguration might have a bigger effect.

However, that’s just a guess. There might be a ton of other reasons to consider.

1 Like

Ok, so you are still in HyperV
You are not using grub, like I am trying to do

One thing puzzles me about the grub method
Isolinux is on the .iso file
grub.cfg for a hd boot does not use it.?
Is isolinux only required for booting from CD or USB?
It seems grub can boot the squashfs.img file directly?
Is that right?

From what I read, Isolinux was required when GRUB Legacy had much less features and possibilities. Since GRUB 2, Isolinux has pretty much lost its original purpose. That’s what I remember about the topic, anyway.


1 Like

Thank you that clears a lot of issues

I might just try putting squashfs.img in a file and booting that… avoid the .iso altogether. According to my theory that should still fail, because the missing modules are inside the squashfs.

Now I really feel stupid. Using my Ventoy stick with both VoidCinnamon and VoidLumina aboard, I can’t find a way to install either. Yes, I know the Void website has instructions and I tried them, but I got bogged down in details beyond my ken. Neither ISO has a Calamares installer or similar, which is something an ignoramus like me needs.

Actually, Lumina looks really interesting, so I’ll go back to Kubuntu and look up the instructions and try to puzzle it out. I suppose I could just run it off a USB, but I’d like to install it on a HDD to see how Grub manages it. Anyway, it’s past my bedtime and I played golf 14 hours ago (first birdie of June!), so I’m beat. Sorry to not provide an answer, but you neglected to consider KISS advocates like me.

1 Like

If you really want to dig deep and make this all work the right way (from your effort it seems like you do), then it would probably be helpful to contact the Void community. Maybe even maintainers would lend you a hand. All you need to know is their particular build process and what quirks they use to make the live ISO work. That’s it. That should clear up all the dracut issues, because all these issues seem to stem from the way the original Void live image is crafted.