You are not logged in.
bluetoothd version 5.62 maybe needs to be debugged and repaired.
Yeah, maybe. Some of these bugs go back to 2009. I can't tell from this page if they're unfixed or if they just don't ever close their bug reports.
https://bugs.debian.org/cgi-bin/pkgrepo … kage=bluez
Thanks for the info. Someone else may run into the same problem.
The *.d directories are a place for the administrator to put customized configurations that will not be wiped out if a new version of the config file is installed/upgraded. Something is programmed to check for files in that directory, and it's letting you know that there's nothing there.
It should be safe to ignore. I don't have that directory on my chimaera or daedalus installations.
My syslog looks like #2. It seems that a lot of my entries for going into sleep have the same timestamp as the entries coming out of sleep. Not sure what to make of that. Or of your #3 paste.
During my testing, I did have occasion to not wake up from sleep. I had other problems after reboot, like not being able to drop to console with ctrl-alt-F2. I ran fsck from another system on the same machine and it fixed some orphaned inodes. That's probably not your problem, but might be worth trying fsck from a live-usb.
Have you tried running loginctl suspend to see if it acts differently? On mine it does the same as pm-suspend.
There's no metapackage for backports kernels like there is for the main kernel. The only updates you would get would be if the kernel version didn't change. I don't know if that happens with backports kernels.
Thanks, nili. I should remember to search the page for words. 7G is more than enough, assuming it's all working.
The only time I ever had a cpu running at 11C was with the computer on a hardwood floor, in the winter with sub-freezing temperatures, and the windows in the apartment below me were open. My floor was very cold.
I vote for staying in this thread. These things may all be related, and someone else might run into similar problems.
Is it a laptop? (Do we need to deal with lid switch and power-manager?)
Look in /var/log/pm-suspend.log to see information related to entering and leaving suspend state.
Look in /var/log/syslog for info about leaving suspend state. Find where it says PM: suspend entry (deep) to see what's happening when you leave suspend. I could not find anytihing in syslog to show when it went into suspend. (And I started with an empty syslog, so there's no way I missed it.)
How much memory does it have? If it's in the inxi output, I'm missing it.
There's a big difference in mem requirements between jessie and chimaera. It keeps going up with each release. Run memtest86+ overnight to see if there's bad RAM.
If you're still having trouble with suspend after you get the packages all straightened out, you might take a look at this page: https://wiki.ubuntu.com/DebuggingKernelSuspend
Someone in IRC gave me the link. I haven't had a chance to read it, and I will be busy with other things today.
consolekit and libpolkit-gobject-consolekit-1-0 should get removed when you install elogind and libpam-elogind. And libpolkit-gobject-elogind-1-0 will be installed automatically.
If you use apt or apt-get to install elogind and the others, it will put a lot of packages on the autoremove list, but it won't actually remove them. I'm pretty sure once you do that and libelogind0 is in the system, those packages will be taken off the autoremove list.
To see the autoremove list without removing anything.
apt -s autoremove
If it doesn't clear after libelogind0 is installed, you can reinstall consolekit, libpam-ck-connector and libelogind0. Then we can talk about setting up sudo for only shutdown/reboot.
If you use aptitude to install, then the packages will be automatically removed during the install. Don't do that here.
If that's the output of apt-get install libelogind0 then I have no idea what's going on. That should not happen. Try installing all at once and see if that works better.
apt install elogind libpam-elogind libelogind0
or maybe
aptitude install elogind libpam-elogind libelogind0
and see if aptitude gives you some other solutions.
I'm glad you waited. Install libelogind0 first to replace libsystemd0, and that should prevent all those removals from happening. Then install elogind and the others.
I assume you're already rebooted at least once since the upgrade. If not, try that first.
There might be a way to get it to work with consolekit, but I don't know what to tell you to do that. What I would do is install elogind and libpam-elogind and let apt remove consolekit and libpam-ck-connector.
Post the output of the following command to check what's installed:
dpkg -l | egrep "logind|consolekit|libpam|policykit|polkit|upower"
What commands did you use to upgrade?
Do you have chimaera, chimaera-security and chimaera-updates all enabled in sources.list (or in synaptic)?
Yes, that's the section for Accessibility features. And the way it's written does sound weird to me. I haven't looked to see if similar wording is used upstream. Thanks for pointing it out.
Sounds like something went wrong in the install. Make sure policykit-1-gnome elogind and libpam-elogind are installed.
The default display manager with xfce is still slim.
How are you looking for it that you can't find it?
In my daedalus install, /etc/debian_version says "bookworm/sid". I think they switch to numbers when it goes stable, so it shows which point-release you are at.
I am unable to reproduce the problem. I just upgraded my daedalus with runit. The dbus version went from 1.12.something+devuan3 to 1.14.0-1devuan1, and my desktop still comes up after a reboot. Looks like it's all working ok.
This line is still present in the runscript:
exec chpst -umessagebus dbus-daemon --system --nofork --nopidfile
Running xfce with lightdm here. What would you like me to check?
Yes, this could be avoided in packaging, but I doubt you can change the debian devs on this. And nobody around here is going to fork the kernel. (that's my prediction)
You can avoid that and a lot of other cruft with this:
cat /etc/apt/apt.conf.d/00norecommends
APT::Install-Recommends "no";
I don't know if adding '--no-install-recommends' will work with 'apt upgrade'. If so, that's another way to avoid it.
In debian/devuan, if the package includes runit scripts, runit will use those instead of the sysvinit scripts. Only a few packages include the runit scripts - the gettys, openssh-server and maybe a few others. You can add runscripts from other sources. (salsa.debian.org, antix, more)
Here are two more discussions.
https://dev1galaxy.org/viewtopic.php?id=4342
https://dev1galaxy.org/viewtopic.php?id=3716
I get leftover directories in /media occasionally and have one now. Looks like it's from pmount. I can't be sure if pmount made the error or if I did it by forgetting to pumount before unplugging the device or maybe by unmounting it as root. I just delete the leftovers when I find them.
With no removable media plugged in:
ls -la /media/sde2/
total 8
drwxr-xr-x 2 root root 4096 Apr 22 2021 .
drwxr-xr-x 4 root root 4096 Jan 12 16:36 ..
-rw------- 1 root root 0 Apr 22 2021 .created_by_pmount
Interesting observation. I see that the run script for network-manager starts dbus first, and the one for lightdm starts dbus and elogind. So I guess if you write a new run script, you have to make sure you start anything that's needed first. It doesn't seem to be a problem that multiple scripts have 'sv start dbus' in them.
I think the obvious answer for now is that you gotta try it. See if you can break avahi and then fix it by editing /lib/runit/run_sysv_scripts to use /etc/service instead of /etc/sv.
There's also the pool1 iso (DVD) that has 5000 packages. That's in addition to the dvd installer iso. If those two isos don't have what you want, you could get the debian isos and carefully pull packages from there. That should work for anything that doesn't depend on systemd (directly or indirectly).
Great, I will research more about runit. Could also explain how sysvinit service management works?
No, I can't, and in my limited understanding, I thought sysvinit did not do service management, and that's why distros switched to a different init system.
I know this much:
service <service-name> start|stop|restart
or
/etc/init.d/<service-name> start|stop|restart
If you install runit, you only get run scripts for the gettys, and also for openssh-server if you install that. No setup or linking is needed.
There are run scripts available from a couple of locations outside the repository. They can be added after the install. Basic procedure is to copy the script dir for a service to /etc/sv/, stop the init script, and then run
update-service --add /etc/sv/<service>
Where <service> is the name of the run script directory and is the same name as the init script.