| systemdlete | I have my lightdm configured to autologin user A, but it actually autologins user B. I can't see any mods to the lightdm.conf file other than the one line specifying the autologin-user. This must be something really dumb that I overlooked. | 01:02 |
|---|---|---|
| systemdlete | comparing it to other systems here, the same one line is changed in all systems configured with lightdm | 01:04 |
| gnarface | hmm... perhaps at some point you've changed the order of the users but not the home directory uid's or something like that? | 01:04 |
| systemdlete | It's quite possible, given this is a testing system. | 01:04 |
| gnarface | only thing i can think of | 01:05 |
| systemdlete | it's kind of hard to screw up lightdm, but I think I dun did | 01:05 |
| gnarface | some sort of uid# mismatch left over from manual uid shuffling but accidentally missing steps | 01:05 |
| brocashelm | lightdm has a tendency of screwing up if you look at it the wrong way | 01:06 |
| systemdlete | I my gosh. | 01:07 |
| brocashelm | does the autologin for user b work with something like lxdm? | 01:07 |
| systemdlete | I DID look at it the wrong way. (I was wondering why it was giving me that look....) | 01:07 |
| brocashelm | lol | 01:07 |
| systemdlete | lol | 01:07 |
| systemdlete | it breaks the mirror if it stands in front of it | 01:07 |
| brocashelm | <ot-moment>that's why i just use startx</ot-moment> | 01:07 |
| brocashelm | but yeah, my experience with DMs is they are very hit and miss | 01:08 |
| systemdlete | yeah, I had some issues with lightdm (and maybe slim) so I reverted to the brocashelm method also | 01:08 |
| systemdlete | now I'm trying to re-establish lightdm. It is more convenient, saving me having to type passwords twice at boot. | 01:08 |
| systemdlete | even though this is a test VM, it was cloned from a generic (zygote is it?) template VM | 01:09 |
| brocashelm | what about automatically logging into tty when you boot? | 01:09 |
| systemdlete | so it has the encryption set up | 01:09 |
| systemdlete | hmmm. | 01:09 |
| systemdlete | Well, having it dump me out at the login prompt is not that bad. | 01:10 |
| systemdlete | why doesn't stuff work on linux anymore? | 01:10 |
| brocashelm | i think you do it with a package called mingetty | 01:10 |
| systemdlete | basic stuff like this | 01:10 |
| systemdlete | so you are telling me to beware DMs? | 01:11 |
| brocashelm | you could always switch to another tty if you want to get your other account logged into | 01:11 |
| brocashelm | yes | 01:11 |
| * systemdlete vaguely recalls an admonition like this in the past.... | 01:11 | |
| systemdlete | so does mingetty auto log me in? | 01:11 |
| systemdlete | (I mean, can it?) | 01:12 |
| systemdlete | or do I still need to submit a password? | 01:12 |
| brocashelm | found about it here: https://askubuntu.com/questions/168706/how-do-i-auto-login-as-root-into-the-tty-upon-boot | 01:12 |
| systemdlete | oh, so it logs me into the first tty it finds, something like that? | 01:12 |
| brocashelm | sudo apt-get install mingetty | 01:12 |
| systemdlete | I don't want to login as root!!! | 01:13 |
| brocashelm | you can change it to another username | 01:13 |
| systemdlete | ok, let me look at this, thanks. | 01:13 |
| brocashelm | np | 01:13 |
| brocashelm | and if you don't want to have to startx manually, you can add a line to your user b's .profile (i think) | 01:14 |
| debdog | that's how I do it | 01:14 |
| systemdlete | I have forgotten all about gettys and the days before desktops | 01:14 |
| brocashelm | oh, ~/.bash_profile | 01:14 |
| systemdlete | no I meant, I just don't think in those terms anymore | 01:14 |
| systemdlete | I have forgotten all the *nix basics is what I am saying | 01:15 |
| systemdlete | I know how to do them, basically, but I just don't think of them anymore. | 01:15 |
| systemdlete | I feel like an antique even thinking about them | 01:15 |
| systemdlete | ok, I will try that brocashelm | 01:16 |
| brocashelm | but the lightdm issue is something i'm not sure about, other than what gnarface suggested about uid mismatch | 01:16 |
| brocashelm | cool | 01:16 |
| debdog | systemdlete: my user's ~/.bash_profile: https://paste.debian.net/plain/1317287 | 01:17 |
| brocashelm | the last four lines | 01:18 |
| brocashelm | that's if you're already logged in, so it saves you from typing startx | 01:19 |
| systemdlete | the tutorial there doesn't seem to align with what's actually there | 01:20 |
| systemdlete | It says to modify a file /etc/init/tty1.conf, but that does not exist | 01:20 |
| systemdlete | I'm wondering if my VM is totally destroyed from testing... | 01:20 |
| debdog | yah, that's _not_ auto-login | 01:21 |
| systemdlete | I've installed mingetty. But no such file appears, at least on my VM. | 01:22 |
| fsmithred | One possible error with lightdm is to mistake the comment section for the section that actually does stuff. | 01:25 |
| debdog | systemdlete: gimme a few minutes, I have a working lightdm config for auto-login on one VM... | 01:25 |
| systemdlete | there are only 5 lines not commented out. 4 are section headers, and one is the autologin-user line | 01:26 |
| systemdlete | everything else is ignored | 01:26 |
| debdog | ..but this WM only has one user | 01:27 |
| systemdlete | that fu works on the other systems where I have installed lightdm | 01:27 |
| systemdlete | debdog, are you talking about your own config? I have 2 users in the VM, apparently | 01:27 |
| systemdlete | s/the VM/my VM/ | 01:28 |
| systemdlete | brocashelm, further down the same page you suggested, there is an alternate solution not requiring mingetty | 01:28 |
| systemdlete | not sure if that works, haven't tried it. Just trying to keep up with the help in this channel atm. | 01:29 |
| systemdlete | I still dont get why something as simple as this doesn't work right. | 01:29 |
| systemdlete | I have multiple users on several of my systems | 01:29 |
| systemdlete | have not seen this happen with those | 01:30 |
| brocashelm | it's like playing russian roulette | 01:30 |
| brocashelm | unfortunately | 01:30 |
| debdog | https://paste.debian.net/plain/1317288 inside my VM with a system that only has one user. removed all the #-lines | 01:30 |
| debdog | so, basically, there is not much that could be set unproperly | 01:30 |
| systemdlete | one thing I am noticing is that upon bootup, just before the prompt for the crypt key, I often times have long pauses with a blank screen. Then sometimes, even rarer, I get an RCU message | 01:30 |
| brocashelm | if you specified the username in the auto-login, then can't think of much else | 01:31 |
| systemdlete | debdog, that is pretty much what mine is also, but there is no timeout= bit; I do not set that in my other lightdm configs | 01:31 |
| systemdlete | brocashelm, yeah. | 01:32 |
| debdog | it might be required (in newer versions?) | 01:32 |
| systemdlete | latest version, latest kernel, latest everything here. | 01:33 |
| systemdlete | I keep my systems up to date, including testing ones | 01:33 |
| systemdlete | (usually, that is. Unless I've been away from testing anything recently...) | 01:34 |
| debdog | systemdlete: are you on testing? | 01:36 |
| systemdlete | when I say testing, I just mean for my own purposes here. Although I have been known, on my more awake days, to test new releases of devuan and other OSs (adelie, e.g.) | 01:41 |
| debdog | hehe, that does not answer my question | 01:42 |
| systemdlete | sorry. I guess I didn't get it. | 01:42 |
| systemdlete | do you mean as a formal member of the devuan test team? | 01:43 |
| systemdlete | (no) | 01:43 |
| debdog | is your VM a devuan stable release (vs. testing or unstable)? | 01:44 |
| systemdlete | oh! | 01:44 |
| systemdlete | (that! lol) | 01:44 |
| systemdlete | no. stable releases here only (with some rare exceptions and only for short spurts) | 01:44 |
| debdog | hehe | 01:44 |
| systemdlete | sorry about that buddy | 01:44 |
| debdog | no worries | 01:44 |
| * systemdlete 's mind doesn't work like most people's | 01:45 | |
| debdog | I have noticed | 01:45 |
| debdog | hrrhrr | 01:45 |
| systemdlete | why were you asking, now you have me curious | 01:45 |
| debdog | just because I have no clue about lightdm's state in testing | 01:46 |
| systemdlete | oh because then I might have been running an unstable lightem | 01:46 |
| systemdlete | yeah, right | 01:46 |
| systemdlete | no, I don't think so, in this case | 01:46 |
| systemdlete | I only installed lightdm just a while ago, actually. | 01:46 |
| systemdlete | maybe I should try force re-installing it. | 01:46 |
| systemdlete | not like it's a big effort to configure | 01:47 |
| systemdlete | know what--let me try that... | 01:47 |
| debdog | oh, in that case what gnarface mentioned earlier might apply. some lingering other config | 01:47 |
| systemdlete | It's a bit Microsoft Supportish, but wth. | 01:47 |
| debdog | how many DMs are listed in you /etc/rc2.d? hrrhrr | 01:48 |
| systemdlete | I checked that earlier--there is only lightdm. No slim, lxdm, or others that I can see. | 01:49 |
| systemdlete | I just recall something. While purging lightdm, it reminds me to remove dependencies. Some of those are lightdm deps, which kind of hung during the installation iirc | 01:55 |
| systemdlete | I had to restart the whole VM becuase of some sort of hang or something. | 01:56 |
| debdog | that's unusual | 01:56 |
| systemdlete | And I just got another RCU hit when I rebooted just now. | 01:56 |
| systemdlete | Yeah, so I am removing all the dependencies and start fresh. | 01:56 |
| systemdlete | Maybe something got badly corrupted | 01:56 |
| systemdlete | I'm wondering if I was getting RCU hangups during that install attempt and maybe that caused the long pause during the install. | 01:57 |
| systemdlete | but if so, then that is pretty scary, isn't it? | 01:58 |
| systemdlete | I'd think apt or dpkg could recover from something like that | 01:58 |
| debdog | what does RCU stand for? | 01:59 |
| systemdlete | I forget but I think it has something to do with the ring buffers? | 01:59 |
| debdog | dunno, 'v been using aptitude for more than a decade and it is pretty solid when it comes to conflicts and such | 01:59 |
| systemdlete | my luck with apt has been good, overall. | 02:00 |
| brocashelm | apt just needs to not be so painfully slow, but that's a debian issue specifically | 02:00 |
| systemdlete | and then consider (not sure if you followed this) I was having issues with apt-cacher-ng for a bit (and still do) | 02:01 |
| systemdlete | lightdm install stuck at 3% during accessibilty themes--really? every time? | 02:02 |
| systemdlete | it will move on, but it takes some time usually | 02:03 |
| debdog | congrats! you've created a linux based windows VM! hrrhrr | 02:09 |
| systemdlete | :p | 02:22 |
| systemdlete | so what I just did was this: I changed the user name, user id, user group id, moved its home etc | 02:22 |
| systemdlete | double checked that I did all that correctly. Did not find any remaining remnants of user B | 02:23 |
| systemdlete | note that even logging out from user B and loggin back in as user A, I still got logged into user B's home anyway!!! | 02:24 |
| systemdlete | so, now when I reboot, I get logged into user A. | 02:24 |
| systemdlete | WTF? | 02:24 |
| systemdlete | so I am guessing that something was stuck in lightdm's craw and it kept wanting to login as user B | 02:24 |
| systemdlete | but now that user B no longer has the same identity, it can't login as user B | 02:25 |
| systemdlete | somehow, it reverts to logging in user A | 02:25 |
| systemdlete | I do note that lightdm keeps a couple of user-specific directories under /var | 02:26 |
| systemdlete | I am wondering if that might have something to do with it. | 02:26 |
| systemdlete | I'm looking at lightdm's logs (which I should have done to begin with) and what I notice is that the greeter is being invoked (not surprisingly considering the outcome, but still surprising) with the userB identity | 02:36 |
| systemdlete | I conclude that this is not good. | 02:37 |
| systemdlete | Logging a user in as a different user might lead to some system vulnerabilities and the like, couldn't it? | 02:37 |
| * systemdlete thinks so | 02:38 | |
| debdog | I don't think that's a lightdm issue anymore | 02:38 |
| systemdlete | whose issue is it now? | 02:39 |
| systemdlete | This whole episode began because I was trying to investigate a desktop freezeup in the VM. I was till able to ssh in from another system, but I could not kill the xfce panel unless I used -9 | 02:41 |
| systemdlete | even then, the desktop was unresponsive. | 02:41 |
| systemdlete | after rebooting the VM, this weirdness with lightdm began. I had not seen this previously. | 02:41 |
| systemdlete | debdog, any ideas? | 02:46 |
| systemdlete | One thing to note is that I was running zoom sessions on that VM until a couple weeks ago. I wonder if zoom is vulnerable to some hacking? I have heard of zoom bombers, but maybe there are other forms of malice borne of boredom and poor self-esteem. | 02:48 |
| systemdlete | The testing I've been doing on that VM is not the sort I'd expect to cause widespread damage to the system. | 02:49 |
| systemdlete | userland stuff mainly | 02:49 |
| debdog | <systemdlete> note that even logging out from user B and loggin back in as user A, I still got logged into user B's home anyway!!! – that sounds very off. a mixuo with UID? | 02:50 |
| systemdlete | ok, so I changed userB's uid, gid, and home and that... fixed it? | 02:51 |
| systemdlete | I did NOTHING to userA | 02:51 |
| systemdlete | I agree it sounds way off | 02:51 |
| systemdlete | debdog, brocashelm mentions that DMs can offer varying mileage. It seems to be a crapshoot. | 02:53 |
| systemdlete | Based on brocashelm's suggestion, I am still suspicious of lightdm. | 02:53 |
| systemdlete | E.g., maybe earlier on, I had had lightdm.conf configured to autologin userB. Then later I switched it to userA. And that somehow confused lightdm. | 02:54 |
| systemdlete | I don't recall doing that, but maybe I did. | 02:54 |
| systemdlete | It could have been months ago. | 02:54 |
| debdog | <systemdlete> note that even logging out from user B and loggin back in as user A, I still got logged into user B's home anyway!!! – you're then user A but inside user B's home? | 02:55 |
| systemdlete | I ran id(1) and could easily see it was logged in as userB, not userA | 02:56 |
| debdog | ahh | 02:57 |
| systemdlete | among other things under /var, there are caches and .caches of lightdmware. | 02:57 |
| systemdlete | Like I said, I am suspicious that lightdm cached something thinking it should be persistent. | 02:57 |
| systemdlete | as in forever persistent. | 02:57 |
| systemdlete | Now that I think of it, I did make one other change today to that VM. | 02:58 |
| systemdlete | I enabled 3D because I was going to to test something. | 02:59 |
| systemdlete | (that might be related to the freeze up, btw. Idk at this point, having gotten stuck in the lightdm crap) | 02:59 |
| systemdlete | I need to get some grub. | 03:00 |
| systemdlete | I'll comme back to this later. | 03:00 |
| systemdlete | *come | 03:00 |
| * systemdlete fingers getting shaky | 03:00 | |
| debdog | bon ape tit | 03:05 |
| systemdlete | carl's jr is not exactly fine cuisine, but thanks | 03:05 |
| debdog | systemdlete: if you disable lightdm, reboot the system then log in as user A on tty1 and user B in tty2, everyting is ok? (as in each user works fine and is inside its own directory? | 03:06 |
| debdog | l /var | 03:14 |
| debdog | hehe | 03:14 |
| debdog | wrong window, obvioulsy | 03:14 |
| Weeezy | I have forgotten the wording but in the devuan 5 set up it asks something about sharing usage data with devuan. can someone tell me about that? I'm sure I said no to this but I seem to have traffic from pkgmaster.devuan.org near constant | 03:14 |
| Weeezy | sorry I know I broke the conversation flow | 03:16 |
| rrq | the "sharing usage data" would have been the s.c. "popularity contest" ? ... send statistics about your packages to popcon.devuan.org | 03:17 |
| rrq | (not pkgmaster) | 03:17 |
| Weeezy | for the sake of asking, what is the service that would be transmitting that back and forth, can I shut it down | 03:19 |
| Weeezy | ? | 03:19 |
| rrq | I think it's some apt conf settings onlly; not a service | 03:19 |
| rrq | somehting else | 03:19 |
| rrq | which ports are involved? | 03:20 |
| Weeezy | right now I have tcp and http blocked int he firewall. netstat shows pkgmaster.devuan.org still trying connect | 03:20 |
| rrq | ??? "pkgmaster.devuan.org still trying connect" > | 03:21 |
| rrq | ? | 03:21 |
| Weeezy | I'm more confused than anyone | 03:21 |
| Weeezy | I can screen shot it | 03:21 |
| rrq | you don't mean your host tries to connect to pkgmaster? | 03:21 |
| rrq | yes.. screenshot it | 03:22 |
| rrq | unless you can show a log | 03:22 |
| rrq | you're 31.129.232.12 ? | 03:24 |
| rrq | currently grabbing changelogs ? | 03:25 |
| Weeezy | I'm not gonna be able to send anything. I have a picture of the screen. | 03:29 |
| Weeezy | I'm looking at imgur but maybe there is something better | 03:29 |
| rrq | curl --upload-file $F https://transfer.rrq.au/$F | 03:30 |
| Weeezy | ok. one sec | 03:32 |
| Weeezy | I'm gonna send this to my other self curl --upload-file $F https://transfer.rrq.au/$F | 03:39 |
| rrq | ... and tell me the download link | 03:42 |
| Weeeezy | $f represents the filename? | 03:43 |
| rrq | yes, the basename (no path)... the first $F can be full path though | 03:44 |
| rrq | the page at https://transfer.rrq.au also has the point-and-click upload option | 03:45 |
| Weeeezy | that will be quicker | 03:45 |
| Weeeezy | https://transfer.rrq.au/eg04Oh9SH4/one.png | 03:47 |
| Weeeezy | idk if that screen will make sense for you. if not ask for what will make sense | 03:48 |
| Weeeezy | I had netstat run continous netstat -a -c to capture the traffic | 03:51 |
| Weeeezy | I was blocking port 80 and 443 | 03:51 |
| Weeeezy | so it started showing the syn_sent fault | 03:51 |
| rrq | hmm... | 03:54 |
| rrq | is it still going? | 03:54 |
| Weeeezy | I opened up the two ports | 03:55 |
| Weeeezy | I'll check | 03:55 |
| gnarface | maybe just see if you have popularity-contest installed then uninstall it? | 03:55 |
| rrq | no popcon is a different host | 03:55 |
| gnarface | oh | 03:56 |
| rrq | there should never be outgoing connections from pkgmaster | 03:57 |
| Weeeezy | it doesn't appear to listening or established at the moment | 03:58 |
| Weeeezy | it does try a number of other addresses before it gets to the one in question, and that will continue for quite some time. trying port after port | 03:59 |
| gnarface | doesn't netstat say which process is making the connections? | 04:01 |
| gnarface | if not you should be able to get it with fuser | 04:01 |
| Weeeezy | I couldnt find a command that would give me the pid, not that there isn't one | 04:02 |
| gnarface | could it just be something like that kde graphical package manager thing checking for updates? | 04:02 |
| rrq | Weeeezy: could you pm me your IP ? | 04:05 |
| Weeeezy | yes, sure. | 04:05 |
| Weeeezy | I have another computer running so I don't how to seperate what a scan might find | 04:06 |
| rrq | it looks related to changelog retrieval | 04:10 |
| rrq | would be your end doing that every so often (?) | 04:11 |
| Weeeezy | idk. | 04:11 |
| Weeeezy | THeres something up. there.quite a few established connections at the moment.and there shouldn't be. | 04:12 |
| rrq | like a handful of concurrent requests... (this is from nginx log) | 04:12 |
| rrq | most of those render 302 (redirect) responses to debian | 04:12 |
| rrq | do you run unattended updates? and it has spawned multiple "let's check if something changed" processes? | 04:13 |
| Weeeezy | a dozen or more | 04:13 |
| Weeeezy | it's a new install from just a couple days ago | 04:13 |
| Weeeezy | I noticed it drawing a lot of traffic with my router software | 04:14 |
| Weeeezy | I was trying to stop that. | 04:14 |
| Weeeezy | but unsuccesful | 04:14 |
| rrq | I'm not sure what drives it, but it seems to lack mutex | 04:15 |
| systemdlete | same VM just froze again. | 04:15 |
| systemdlete | I am going to disable 3D and see if it keeps freezing | 04:15 |
| al1r4d | hello everyone~~ | 04:17 |
| Weeeezy | well, maybe this fuser program will help. I'll tinker with that. | 04:19 |
| Weeeezy | If I can find the source I wold have some direction | 04:20 |
| gnarface | if might help you to look for the outgoing port | 04:20 |
| Weeeezy | I'm not sure how accurate the stats are on the router but this box, just sitting idle most of the day with the ports turned off is near two gigabytes | 04:20 |
| rrq | there's an apt-compat cron script that might need some flock | 04:21 |
| Weeeezy | likely counting all the rejected packets | 04:21 |
| gnarface | when a tcp/ip connection is made typically (by something that isn't a nintendo) the outbound port is randomized and never the same as the destination port. so you're not actually looking for ports 80 or 443 open on your local network device, you're looking for probably some high 5-digit range ports where those connections are originating | 04:22 |
| Weeeezy | I'll reengage the port block for now. thanks everyone | 04:22 |
| gnarface | (and they'll be different for every connection) | 04:22 |
| systemdlete | I can ssh into the frozen VM. What might I do to figure out what is causing the freeze? I mean, htop doesn't tell me much. | 04:24 |
| gnarface | systemdlete: nvidia drivers involved this time? | 04:30 |
| systemdlete | no... but I do have an nvidia card installed. I'm not using it though. | 04:33 |
| systemdlete | The mb is radeon | 04:33 |
| systemdlete | is that bad? | 04:33 |
| systemdlete | did I just make a royal mess of things? | 04:33 |
| systemdlete | or is the problem doing this with a VM | 04:35 |
| systemdlete | seems some people are doing it successfully, but they donn't mention virtualization | 04:35 |
| gnarface | you haven't mentioned doing anything that should have hosed it | 04:38 |
| gnarface | to be honest if you can ssh into it still the verdict is still out on whether it's even really frozen | 04:39 |
| systemdlete | xfce4 desktop does not respond. I call that frozen, but maybe there are things I don't know | 04:39 |
| gnarface | maybe the screensaver just crashed>? | 04:39 |
| systemdlete | no screensaver in any of my VMs. I let the host manage that. | 04:40 |
| gnarface | ? some dpms problem | 04:40 |
| systemdlete | searching dpms with ddg tells me all bout rifles | 04:41 |
| gnarface | i have a problem with Steam and Wine sometimes that affects nothing else, where some or all of the window will be black and apparently unresponsive, but secretly actually working just not rendering, until i do something weird to it to force a redraw | 04:41 |
| systemdlete | ^L? | 04:41 |
| systemdlete | (let me try that!) | 04:41 |
| gnarface | usually it involves doing something to it with the mouse that resizes the window manually or triggers a drag+drop action or something like that | 04:42 |
| systemdlete | also tried ctl-alt-bs but no luck | 04:42 |
| gnarface | are you sure ctrl+alt is being sent through to the VM in question? | 04:43 |
| systemdlete | hmmm. ok I will try a few ways with that | 04:43 |
| gnarface | also run this from the ssh connection: xset dpms q | 04:43 |
| systemdlete | I use the menu insert characters, so it had better!! | 04:43 |
| systemdlete | unable to open display "" | 04:43 |
| gnarface | you might have to set DISPLAY even to get the right terminal output with that though | 04:43 |
| systemdlete | yep | 04:43 |
| systemdlete | will | 04:43 |
| gnarface | check the last 4 lines | 04:44 |
| systemdlete | last 4 lines of... ? | 04:44 |
| gnarface | the "xset dpms q" output | 04:44 |
| gnarface | after you've manually pointed it to the right DISPLAY | 04:44 |
| systemdlete | that was the only line emitted | 04:44 |
| gnarface | probably :0.0 | 04:44 |
| systemdlete | oh | 04:44 |
| gnarface | DISPLAY=":0.0" xset dpms q | 04:44 |
| systemdlete | it hangs | 04:45 |
| gnarface | HANGS? | 04:45 |
| gnarface | then it's xorg itself that's locked up | 04:45 |
| systemdlete | in the ssh window, yes, that command hangs | 04:45 |
| gnarface | gotta be xorg itself then, is my guess | 04:45 |
| gnarface | not sure why | 04:45 |
| gnarface | xorg instance inside the vm is unresponsive | 04:45 |
| gnarface | ctrl+alt+backspace probably would have worked but note that it's disabled by default these days | 04:46 |
| systemdlete | oh lucky us | 04:46 |
| gnarface | normally i blame nvidia drivers on stuff like this but in a VM context i can't guess what would be the likely culprit... you using virtio* drivers in there for graphics, right? | 04:47 |
| systemdlete | strace -p nnnn (pid of xorg): FUTEX_WAIT_PRIVATE over and over again | 04:47 |
| systemdlete | futex(0x55ee14c7b1a0, FUTEX_WAIT_PRIVATE, 2, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set) | 04:47 |
| systemdlete | followed by | 04:47 |
| systemdlete | --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} --- | 04:47 |
| systemdlete | and those 2 lines repeat endlessly | 04:47 |
| gnarface | not sure what that means, maybe a real developer has an idea? | 04:47 |
| systemdlete | let's see what Uncle Duck has to say about it. hold on | 04:48 |
| systemdlete | https://bbs.archlinux.org/viewtopic.php?pid=1379236#p1379236 | 04:51 |
| systemdlete | Indeed, I have libvdpau-va-gl1 AND nvida-vdpau-driver installed | 04:51 |
| gnarface | hmm | 04:51 |
| gnarface | but it's an AMD host system with virtual video cards in the guest? i'd say you don't want either of those packages in the guest | 04:52 |
| systemdlete | honestly not sure wth I am even talking about at this point, but at least I /feel/ like I am getting some info... | 04:52 |
| gnarface | and actually i doubt you want either of them on the host | 04:52 |
| systemdlete | the mainboard is AMD with an onboard radeon and I also have a nvidia card in the pcix16 slot | 04:53 |
| systemdlete | (but the nvidia is not attached to any monitor) | 04:53 |
| gnarface | libvdpau-va-gl1 in fact is only really useful for cards that don't have any va-api or vdpau support otherwise... shouldn't be even relevant for something with a real hardware vdpau and vaapi interface, such as any modern intel amd or nvidia card | 04:53 |
| gnarface | libvdpau-va-gl1 is actually just a va-api wrapper for opengl cards | 04:54 |
| systemdlete | so should I still try to remove these? and if I do, will it cause 600 packages to be removed with it? | 04:54 |
| systemdlete | (dependencies! dependencies!) | 04:54 |
| gnarface | no idea | 04:54 |
| gnarface | in a fair world no, since those are both optional packages | 04:54 |
| systemdlete | hmm. I guess it is a fair world then. Only that one package (meta package) vdpauinfo | 04:55 |
| gnarface | for the onboard AMD you'd want the mesa-vdpau-drivers package instead of the nvidia one anyway | 04:56 |
| systemdlete | should I install it? | 04:56 |
| systemdlete | (it's strange that I do not have these issues on my other AM3+ machines) | 04:57 |
| gnarface | completely up to you. it's only useful for watching video | 04:57 |
| systemdlete | I run zoom on it, so maybe yeah | 04:57 |
| systemdlete | already installed | 04:57 |
| gnarface | and you would use mesa-va-drivers in place of libvdpau-va-gl1 | 04:58 |
| systemdlete | btw, I've looked at the user's .xorg-errors file and the system Xorg.0.log | 04:58 |
| systemdlete | removing libvdpau-va-gl1 | 04:58 |
| gnarface | does xfce have its own error log? | 04:59 |
| gnarface | or does it just log to the xorg log? | 04:59 |
| gnarface | it might have caught a clue too, right when this started | 04:59 |
| systemdlete | .xsession-errors in user home and /var/log/xorg.0.log | 04:59 |
| systemdlete | the user's .xsession-errors log just says that xfce4-panel theme parsing error: gtk-wideget style property blah blah blah is deprecated and should not be used anymore and it will go away in the future | 05:01 |
| systemdlete | it says that like 20 times in a second (prob while bringing up the desktop) | 05:01 |
| gnarface | it would probably be easy to find theme that's less noisy | 05:02 |
| systemdlete | yeah. will look into that later, thanks | 05:02 |
| systemdlete | is there a way to send xorg a message the equivalent of ctl-alt-bs? | 05:06 |
| systemdlete | from command line? | 05:06 |
| gnarface | yea you just kill -9 it | 05:06 |
| gnarface | kill -9 [PID] | 05:06 |
| systemdlete | will it restart itself ? | 05:06 |
| gnarface | no, that's force shutdown. -HUP would be restart, not that i've tried it | 05:07 |
| gnarface | (not that i've tried it on Xorg anyway) | 05:07 |
| gnarface | oh, but if you have a graphical login, that might restart it | 05:07 |
| gnarface | usually the graphical logins run as a separate X session that launches the first one | 05:07 |
| systemdlete | you mean the greeter? | 05:08 |
| gnarface | yea... so if you have one of those up, killing X should just cause it to take over, and then logging in again should cause it to start X again... but there's no particular reason to expect it's not locked up too right now, so who knows what will happen really | 05:08 |
| systemdlete | how would I get a login window? I think only vt7 is running xorg | 05:09 |
| gnarface | ctrl+alt+f2 do anything? | 05:10 |
| systemdlete | no. even using the soft keyboard, no response. It is ignoring me. | 05:11 |
| gnarface | if you have a normal sysvinit install with a normal inittab, then vts 1-6 should all be running getty, which provides that default text login ubiquitous before graphical logins | 05:11 |
| gnarface | sometimes vt1 is actually Xorg though these days | 05:12 |
| systemdlete | right. I mean, I could try starting a new xfce4 session from one of them. | 05:12 |
| gnarface | yea, i'd recommend killing the old ones first though... | 05:12 |
| systemdlete | but I think it might be upset because there is already xorg running as root | 05:12 |
| gnarface | or maybe try to kill -HUP them just for science but don't expect much | 05:12 |
| systemdlete | kill the getty's ? why? they are working | 05:13 |
| gnarface | no, not the gettys, the Xorg instances | 05:13 |
| gnarface | or maybe even just the xfce instances | 05:13 |
| gnarface | ctrl+alt+bs is basically kill -9 though, if you previously saw xorg relaunching after a ctrl+alt+bs, that's your graphical login stack doing that | 05:14 |
| gnarface | ...and it may still work for doing that if you kill -9 the right thing | 05:14 |
| systemdlete | kill -9 nnnn (xorg process) just turns it zombie | 05:14 |
| gnarface | give it a few seconds | 05:15 |
| systemdlete | still zombie | 05:15 |
| gnarface | get your shotgun | 05:15 |
| systemdlete | maybe that dpms rifle? | 05:15 |
| systemdlete | :D | 05:16 |
| systemdlete | this is the 2nd freeze since enabling 3D. | 05:16 |
| gnarface | i thought if maybe we could find evidence that this had happened when dpms had triggered a screen blank we could diagnose it as some sort of power management issue in software | 05:16 |
| systemdlete | maybe coincidence, maybe not | 05:16 |
| gnarface | but since xorg was so out to lunch it wouldn't even respond to xset i dunno that we can find out what happened without catching it in the act | 05:16 |
| systemdlete | power management in a VM? | 05:17 |
| gnarface | Display Power Management System (i think) is what that stands for | 05:17 |
| systemdlete | I'm willing to leave 3D going and restart the VM cold. But only if you are interested in "the science" | 05:17 |
| systemdlete | otherwise, I'll just put it back to no 3D | 05:18 |
| gnarface | so yea, in theory even in a VM it could be triggering a screen blank, and i've seen plenty of instances not in a VM where for various driver reasons bare metal won't recover from screen blanking , seems possible a VM might be subject to similar issues | 05:18 |
| systemdlete | bc, honestly, I have few ideas on how to proceed investigating this | 05:18 |
| gnarface | disabling 3d to see if it stops happening seems like as valid a deductive step as any of the others on the table so far | 05:18 |
| gnarface | disabling dpms likewise | 05:19 |
| systemdlete | ok, I'll disable 3D and restart it. If it still freezes again, I'l lremove the nvidiot card and try 3D again | 05:19 |
| gnarface | yea, removing the nvidia card or at least all the *nvidia* packages might also be valid tests | 05:20 |
| systemdlete | well, first let me try no-3D, with the nvidia card dormant in the box. | 05:20 |
| systemdlete | eliminate one thing at a time | 05:20 |
| systemdlete | here goes | 05:21 |
| systemdlete | all of my VMs on my other boxes running desktops are running without 3D, and I have not had this issue with them. However, the one that is running 3D is running mx-linux. Maybe they are configured differently. | 05:25 |
| systemdlete | (i hope that choice is not offensive!) | 05:26 |
| systemdlete | it was one of the OS's I chose years ago when the roof finally started caving in on centos and others | 05:26 |
| * systemdlete means when they went "dark" | 05:27 | |
| systemdlete | *all but one of... | 05:27 |
| systemdlete | gnarface, another factor, just remembered. I upgraded vbox on the testbox a few days ago to 7.0.18. 7.0.14 was stable enough, but then came 7.0.16 which had to be recalled due to some crashing problems in some instances. About 2 weeks later they released 7.0.18, and hesitantly, I installed it ONLY on the testbox just to make sure it was sane enough. | 05:30 |
| systemdlete | the other boxes are still on 7.0.14 at this point, so that could be a factor. | 05:31 |
| systemdlete | sorry for not mentioning this. | 05:31 |
| systemdlete | (and I know how much devuan folk love vbox... not! but I do) | 05:31 |
| systemdlete | this is the first problem release of vbox I've seen in a few years. | 05:32 |
| systemdlete | so apparently it is known that 3d can crash VMs. http://www.pjhutchison.org/virtual/virtualbox.html #19 | 05:38 |
| systemdlete | now I remember that vbox 3D is "experimental" (for how long now?) | 05:38 |
| systemdlete | so I think the key is to stay away from 3D until it has been vetted and blessed | 05:39 |
| systemdlete | thanks for your patience again, gnarface | 05:52 |
| gnarface | systemdlete: no problem | 05:53 |
| systemdlete | well, you did just give me a whole lot of your attention, so it is greatly appreciated | 05:53 |
| golinux | gnarface is legend!! | 06:25 |
| AEonFyr | Is there a way (script/config file) to get the debian release that a devuan release is based on? i.e. daedalus -> bookworm | 14:59 |
| fsmithred | add 7 | 15:00 |
| fsmithred | devuan+7=debian | 15:00 |
| fsmithred | devuan names go in alphabetical order, but that doesn't help compare them to debian names. | 15:01 |
| AEonFyr | I'm looking for something akin to lsb_release or /etc/os-release | 15:03 |
| AEonFyr | Let me explain... | 15:03 |
| AEonFyr | I'm installing docker from docker website, on daedalus the apt repo would be based on debian's bookworm, so I'm looking for a programmatic method to get "bookworm" from within daedalus. If that makes sense? | 15:05 |
| AEonFyr | Or "bullseye" from within chimaera for example. | 15:07 |
| fsmithred | yes, it makes sense. AEonFyr you can get the debian codename from /etc/debian-release or you can get the devuan release number from /etc/os-release and add 7 to it. | 15:14 |
| AEonFyr | hmm, I don't seem to have /etc/debian-release. I do have /etc/debian_version though. | 15:17 |
| fsmithred | oops. | 15:18 |
| fsmithred | you're right. | 15:18 |
| fsmithred | and that is exactly why I use tab-completion when I can. | 15:18 |
| AEonFyr | /etc/debian_version has the release number. Is there a similar file with the codename in it? | 15:25 |
| fsmithred | AEonFyr, debian_version has a number for stable relase but I see a name for testing (trixie/sid) | 15:42 |
| AEonFyr | ha ha, seems this is going to be trickier than I suspected :) If only debian project had an api where you could plug in the release number and get a codename back. But that would be too simple. :-D | 15:51 |
| djph | /etc/os-release? | 15:53 |
| AEonFyr | Unfortunately not, that file only contains Devuan details, with a nod to debian in ${ID_LIKE}. | 15:54 |
| AEonFyr | I might have to resort to scraping wikipedia's debian release page. omgl...I hope not. :) | 15:56 |
| fsmithred | Looks like you could hard-code your own list up to 14 (Forky) | 16:09 |
| AEonFyr | just for fun because apparently I have too much time on my hands (requires installation of html2text and curl) | 16:30 |
| AEonFyr | curl -fsSL https://en.wikipedia.org/wiki/Debian_version_history | grep "toc-Debian_`cat /etc/debian_version | awk -F '.' '{print $1}'`" | html2text | awk -F '[()]' '{print $2}' | tr '[:upper:]' '[:lower:]' | 16:30 |
| ted-ious | You don't want to convert it to text before grep'ing? | 16:35 |
| AEonFyr | using a plethora of little utilities to do something useful. take that systemd. ;-) | 16:36 |
| AEonFyr | ted-ious: I thought about that, but then I lose the html on which the grep is based. | 16:37 |
| ted-ious | Oh ok that's interesting. | 17:08 |
| fsmithred | Maybe the debian wiki page is easier to scrape | 17:14 |
| AEonFyr | Ok, because I started this, I should finish it. improved version scraping debian wiki page and incorporating lsb_release -r which should be more durable: curl -fsSL https://wiki.debian.org/DebianReleases | html2text | grep ^"`lsb_release -r | awk -F ':' '{printf("%d"),$2 + 7}'` " | awk '{print tolower($2)}' | 17:52 |
| AEonFyr | ymmv | 17:53 |
| AEonFyr | Thanks fsmithred | 17:56 |
| joerg | I'd suggest s/grep ^"/grep "^/ | 18:29 |
| AEonFyr | Done, thanks! | 18:40 |
| joerg | yet another cosmetic suggestion: I try to use $( ) instead of ` ` whenever I do sth "for the record" | 18:56 |
| joerg | I found I can read my own stuff more easily after a week or more, when I do | 18:59 |
| AEonFyr | fair point. after so many years, my fingers just automatically type ` ` whenever it comes to "execute this". old habits ;) | 19:11 |
| joerg | same here. I fix it on the review ;-) | 19:19 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
