| rkta | Can I somehow use startx and kill it after some seconds? I don't have a working touch pad or keyboard after startx. I want to debug it w/o the need to reboot everytime. | 08:38 |
|---|---|---|
| gnarface | rkta: there's a few ways, yea | 08:38 |
| rkta | Would you tell me one? | 08:40 |
| gnarface | so, the traditional way, killing it by "ctrl+alt+backspace" has been disabled by default for some years, but you should be able to re-enable it somewhere in the menu that comes up when you run "dpkg-reconfigure keyboard-configuration" | 08:41 |
| gnarface | that should work unless your video driver has gone WAAAAY out to lunch | 08:41 |
| rkta | I don't have a keyboard after launching X. | 08:42 |
| gnarface | oh, well that makes it more complicated | 08:42 |
| rkta | I tried combinations of startx & kill ... but did not get it to work. | 08:43 |
| gnarface | well i'm not sure what value the exercise is, but you can try "at" to kill it on a timer | 08:44 |
| gnarface | there's also a way to launch Xorg while keeping the controlling terminal in a window in the Xorg instance | 08:44 |
| onefang | startx; sleep 5; kill ... | 08:44 |
| gnarface | i forget exactly how | 08:44 |
| gnarface | (and it might work in theory if the window has focus even if the rest of xorg is ignoring your keyboard) | 08:45 |
| gnarface | really though, you should check the Xorg log for errors (it might still be in /var/log but it's usually in ~/.local/share/xorg/ now) | 08:45 |
| onefang | Another option is to ssh into the box and kill from there. | 08:45 |
| rkta | The value is that I need to get X working again, because I should be working right now. :) | 08:45 |
| onefang | But that might not be an option. | 08:46 |
| gnarface | it would help a lot to know what changed last, since there shouldn't be any good reason for it to stop working | 08:46 |
| rkta | onefang: What's the ... in your kill command? | 08:46 |
| gnarface | -9 [PID] [PID] ... | 08:47 |
| onefang | You mentioned combinations, the ... would be those combinations. | 08:47 |
| onefang | or perhaps killall -KILL startx | 08:47 |
| gnarface | does it help to kill startx after it's run? i thought you had to kill X | 08:48 |
| rkta | The last changes I did was to do upgrades, I uninstalled two packages, which I already reinstalled and I rebooted. I have no idea right now. | 08:48 |
| gnarface | which two packages? | 08:48 |
| onefang | Dunno I don't use startx, and no idea off the top of my head exactly what X binary should be named there. | 08:48 |
| rkta | bind9-dnsutils and bind9-host | 08:48 |
| gnarface | onefang: i think startx is just a wrapper script for xinit. the binary to kill though i think is called Xorg | 08:49 |
| gnarface | (i think it might sometimes have been called just X in the past, but i could be wrong) | 08:49 |
| gnarface | you might commonly have to kill the window manager and several other child processes too though i think | 08:49 |
| onefang | Yep, pstree tells me it's Xorg. | 08:49 |
| onefang | Soooo killall -KILL Xorg | 08:50 |
| gnarface | rkta: grep the xorg log for the string (EE) | 08:50 |
| gnarface | "(EE)" just like that, case sensitive, without the quotes | 08:51 |
| brocashelm | maybe also look into dpkg-reconfigure keyboard-configuration so you can check if the ctrl+alt+backspace is enabled to terminate x? | 08:51 |
| brocashelm | nvm, i see it was mentioned a few lines ago | 08:52 |
| gnarface | suspected i/o lock, possible auto-detection fail or bad xorg.conf... | 08:52 |
| brocashelm | what about seatd in this case? | 08:53 |
| gnarface | rkta: which release, and are you using any xorg.conf customizations? | 08:53 |
| rkta | I started X again and it works now. I see some errors: http://0x0.st/HWx4.ee | 08:56 |
| rkta | I'm still on Chimaera and don't have a xorg.conf (other then maybe a system default) | 08:57 |
| rkta | I booted with an older Kernel, not sure if it is related. I will have to investigate later. | 08:58 |
| gnarface | if you use paste.debian.net i'll actually look at the errors | 08:59 |
| gnarface | have you mixed in any 3rd party packages or are they all from devuan's repos? | 08:59 |
| rkta | http://paste.debian.net/1294176/ | 08:59 |
| gnarface | sometimes 3rd party packages cause non-obvious problems after regular updates | 09:00 |
| gnarface | yea, this is a smoking gun here (EE) systemd-logind: | 09:00 |
| rkta | 3rd party is virtualbox and google chrome | 09:01 |
| rkta | Also these timeouts and system is slow with Synaptics and Trackpoint look suspicious. | 09:02 |
| gnarface | yea, that's definitely not supposed to be happening, which makes me wonder if you have stuff in there that pulled in some debian packages that aren't fully compatible | 09:03 |
| gnarface | it could just be the old kernel, i couldn't really be sure | 09:03 |
| gnarface | any sort of package version mismatches might cause something like this | 09:04 |
| rkta | I'll do a dist-upgrade next week and will see if it happens again. If so, then try to pin it down. | 09:07 |
| gnarface | see if you can figure out exactly which all packages came from the 3rd party repos | 09:07 |
| gnarface | that repeating systemd-logind error, i don't think you're supposed to be seeing anything like that at all | 09:09 |
| gnarface | it's also possible that something else got removed too, i think | 09:10 |
| gnarface | as far as i know if you're using startx, systemd-logind shouldn't show up in the log at all | 09:13 |
| gnarface | it should only be there if you're using a graphical login and even then it should only show up once, to say it's disabling itself, as a (II) not (EE) | 09:13 |
| rkta | gnarface: Here is a grep systemd of the log file. Could not post the complete log, it's to big. http://paste.debian.net/1294181/ | 09:17 |
| gnarface | rkta: hmm, do you think the failure case starts after it has resumed from sleep? | 09:21 |
| gnarface | like maybe it's fine after a cold boot until it goes to sleep for the first time? | 09:22 |
| gnarface | then... some driver goes out to lunch partway and then derails the thing | 09:22 |
| gnarface | it wouldn't be unprecedented | 09:22 |
| gnarface | statistically speaking though, 3rd party packages are the most likely culprit still | 09:23 |
| rrq | rkta: which version xserver-xorg-core do you have? | 09:23 |
| rkta | rrq: 2:1.20.11-1+deb11u6 | 09:24 |
| rrq | do you have the top part of Xorg log, where the deices are installed and their modules get loaded; which modules? | 09:26 |
| rkta | I think it's about something with timing. It seems random to me. But I don't think it's worth to debug more while I'm on oldstable. | 09:26 |
| rrq | it looks like something between Xorg and the devices is poweer toggling | 09:27 |
| rkta | rrq: http://0x0.st/HWxF.log.old Complete log | 09:27 |
| rrq | possibly if you uninstall xserver-xorg-input-libinput... either nothing will work or posssibly it gets better | 09:30 |
| rrq | need to restart X | 09:30 |
| rkta | rrq: will try | 09:31 |
| rrq | looks like udev keeps adding your touchpad for some reason; that won;t happen without libinput, but I'm not sure if you then need to declare the inouts explicitly | 09:32 |
| rrq | (maybe it has a loose connection?) | 09:32 |
| rkta | yeah, was thinking about an actual HW error | 09:33 |
| rkta | but, otoh, it works reliably now. | 09:34 |
| gnarface | check the batteries? | 09:35 |
| rkta | what batteries? | 09:39 |
| onefang | You mentioned at the beginning that the track pad was not working. That implies a laptop, which implies a battery. | 09:44 |
| rkta | my charger is plugged in | 09:45 |
| buZz | devuan still has 2.36-9+deb12u1 , shouldnt we get 2.36-9+deb12u3 now? | 11:37 |
| buZz | (on daedalus) | 11:37 |
| buZz | according to https://www.debian.org/security/2023/dsa-5514 | 11:37 |
| buZz | hmmz, i dont get it, why doesnt my apt show it existing yet | 11:39 |
| buZz | while its on https://pkginfo.devuan.org/cgi-bin/policy-query.html?c=package&q=libc-bin&x=submit | 11:39 |
| onefang | In chimaera that GLIBC_TUNABLES fix is available already. | 11:41 |
| buZz | so should be on daedalus too then? maybe my apt is broken | 11:41 |
| buZz | this was a jessie install that i endlessly upgraded, maybe finally broke :D | 11:42 |
| rrq | glibc-source=2.36-9+deb12u3 is in daedalus-security, and libc6=2.36-9+deb12u3 as well | 11:43 |
| buZz | welp, i declare it broken, then | 11:44 |
| * onefang hands you a spanner. | 11:46 | |
| buZz | i'll do a reinstall party this weekend perhaps :) | 11:48 |
| brocashelm | i got the package of libc6 version 2.36-9+deb12u3 from daedalus-security; everything is fine | 11:49 |
| * onefang goes back to my update party. | 11:51 | |
| AEonFyr | I recently discovered that Debian (bookworm) symlinks /bin to /usr/bin and Devuan (daedalus) doesn't. I'm assuming that is by design. Is there any explanation available as to why? | 17:02 |
| fsmithred | AEonFyr, google for usrmerge and you'll find plenty of info | 17:05 |
| AEonFyr | I did see some discussion when I was looking into it, but given Devuan is based on Debian, I wasn't sure if it is by design or a bug (or a work in process etc.). Is it intentional? | 17:09 |
| fsmithred | yes, there's even a question in the installer if you use expert install | 17:09 |
| AEonFyr | k, thanks. | 17:10 |
| fsmithred | we resisted because it wasn't ready for prime-time. The dpkg devs had some complaints. I don't know if that was resolved. | 17:10 |
| onefang | On the other hand, it works fine for some of us. | 17:10 |
| fsmithred | fwiw, a few years ago I installed ascii when it was still in testing and didn't notice the symlinks for a year | 17:11 |
| fsmithred | but I've avoided the merge on subsequent installs | 17:11 |
| AEonFyr | I only noticed it because egrep & fgrep scripts are in /bin and not /usr/bin on my devuan boxen. | 17:14 |
| fsmithred | The people most affected by the merge are those who don't use initramfs to boot. | 17:15 |
| onefang | In my opinion there's generally too much "OH NOES!!!111!!!elevn" over this usermerge thing. Use the symlinks. | 17:16 |
| onefang | Well no initramfs with a separate mount for /usr. | 17:16 |
| fsmithred | other problem is hard-coded paths in scripts | 17:17 |
| onefang | Which symlinks fix. | 17:17 |
| AEonFyr | onefang: Could you please clarify what you meant with "Use the symlinks"? After a bit of poking around I see a huge difference between the contents of /bin and /usr/bin. So I don't image you're suggesting simply ln -sf /usr/bin /bin, so was curious what you meant. | 17:54 |
| onefang | If you are using the usrmerge then the contents of /bin get moved to /usr/bin and a symlink is made. Same happens with /lib, /lib32, /lib64, /libx32, and /sbin. | 17:57 |
| onefang | There is a package usrmerge that does all this for you. | 17:58 |
| AEonFyr | Aah, ok, so usrmerge is a thing... I misunderstood it to be a policy or a proposal | 17:58 |
| onefang | It's something Debian has done. | 17:59 |
| ballsxd | hello everyone! i was wondering how i could fix "Errors were encountered while processing: mpd, openrc" | 23:21 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!