Have been tryng to replace slim with wdm so that i get rid of a dm which has dbus as a dependency. So, farewell to "login command failed". But "libseat has a problem with VT 0"-thing has returned. Any ideas how to fix that?

And searching with "(EE) seatd_libseat device not open (/dev/input/event0" resulted, amongst others:

https://www.reddit.com/r/devuan/comment … _20230103/
https://github.com/kennylevinsen/seatd
https://unix.stackexchange.com/question … sock-no-su
https://git.sr.ht/~kennylevinsen/seatd/ … 2b4cdf480c

Just as an aside, it seems that my dual nvme slots  in the ROG370 were only recognized by EVERY OS based upon Kernel 5.4 and earlier. The moment the upgrade to 6.0 NONE saw my second nvme, until i found only by accident a reference to  "  nvme_core.multipath=0  "  which negates the Kernel looking for sometthing that is NOT there -- so anything is possible these days.  i dont think anyone at LInus world even knows about it yet.

This is why i try so many  distributions - just to see how the evolutions sometimes DON'T  . .  .

just a last note here... i may try again later on to reinstall Daedalus with a different mind-set and maybe i will discover the pea under the mattress. I wonder if a straight upgrade from 4.0 to 5.0 instead of a wipe-and-install might work. 

Will let you know.

And thanks Nahkiirmees , for your thoughtful reply.

1) the user that runs Xorg in vtN must have rw access to both /dev/ttyN and /dev/tty, and (I think) have w access to /dev/tty0 as well. This access is required for Xorg's VT ioctls.

2) further, that user must have rw access to /dev/dri/card0, i.e. the graphics card in use which typically is card0 but could possibly by card1 etc. This access is required for Xorg's graphics ioctls.

3) further, that user probably must have access to /dev/fb0 as well.

In my case, 1) seems to be fine. Normal user account owns /dev/ttyN , /dev/tty has o=rw.
And 2) and 3) are achieved by normal users belonging to group video.

With 4) there may be a a problem concerning owners and rights of /dev/input*. That can be fixed one way or another.
But that is not the whole story since running startx as root bypasses the access-problem. And recently i had problems after exiting from xfce even when running as root.

Not too familiar with logind0, elogind or seatd.
Does the logind0 have something to do with systemd ?

Maybe i'll try the ssh-trick in a vm, what does the logs then say. But the easy way out seems to be same as Andrew's .

The permissions without  GUI TO WORK WITH
The inability to LAUNCH  a GUI at tty7 or any other tty
using sddm or slim and openRC and the other sysv alternatives did not resolve it.  Too bad.

whatever is necessary in permissions and users and groups to launch just the default desktop is beyond me with no visual way to work.  And no one has given me the path for that so  I give up for now. And startx is no option -- it just errors out.

leave me no way to know what to do at that point that will change the approaches as spelled out above by me and  all of you.

I will revert to Daedalus or the next experimental one later on this year but i have lots of work to do in the meantime that cannot be further delayed by this.

I know the problem should be narked solved when abandoned, but it is by no means solved.

Now on to Firefox repos ( not esr ) to get installed into Synaptic. But that requires a new question.

Thanks for  everything.

Andrew

1) the user that runs Xorg in vtN must have rw access to both /dev/ttyN and /dev/tty, and (I think) have w access to /dev/tty0 as well. This access is required for Xorg's VT ioctls.

2) further, that user must have rw access to /dev/dri/card0, i.e. the graphics card in use which typically is card0 but could possibly by card1 etc. This access is required for Xorg's graphics ioctls.

3) further, that user probably must have access to /dev/fb0 as well.

4) further, that user must have access to input devices, ether directly or as mediated by either logind0 or seatd. This access is required for Xorg's use of input devices.

4a) the logind0 method for mediating input deices requires access to a system dbus with whatever plethora of environment variables that requires. This typically gets done by using elogind for "session management".

4b) the seatd method for mediating input devices requires acces to the seatd communications socket.

Normally, (1) is typically achieved by the text terminal getty program which makes the logged in use the owner of the associated /dev/ttyN. The other (2-4) are typically achieved by the devices and the user being in the video group.

- Introduction
- New in this Release
     + Rootless startx uses libseat1
     + Sway (wayland) GUI without elogind

xserver-xorg-core now uses libseat1 to control rootless startx and access to
input and video devices. This has several advantages, the most significant being
that it removes the dbus dependency from xserver-xorg-core.

libseat1 can use either seatd or elogind as a
backend. If you need to override the default choice (autodiscovery), use the
LIBSEAT_BACKEND environment variable.

If you are using seatd as the backend, ensure the user is a member of the video group.

This is only relevant to running startx as a user, xorg run as root by a display
manager is unaffected.

### Wayland GUI without elogind

Users can now enjoy a wayland desktop without elogind by installing
libpam-ck-connector, sway and seatd.

Ensure the relevant user is a member of the `video` group and run sway from
the terminal.
. . . . . .. . . .

seatd is present. sddm and or slim are present.  xorg is present but not allowed to execute because it is locked out or some other error on the x-server.

What i did do was download fresh copy of the Install - live  . .  and see if there were any errors in the original downloaded .
.iso.  Nope - identical result.

What am  i forgetting to do  ? there must be something simple i am forgetting to do.

As i mentioned in another topic, i saw some errors about /dev/tty$some_number and libseatd also. In xorg's log.
Today i'll try to a) reinstall seatd-related packages and b) those grub parameters. If those will help.

GlenW  comments:
I AM able to see entire entries on my big monitor. 

When you do get to a tty, have you seen any errors about seatd? Because I found with a clean install seatd was not installed and the sddm would fail to show up and startx would not work either.

Once I installed seatd everything worked again. This was with kde/plasma desktop.

One other thing that may help... add console=tty12 to your grub line... I also add vga=794 to make the font smaller in-case the video module hasn't started, just makes it readable, for me. And may give more clues when it won't start properly.
----------------------------------

## No such error but i called it up and it was not installed so i installed it and system seemed to like it and IT DID advance the boot to a clean login position instead of having to fight through  paragraphs, so THANK YOU Glen . . 

## Here  are my notes on the more-obvious anomalies --  from phone pic of visible text at rest awaiting login:

/run/lock : creating directory
/run/lock : correcting owner    ( but later on at the end it remarks about being locked out of some access and failure to locate server [ which i will reference below ]
er,bin (-2)
     nouveau firmware failed to load nvidia drivers  ( but i see this often  across other OS )
        firmware : failed to load  i915/kbl_dmc_ver1.04
       nouveau : DRM: failed to create kernel channel, -22

## ALSA  warning runtime restore failed with errors

## Setting up  X  socket  directories seemed to be ok in temp files

## Seatd started
## slim started

## AFTER I introduced seatd then X proceeded  to login   [ Small victories , GlenW ]

E:  Could not open olock file  /var/lib/dpkg/lock-fronted - open ( 13: permission denied )
E:  Unable to acquire the dkg fronted lock ( var/lib/dpkg/lock-frontend),   ( are you root )

## When i run in root it still does not .. just x-sever error - besides cannot boot and stay in root - that is a big no no right ?

Still cannot access a desktop  in root either

Hi, when you do get to a tty, have you seen any errors about seatd? Because I found with a clean install seatd was not installed and the sddm would fail to show up and startx would not work either.

Once I installed seatd everything worked again. This was with kde/plasma desktop.

One other thing that may help... add console=tty12 to your grub line... I also add vga=794 to make the font smaller in-case the video module hasn't started, just makes it readable, for me. And may give more clues when it won't start properly.
----------------------------------

No such error but i called it up and it was not installed so i installed it and system seemed to like it and IT DID advance the boot to a clean login position instead of having to fight through  paragraphs.
Here  are my notes on the more-obvious anomalies --  from phone pic of visible text at rest awaiting login:

/run/lock : creating directory
/run/lock : correcting owner    ( but later on at the end it remarks about being locked out of some access and failure to locate server [ which i will reference below ]
er,bin (-2)
     nouveau firmware failed to load nvidia drivers  ( but i see this often  across otehr OS )
        firmware : failed to load  i915/kbl_dmc_ver1.04
       nouveau : DRM: failed to create kernel channel, -22
ALSA  warning runtime restore fialed with errors

Setting up  X  socket  directiores seemed to be ok in temp files

Seatd started
slim started

AFTER iintroduced seatd then X proceeded  to login   ( WHICH IS a help so thank yuou for that Nahkhiirmees.

E:  Could not open olock file  /var/lib/dpkg/lock-fronted - open ( 13: permission denied )
E:  Unable to acquire the dkg fronted lock ( var/lib/dpkg/lock-frontend),   ( are you root )

When i run in root it still does not .. just x-sever error - besides cannot boot and stay in root - that is a big no no right ?

Still cannot access a desktop  in root either

Once I installed seatd everything worked again. This was with kde/plasma desktop.

One other thing that may help... add console=tty12 to your grub line... I also add vga=794 to make the font smaller in-case the video module hasn't started, just makes it readable, for me. And may give more clues when it won't start properly.