All testing is good; Ideally it will get a wide range of testing, with different setups and different usage patterns.

So it's a good thing also to test with virtual machines. We have of course tested in one such setup:

• qemu with daedalus

• using a qxl emulation graphics device

• two users + root in 4 VTs, with one user in 2 VTs

• all using startx jwm

• testing with elogind installed

• and testing with both elogind and seatd installed (defaults to using seatd)

• VT switch triggered via chvt in root shell via ssh

There are many test scenarios but Xorg is kind of fundamental so the more it's tested before going into the release, the better.

Suggested hands-on to bring in test packages (xserver-xorg-core and xserver-xorg-common):

1 # echo "deb http://deb.devuan.org/devuan experimental main" > /etc/apt/sources.list.d/X.list
2 # apt-get update
3 # apt-cache policy xserver-xorg-core xserver-xorg-common
4 # apt-get install --no-install-recommends -t experimental xserver-xorg-core

Note that step 3 is for you to verify that the packages from experimental are available, and so you can make note of the original package versions.

Make a note of which packages get installed, if there for some reason are more than those (there shouldn't be).

Restore to version $VERSION with

# apt-get install xserver-xorg-core=$VERSION xserver-xorg-common=$VERSION

@rolfie, use http without the s

check out https://wiki.qemu.org/Documentation/9psetup

Well, the particular issue with the attempt of using the daedalus installer as cdrom on UEFI appears to be that the boot loader syslinux64.efi (duly named BOOTX64.EFI) has some difficulty with that use case.

Using the same ISO as disk image on UEFI runs the same program without error.

Note that the chimaera ISOs (as well as the debian ISO) use grub rather than syslinux for UEFI boot, and apparently the grub boot loader lacks that sensitivity to that use case difference (i.e. whether the media is presented via a cdrom drive or a disk drive).

Perhaps it's simply that the boot loader gets mislead by the difference in sector size (where a cdrom has 2k sectors and a disk has 0.5k sectors). Unfortunately there are layers upon layers of compiled software involved so it's far from trivial to investigate these details. OTOH it's FOSS, so it just takes a bit of interest and skill to drill down into the particulars to determine the technical cause, and possibly correct it.

And there are of course other ways to achieve the goal of a "cdrom on UEFI" installer...

The "EFI PART" text is not a partition but the beginning of the GUID Partition Table (GPT), which it has in addition to the MBR partition table.

Both ISO sports 2 partitions, which you can read out from the MBR table (at 0x1c0-0x1ff).

The first partition is typed 0x00 (Empty) and it's defined to span the whole ISO from sector 0. The second partition is typed 0xef (EFI) and it's defined to span a block sequence within the ISO corresponding to the included FAT image.

The Debian ISO has both an MBR partition table and a GPT whereas the Devuan ISO only has an MBR. Presumably it's the lack of GPT that makes the Devuan ISO non-bootable for your UEFI use case.

It's good you had an alternative method for installation.

@simon_a, try with adding the following to /etc/default/seatd

export SEATD_VTBOUND=0

and then restart the service, which may well upset Xorg, but any goodness it might possibly bring doesn't take effect until its next start. A full reboot would also work.

Have you done

apt-get update

.. or whatever the corresponding button presses are on the gui tool?

Have you done

apt-get upgrade

.. or whatever the corresponding button presses are on the gui tool?

Have you done

apt-get dist-upgrade

  .. or whatever the corresponding button presses are on the gui tool?

Thoe are the three steps to follow after having changed sources.list.

I thought I just did Yes, go ahead.. see post #40

All the installer ISO have the same installer software and they only differ in which collections of packages they come with; the so called package pool. They work by installing that which you select, and then those selections expands by having dependencies. If you install with network mirror backing, they will all link up with the Devuan repository and they will all have all packages available.

The leanest system you can get from them is their base system where you opt for not installing anything else. That gives you a Linux operating system without all things you may expect, and in particular without graphical desktop environment. That's generally known as a "server system" although even a functional server would typically include some additional services such as perhaps ssh and web service.

The cinnamon desktop is generally understood to be "defined" by the task-cinnamon-desktop package, which is a content free-package that only depends on the collection detail packages that would make up a "cinnamon desktop". The "desktop" ISO contains all those packages, as do the collective of server+cd2+cd3+cd4 ISOs (both having also other packages that are outside of the task-cinnamon-desktop collection).

At a more general level, Devuan (like Debian) is like a warehouse of packages rather than an end-user "distribution", and it's up to the end-user to choose which subset of packages they will want to use. The installer offers some pre-packaged choices of end-user-like desktop collections, but that is supposed to be for convenience; in particular someone new to it may otherwise struggle a fair bit to pull together their best convenience package collection.

Nah. If you want to spout that shit you'll have to go elsewhere.

@Gregors, if you make a theme and email to me I can probably stuff it in as an option.

I'm not sure there is a bug report, but that particular issue of having multiple Xorg (in different VT) with seatd, is currently being worked on, and I believe an update is coming fairly soon.