| nsprra | devuan dist-upgrade nuked usr/share/fonts/X11/ back that up before upgrading | 00:46 |
|---|---|---|
| nsprra | ok force-reinstalling xfonts-100dpi and xfonts-75dpi seems to fix | 00:48 |
| nsprra | The following packages have unmet dependencies: libelogind-compat : Conflicts: libsystemd0 | 01:23 |
| nsprra | we don't want libsystemd0, do we? | 01:23 |
| nsprra | removing libelogind-compat removes a ton of packages includer xserver-xorg-core | 01:24 |
| nsprra | what's the least broken session provider? elogind or seatd? | 01:25 |
| nsprra | yeah seatd is less broken | 01:28 |
| nsprra | poettering is the Karl Marx of open source | 02:54 |
| nsprra | https://sysdfree.wordpress.com/2023/07/08/372/ and whoever at gnome is raping us with libgudev | 03:51 |
| gnarface | i thought you should be able to replace libsystemd0 with libelogind0 | 03:51 |
| nsprra | apt purge libsystemd0 removes a tonn of packages | 03:52 |
| nsprra | but i'll do it | 03:52 |
| gnarface | well you should be able to put them right back once libelogind0 is there instead | 03:52 |
| rrq | do apt-get install libelogind0 libsystemd0- | 03:52 |
| gnarface | nsprra: yea, do this ^ | 03:53 |
| nsprra | too late but none of that stuff is essential | 03:53 |
| nsprra | idk how libsystemd0 snuck in again | 03:54 |
| nsprra | i had libelogind0 installed | 03:55 |
| gnarface | hard to say, but it might help in general to use --no-install-recommends | 03:55 |
| nsprra | ty! | 03:55 |
| nsprra | now initramfs-tools is failing with patched libeudev hrm | 03:57 |
| bb|hcb | nsprra: FWIW the fix for eudev vs libgudev is already in the Devuan eudev... | 03:57 |
| nsprra | ceres/main libeudev1 arm64 3.2.12-4 ? | 03:58 |
| gnarface | nsprra: do you have udev or eudev installed? | 04:02 |
| nsprra | yes, both | 04:04 |
| nsprra | libudev1 Version: 1:3.2.9+devuan4 | 04:05 |
| gnarface | not lib | 04:05 |
| gnarface | just udev or eudev | 04:05 |
| nsprra | udev is installed Version: 1:3.2.9+devuan4 | 04:05 |
| nsprra | eudev is installed Version: 3.2.12-4 | 04:05 |
| gnarface | maybe you're seeing something new broken in ceres, it's always possible | 04:06 |
| nsprra | should i not have both installed? | 04:06 |
| gnarface | uh, you should only have had one or the other before, but i'm looking at it now and it looks like udev is now a transitional package for eudev, so nevermind that i guess | 04:06 |
| nsprra | maybe i apt install eudev udev- | 04:07 |
| gnarface | worth a try | 04:07 |
| bb|hcb | udev and libudev1 packages are transitional and may be removed... | 04:09 |
| bb|hcb | eudev 3.2.12-4 is the latest | 04:09 |
| nsprra | wayfire needs libseat. libseat pulls in libsystemd0 | 04:11 |
| brocashelm | i don't have any packages with "systemd" in the name (not even libsystemd0) | 04:12 |
| bb|hcb | libsystemd0 is not banned, should be safe to have it installed, no matter how bad that sounds... | 04:12 |
| brocashelm | i blacklisted all *systemd* packages (by wildcards) | 04:12 |
| brocashelm | i got libseat installed, regardless | 04:13 |
| bb|hcb | that is an option, but some stuff is linked to libsystemd0 and will become uninstallable in this way | 04:13 |
| nsprra | wayfire needs a session provider systemd or elogind or seatd. which causes least systemd problems? | 04:13 |
| brocashelm | yeah, i know, but i haven't had any compatibility problems since | 04:14 |
| brocashelm | i can install wayfire if i wanted to, without any libsystemd0 | 04:14 |
| brocashelm | i just tested a prompt and all green lights | 04:14 |
| brocashelm | even cmus is installed without a single *systemd*-named package | 04:14 |
| brocashelm | but yes, libelogind is what a lot of these fall back on | 04:15 |
| nsprra | it's not a reccommends libseat1 requires libsystemd0 | 04:15 |
| bb|hcb | "apt install wayfire" gives The following additional packages will be installed: libseat1 libwf-config1 libwf-utils0 libwlroots11 libxcb-composite0 libxcb-res0 | 04:15 |
| nsprra | The following NEW packages will be installed: libseat1 libsystemd0 | 04:16 |
| nsprra | libsystemd pulls in the broken libgudev | 04:16 |
| rrq | note that libelogind0 provides libsystemd0, but apt doesn't realize that until libelogind0 is installed | 04:17 |
| bb|hcb | I am testing on ceres. Are you on daedalus? | 04:17 |
| nsprra | ceres | 04:17 |
| nsprra | how can i blacklist libsystemd0 so it is pretended to be installed? | 04:17 |
| brocashelm | i've been on ceres for the past year and never had this conflict | 04:17 |
| brocashelm | nsprra: through apt-pinning libsystemd0 with -1 priority | 04:18 |
| brocashelm | wait... pretended to be installed? | 04:18 |
| nsprra | well libseat needs libsystemd0 | 04:19 |
| brocashelm | right | 04:19 |
| nsprra | and you say you dont get libsystemd0 | 04:19 |
| brocashelm | i was somehow able to dodge that completely | 04:19 |
| brocashelm | i might've removed libsystemd0 afterwards without any complaints | 04:20 |
| bb|hcb | rrq: I do not see that provides? | 04:20 |
| brocashelm | same | 04:20 |
| rrq | so it's changed? there is a libelogind0-compat or something? | 04:21 |
| brocashelm | i'm on daedalus, btw | 04:21 |
| brocashelm | no provides; just depends (libc6 and libcap2) | 04:21 |
| bb|hcb | Yes, right. libelogind-compat provides libsystemd0... nsprra: install that and you should be good | 04:22 |
| bb|hcb | And as a note, eudev 3.2.12-4 does not have the nasty problem with the new libgudev | 04:24 |
| nsprra | thanks bb|hcb | 04:30 |
| nsprra | wayfire: /lib/aarch64-linux-gnu/libudev.so.1: version `LIBUDEV_247' not found (required by /lib/aarch64-linux-gnu/libgudev-1.0.so.0) | 04:34 |
| bb|hcb | Ugh, I do not have ceres on arm64 to check... Most probably it is the same on amd64? | 04:35 |
| nsprra | i still had libudev1 installed | 04:35 |
| nsprra | purged libudev1* | 04:35 |
| bb|hcb | That is an empty package, it only helps converting from Debian to replace udev/libudev with eudev/libeudev. | 04:37 |
| nsprra | alright got past the error thanks | 04:41 |
| bb|hcb | Can you run these two: | 04:41 |
| bb|hcb | objdump -T /usr/lib/x86_64-linux-gnu/libgudev-1.0.so.0|grep UDEV_247 | 04:41 |
| bb|hcb | objdump -T /lib/x86_64-linux-gnu/libudev.so.1 | grep udev_device_get_current_tags_list_entry | 04:41 |
| nsprra | objdump -T /usr/lib/x86_64-linux-gnu/libgudev-1.0.so.0.3.0 |grep UDEV_247 returns nothing | 04:42 |
| nsprra | objdump -T /lib/x86_64-linux-gnu/libudev.so.1 | grep udev_device_get_current_tags_list_entry returns nothing | 04:43 |
| bb|hcb | What are the versions of libeudev1 and libgudev-1.0-0? | 04:44 |
| nsprra | patched from forum | 04:46 |
| nsprra | then replaced with new ceres. Version: 3.2.12-4 | 04:47 |
| nsprra | Package: libgudev-1.0-0 Version: 238-2 | 04:47 |
| bb|hcb | Maybe above commands didn't show anything because x86_64-linux-gnu should be replaced with aarch64-linux-gnu for your system | 04:48 |
| nsprra | i have multiarch :) 166136 May 16 17:32 /lib/x86_64-linux-gnu/libudev.so.1.6.3 | 04:51 |
| nsprra | but yes, thanks. i didn't catch it | 04:51 |
| bb|hcb | objdump -T will list all symbols - both the provided ones and the ones that are required from other libs. The point is that both should have udev_device_get_current_tags_list_entry tagged with LIBUDEV_247. The exported one is .text and the imported one is *UND* | 04:53 |
| nsprra | objdump -T /usr/lib/aarch64-linux-gnu/libgudev-1.0.so.0.3.0 |grep UDEV_2 | 04:54 |
| nsprra | 0000000000000000 DF *UND* 0000000000000000 (LIBUDEV_247) udev_device_get_current_tags_list_entry | 04:54 |
| nsprra | objdump -T /usr/lib/aarch64-linux-gnu/libudev.so.1 |grep udev_device_get_curr | 04:55 |
| nsprra | 000000000000a1b0 g DF .text 0000000000000008 LIBUDEV_247 udev_device_get_current_tags_list_entry | 04:55 |
| bb|hcb | That looks good | 04:56 |
| nsprra | i might be able to startx now | 04:56 |
| nsprra | whatever was done with 'session providers' i don't like it. we didn't need this in the 90s, didn't need this in the 00s. | 04:57 |
| nsprra | there's a lot of corruption | 04:58 |
| bb|hcb | Desktop have become a muddy swamp. With frogs. And they all croak ;) | 04:59 |
| onefang | Some of them don't croak quickly enough. | 05:03 |
| nsprra | unw_get_proc_info failed: unsupported operation or bad value [-8] | 06:12 |
| nsprra | bad news with Xorg | 06:13 |
| nsprra | update-initramfs -k all -u -v has a problem with eudev | 06:24 |
| nsprra | E: /usr/share/initramfs-tools/hooks/udev failed with return 1 | 06:24 |
| nsprra | ssh force installs elogind, so now i have seatd and elogind | 09:19 |
| nsprra | get rid of all session managers and whoever invented them | 09:22 |
| nsprra | dpkg: error processing package initramfs-tools (--configure): | 09:53 |
| nsprra | who caused this swath of destruction? | 09:54 |
| cws6969 | Can Somebody Help Me , https://dev1galaxy.org/viewtopic.php?pid=44623#p44623 | 10:13 |
| gnarface | nsprra: you on unstable? might just be normal business as usual. i don't think ssh requires elogind, that might be because you didn't disable recommends. | 10:26 |
| gnarface | cws6969: unfortunately this isn't a lot to go on, that type of failure is usually power management or video driver related, but it could even happen from hardware failure or running out of swap (or not having any) | 10:29 |
| gnarface | cws6969: the first step would be to try to figure out by deduction whether one of those programs is specifically causing it, or the system could fail this way just idle | 10:30 |
| cws6969 | os is Daedalus 5.0 stable | 10:31 |
| gnarface | (may also be heat or power supply related) | 10:31 |
| gnarface | it could be a lot of things, really | 10:31 |
| gnarface | you have swap, right? | 10:32 |
| cws6969 | yes sda2 8:2 0 5.9G 0 part [SWAP] | 10:33 |
| gnarface | one thing you could do is keep an eye out for it filling up right before the lockup | 10:33 |
| gnarface | another thing you could do is see if it's related to the computer or even just the display going to sleep then failing to wake up | 10:34 |
| cws6969 | I can't find the cause at the moment. I'm going to change the operating system (mx-linux or Antix) , and if the problem persists, it could be a hardware failure | 10:38 |
| DelTomix | nothing in the provided logs looks like its related to a crash or failure - unless the logs don't cover the specific time of the failure. By the description I would suspect thermal issue, overclocking, something along that line. | 10:38 |
| cws6969 | The system never sleeps | 10:39 |
| cws6969 | The selected log is at the time of the system crash | 10:42 |
| cws6969 | Thank you for talking to me about it | 10:44 |
| cws6969 | My System crashed again. I rebooted again | 10:51 |
| gnarface | cws6969: could be the power supply | 10:59 |
| gnarface | if it were bad ram, i'd expect some visual anomalies or random segfaults | 10:59 |
| gnarface | reliably only ever locking up with a black screen, that's something i'd usually expect out of a video software problem or a power hardware problem | 11:00 |
| gnarface | overheating could do it too, but i'd also typically expect some segfaults then | 11:01 |
| gnarface | or some warnings in the error logs abotu overheating | 11:01 |
| gnarface | but i guess that could depend on the generation of the hardware | 11:01 |
| gnarface | (and whether you'd suppressed such errors if you were overclocking anyway) | 11:01 |
| cws6969 | no suppressed | 11:02 |
| gnarface | i do have one piece of hardware that exhibits this problem if i don't disable dpms | 11:03 |
| gnarface | but that's a known driver issue | 11:03 |
| gnarface | and ARM hardware | 11:03 |
| gnarface | probably not related, but disabling dpms would be something else you could try just in case | 11:04 |
| DelTomix | myself - almost any time I've ever experienced memory/thermal/overclock/hardware issues I've never seen a segfault or warning, just a sudden, silent freeze. Also if dpms the kernel usually manages to eek out a failure message | 11:04 |
| nethead23 | Probably not relevant but i had my Linux Mint 21 Desktop regulary freezing until a couple of days ago. The desktop would mostly freeeze for a couple of seconds but sometimes completely requiring a restart of the X server. Since i did an "apt-get update/upgrade" a couple of days ago its gone... | 11:34 |
| nethead23 | Error log showed this for about a year: Sep 9 20:48:30 colossus kernel: [1052076.425433] Asynchronous wait on fence NVIDIA:nvidia.prime:6bbc96 timed out (hint:intel_atomic_commit_ready [i915]) | 11:40 |
| nethead23 | Sep 9 22:24:13 colossus kernel: [1057819.669136] i915 0000:00:02.0: [drm] *ERROR* Atomic update failure on pipe B (start=33038819 end=33038820) time 273 us, min 1073, max 1079, scanline start 1069, end 1088 | 11:40 |
| nethead23 | Sep 9 23:37:13 colossus kernel: [1062199.782654] i915 0000:00:02.0: [drm] *ERROR* Atomic update failure on pipe B (start=33301625 end=33301626) time 289 us, min 1073, max 1079, scanline start 1065, end 1084 | 11:40 |
| gnarface | yea, it's actually a problem i've seen a lot with nvidia drivers | 12:30 |
| Xenguy | "Fuck you, nvidia!" | 12:33 |
| gnarface | i'm lead to believe it's actually an array of different, repeating problems, but the symptoms are all surprisingly similar | 12:35 |
| gnarface | that said, the thing about it being a possible heat issue isn't necessarily a mutually exclusive thing here, and it's a good idea to add temperatures to the log too | 12:36 |
| gnarface | there might be some pattern in temperature or memory/swap usage that appears | 12:37 |
| gnarface | cpu load too | 12:37 |
| FlibberTGibbet | This here Devuan 5 is really pretty good... | 21:25 |
| golinux | FlibberTGibbet: Long time no see! | 21:38 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!