Apparently your machine runs multiple dhclient processes competing about the interfaces.

Which networking do you use? Do you use ifupdown (which primarily is configured with /etc/network/interfaces) or something else, or several?

Note that the updated Devuan daedalus installer ISO set 5.0.1 now also handles the use case of booting from CDROM on UEFI.

The issue indeed was that the boot loader got confused about the iso9660 block size (2k) differing from the expected block size (512) for the EFI filesystem. To fix that we forked syslinux, added a corrective patch and published to Devuan experimental. The patched software was next used for building the updated ISO set.

@yemuyin presumably the computer clock is off by 51.5 hours. You'll need to correct that.

@hunter0one, did you verify read-write access to the USB device node concerned?

Obviously you have read access but you do need write access right as well. Use e.g. lsusb to figure out which "bus id" it has, en then chech that /dev/bus/usb/xxx/yyy.

I guess you've confirmed file access mode for /dev/videoN .. you need rw I think.

Thanks. Good. Yes, we have seen a termination delay in some settings... not sure why that is.

Please email your observations with the Xorg log attached (would be ~/.local/usr/share/xorg/Xorg.0.log maybe?) as bug report:

$ reportbug xserver-xorg-core

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.