You are not logged in.
I had a single user defined. Enter UserID and password for that user, and press login. Back at login prompt.
Enter root for UserID and root's password, and the login completes. Root has a GUI in what appears to be XFCE4.
Get back to text console. Look in /var/log/auth.log
lightdm: pam_unix(lightdm:session) session opened for ****
...
gnome-keyring-daemon[ID]: couldn't create socket directory
couldn't bind to control socket
I will guess, the UID number of this user has changed, and hence it is a permission problem. Nope. No home for user. The /home partition has nothing in it.
mkdir /home/alyce
chown alyce.alyce /home/alyce
chmod 2750 /home/alyce
Attempt to login at GUI again, and it works this time.
/var/log/messages entry
[TS] alyce2 kernel: [time?] mousedev: PS/2 mouse device common for all mice
...
usb 2-5: Product: USB OPTICAL MOUSE
...
input: USB OPTICAL MOUSE as /devices/pci...
hid-generic ... USB OPTICAL MOUSE ...
...
then stuff about disk partitions and btrfs, so /usr is not mounted when the above USB/hid/libinput stuff is happening.
There were 3 boot events in messages, the above commentary is on the first, the other two are seemingly the same. Strictly speaking, the above processes was one where evdev was to be loaded for X to use for the mouse.
Looking in Xorg.log.0, it is back to what the libinput stuff was to bewgin with. It seems all ready to use a mouse, and then you see
config/udev: Add input device USB OPTICAL MOUSE (/dev/input/mouse0)
No input driver specified, ignoring this device.
On to #5.
/etc/init.d/slim stop
startx
X has mouse, and mouse works.
Install lightdm, and set lightdm to manage logins.
Reboot.
GUI screen now has mouse.
I'm guessing at this point, the next thing to try it that PS/2 mouse hint?
The mode on devtmpfs (searching /proc/mounts) is 755. The permissions on /dev/input/mice is 660 for root/input.
As I haven't tried actually logging in with that graphical GUI login screen, it is slim that is displaying it. The input group has no members listed in /etc/group.
I might have a 30-mouse.conf, but it would be residing in /usr/share (along with others). As libinput originally was processing everything, it would seem that the /usr partition is being mounted early enough for all those x.conf.d snippets in /usr/share to get loaded. There is however, no 30-mouse.conf (or any other mouse.conf) in /usr/share/X11/xorg.conf.d. In /var/log/messages early on in this process, there was a line which suggested the USB mouse was being treated as PS/2.
I am going to stop at this point, as I need to get outside and cut some more hay with a scythe before the dew evaporates away. I'll modify /etc/X11 to not load evdev and try this 30-mouse.conf. Comment #5 not processed yet.
Thanks.
To start with, there were quite a few things being mounted, that were never in fstab. Udev is one of them.
Unplugging and replugging in the USB mouse, sees changes to /var/log/(messages,Xorg.log.0). The Xorg file says mouse still being ignored (and I still have no mouse on GUI login screen). Restarting the udev service, sees messages in Xorg.log.0, but nowhere else. As far as input devices goes, the Xorg.log.0 shows stuff about the libinput devices: power button, USB keyboard. Dmesg shows a USB event, There is a input line for the mouse with a pci address, and then a hid line about a USB mouse.
I see that the installation has installed libgpm2 (a long time ago). Installing gpm goes fine. No change to Xorg.log.0, but messages has a change indicating that gpm daemon started succesfully.
Unplugging and replugging mouse has similar results to earlier, and still no mouse/cursor on the GUI login screen.
Added evdev to modprobe file. Evdev is loaded (was before too, but I didn't know when). Gpm works on the console. Modinfo evdev shows same thing you have (I was going to say author changed to Admiral Pavel Checkov, United Federation of Planets).
Module evbug does not exist here.
I don't mind the shotgun, I need to get practiced up. Next thing is to get fglrx on this machine. And as near as I can tell, I have to import Debian packages for that. I hope you got a good sleep.
Fortelling other threads to come. This machine has a HD5450 card, so not very much of a GPU. It needs Catalyst. Another machine has a HD6450 card, so a bit more oomph, it too will need Catalyst (and probably comes last). A third machine has an A10 APU and a R7-250 card, it needs Crimson (Catalyst for multiple GPU), which I have never got running. And fourth machine will have a RX-460. And if that isn't enough numbercrunching ability, I plan to set up a machine with a Ryzen 1600x and a RX560 (or two of them). I have some weather/climate modeling to do.
I have an older machine (Dell Optiplex 740 SFF) which had Debian/Jessie and Windows XP installed on a small hard disk. I replaced the hard disk with a bigger SSD, and partitioned it in such a way as to allow for 2 Devuan installations. A set of partitions (mostly btrfs, some ext[24]) and as a single ext4 partition (last one). There is some unallocated space beyond the last partition. I installed Devuan/Jessie to the single ext4 partition using the netinst CD, and then because I forgot a detail, did the install again with the Devuan DVD. I upgraded to Ascii, so as to get a 4.x kernel and rebooted. With a 4.x kernel working, I then put btrfs, ext4 or ext2 filesystems on the other partitions as planned, and proceeded to copy parts of the single partition installation over to the multiple partition one. There was some hickup about getting grub set up on the new set of partitions.
Along the way on booting, I seen the gui Devuan login screen, but never used it. I just changed to a text console and logged in as root.
With things starting to work, I thought I would do a gui login. There was no mouse (cursor). Unplugging the USB mouse and plugging it back in, same result. No mouse.
I see that inputs to X are now handled with libinput, which I have never worked with before (part of Wayland?). I didn't know if libinput was the problem, but I tried to see if falling back to evdev would fix things. So, I added a mouse snippet to /etc/X11/x.conf.d to allow for evdev on mice (pointers). And I can see in the Xorg.conf.0 log file, that it is correctly going over to evdev. And then the next 2 lines show that udev doesn't know what to do, and so it will ignore the mouse.
It doesn't matter to me (too much) whether I go back to libinput, or continue with evdev. But how does one get the mouse working? Or rather, how does one troubleshoot this?
Thanks.
I have 4 Debian machines on a LAN, with one machine running apt-cacher-ng to reduce downloads. Some hardware issues kept me from changing to Devuan earlier. But with Stretch going to a 4.9 kernel, most of the problems I think might happen should go away (oh, isn't the default kernel in Jessie 3.16.0-4 ?).
Some of the Debian-Jessie machines will transition to Devuan-Jessie, and that is it. Others will make the move from Devuan-Jessie to Devuan-Ascii.
Do I need to update the machine with the apt-cacher-ng before the other machines? I was actually planning to upgrade the smallest system first. Are there any problems with having apt-cacher-ng working with Debian and Devuan?
At some point in the not too distant future, I will have another 2 (3? 5?) Raspberry Pi type things preferably running something like Devuan. I want to get my time from GPS, and I want to do real time kinematics on positioning on the farm.
--
Live Long and Prosper