SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
And how you explain the issues with the initial release of 255.4 (without ulterior patches) ?
I for one I believe that an explanation could be that this issue introduced by that patch is in fact the second one (but having a similar behavior) , as speculated by Zhao Lin there:
Just want to say thanks to all the folks who are in that bug report and are contributing good info. It makes the opensource community a better place.
I had spun up a Slackware-Live usb to pick away at the problem too but haven't had much time to contribute toward it. All I can note for now is that I've probed and monitored NetworkManager with the nmcli tool and noticed that after suspend it goes to sleep and never returns, where-as with the older elogind version on current it just works. Also NetworkManager's status after resuming from suspend still reports 'asleep'. (I'd post the cut and paste the nmcli status and whatnot from the terminal but that liveslack usb is at work and I'm at home, oops.)
My next thought was to look at the session dbus to see what's going on between elogind and NetworkManager, but it looks like ctrlaltca's already looked and confirmed there is no resume from sleep sent. Hopefully the code maintainer can figure out how to correct the behavior now that he has a place to check.
What'll come first, a 255.4-r4 upgrade, or a downgrade in elogind from Pat? ;-)
This branch is feeling a bit alpha to me, but we'll stick with it for now.
So then Pat:
a) doesn't use NetworkManager
b) doesn't suspend his -current machine(s)
c) thinks '/etc/rc.d/rc.networkmanager restart' for a while longer is fine
Always fun to figure out 'The Plan'.
For now my day-to-day laptop that runs current is going to keep elogind downgraded.
So then Pat:
a) doesn't use NetworkManager
b) doesn't suspend his -current machine(s)
c) thinks '/etc/rc.d/rc.networkmanager restart' for a while longer is fine
Always fun to figure out 'The Plan'.
For now my day-to-day laptop that runs current is going to keep elogind downgraded.
Or:
He uses a very stable version of Slackware, named 15.0 and only uses -current for what it's supposed to be: a development pre-release of the next stable
So then Pat:
a) doesn't use NetworkManager
b) doesn't suspend his -current machine(s)
c) thinks '/etc/rc.d/rc.networkmanager restart' for a while longer is fine
Always fun to figure out 'The Plan'.
For now my day-to-day laptop that runs current is going to keep elogind downgraded.
So then Pat:
a) doesn't use NetworkManager
b) doesn't suspend his -current machine(s)
c) thinks '/etc/rc.d/rc.networkmanager restart' for a while longer is fine
Always fun to figure out 'The Plan'.
For now my day-to-day laptop that runs current is going to keep elogind downgraded.
BTW, that (c) of yours does not always work. At least with my computers does NOT work at all. So, I do a nice reboot.
And, no offense intended but I believe that this suspend/hibernate seems kinda overrated. You can live well without ever suspending your computer.
Anyway, the suspend/hibernate never worked for me until recently - so far until rising of kernel 4.x
Last edited by LuckyCyborg; 04-17-2024 at 04:38 PM.
Or:
He uses a very stable version of Slackware, named 15.0 and only uses -current for what it's supposed to be: a development pre-release of the next stable
Indeed. I use 15.0 on my main rig as-well. I also maintain a number of SBo builds and use -current to test out what I can all upgrade for the next release to cut down on that work for when it happens. I'm well aware of the risks and happy to help out when I have time. It also helps to keep me up-to-date with Slackware development.
Quote:
Originally Posted by volkerdi
I'm suffering along with all of you, thanks.
My post was a bit of 'tongue in cheek' sarcasm, though that doesn't always translate via text. I realized afterward you've got this tied in with that libgudev upgrade and backing out now is going to be messier than just a simple downgrade of elogind. I'm sure its a headache for you as well. Looking forward to testing 255.4-r3!
Last edited by 0XBF; 04-18-2024 at 03:53 PM.
Reason: It should actually be r3. Lets hope we dont need r4
I was having trouble with suspend/wake since last week. I just got a new GPU card and thought I was running into a string of bad kernels or bad hardware turns out it was this little darn program causing me so much grief. After testing my new setup with Windows and seeing everything was working fine there I was ready to make a kernel bugzilla report. A slackpkg-upgrade and all is fine again mostly.
I'm now on polkit 252.23 & polkit-124, but I still have no 'poweroff' option in mate. I haven't bothered to test the screensaver. I presume it's a no-go.
Is there a way where I can do a mass downgrade with 'upgradepkg?' I still have current of 2024-03-24. I installed everything here except emacs, the Howtos & kde. I'm interested in trying a downgrade instead of an upgrade.
But rebuilding elogind failed for the lack of auditd, and polkit for the lack of duktape.h. If they're just compile time dependencies, fine. But if they're used in runtime, I could be making very tricky issues for myself.
Distribution: Slackware 64 -current multilib from AlienBob's LiveSlak MATE
Posts: 1,071
Rep:
Quote:
Originally Posted by business_kid
I'm now on polkit 252.23 & polkit-124, but I still have no 'poweroff' option in mate.
As mentioned earlier in this thread ( https://www.linuxquestions.org/quest...ml#post6496580 ), you have two options if you want to keep elogind-252.23:
- downgrade polkit to version 123, or
- rebuild polkit-124 with elogind-252.23 installed.
This because the polkit-124 in slackware -current repo was compiled after and thus against the elogind upgrade to v255.4.
Here's a probably almost clean workaround , waiting for the elogind bug to be fixed upstream.
All the best
/lib64/elogind/system-sleep/hook.sh
Code:
#!/bin/bash
# Copyright Jean-Philippe Guillemin <jpguillemin@sfr.fr>. This program is free software;
# you can redistribute it and/or modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version 2 of the License,
# or (at your option) any later version. Please take a look at http://www.gnu.org/copyleft/gpl.htm
case $1/$2 in
pre/*)
for i in $( bluetoothctl devices | cut -f2 -d " " ); do
bluetoothctl info "$i" | grep -q "Connected: yes" && bluetoothctl disconnect "$i" && echo "$i" > /tmp/.last-bt-device
done
;;
post/*)
if [ -e /tmp/.last-bt-device ]; then
bluetoothctl connect "$(cat /tmp/.last-bt-device)"
rm -f /tmp/.last-bt-device
fi
dbus-send --system --reply-timeout=120000 \
--type=method_call --dest='org.freedesktop.NetworkManager' \
'/org/freedesktop/NetworkManager' \
org.freedesktop.NetworkManager.Sleep boolean:false
;;
esac
But rebuilding elogind failed for the lack of auditd, and polkit for the lack of duktape.h. If they're just compile time dependencies, fine. But if they're used in runtime, I could be making very tricky issues for myself.
Both packages compile perfectly in a complete and updated installation of Slackware-current.
Please don't blame Slackware for the problems caused by the fact that you are using a partial installation.
Last edited by ZhaoLin1457; 04-19-2024 at 05:19 AM.
Here's a probably almost clean workaround , waiting for the elogind bug to be fixed upstream.
All the best
/lib64/elogind/system-sleep/hook.sh
Code:
#!/bin/bash
# Copyright Jean-Philippe Guillemin <jpguillemin@sfr.fr>. This program is free software;
# you can redistribute it and/or modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version 2 of the License,
# or (at your option) any later version. Please take a look at http://www.gnu.org/copyleft/gpl.htm
case $1/$2 in
pre/*)
for i in $( bluetoothctl devices | cut -f2 -d " " ); do
bluetoothctl info "$i" | grep -q "Connected: yes" && bluetoothctl disconnect "$i" && echo "$i" > /tmp/.last-bt-device
done
;;
post/*)
if [ -e /tmp/.last-bt-device ]; then
bluetoothctl connect "$(cat /tmp/.last-bt-device)"
rm -f /tmp/.last-bt-device
fi
dbus-send --system --reply-timeout=120000 \
--type=method_call --dest='org.freedesktop.NetworkManager' \
'/org/freedesktop/NetworkManager' \
org.freedesktop.NetworkManager.Sleep boolean:false
;;
esac
Now using elogingd 255 / pk124 here
I think there are other programs or services that need to be informed about the wake up. So we would need a broadcast call.
For example, pages opened by Firefox or Thunderbird will behave strangely, even if NetworkManager is restarted.
Distribution: Slackware 64 -current multilib from AlienBob's LiveSlak MATE
Posts: 1,071
Rep:
ZhaoLin1457 is right: even if the hook.sh script makes networkmanager to wake up and connect after resume, Thunderbird (if open when suspending) doesn't work properly after resume but needs restarting.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
