You are not logged in.
Refractainstaller has supported full disk encryption for at least a couple of years. Select encryption for the root partition and do not select a separate /boot partition.
Glad you got it fixed. For future reference, those GDBus errors complaining about missing .service files are just noise from programs that expect you to be running systemd, even though they may not require it. I see them often when I start programs from a terminal.
Have you tried logging out of the desktop and then log in again? I've deleted my panel a few times by accident. It always comes back on login.
If you're in the middle of something and can't log out, run xfce4-panel from the Run dialogue or from a terminal. You can get a Run dialogue with alt-F2.
The watermark is barely visible in the gray field. It's the round peppermint candy. (And now I want one. Or a candy cane, but they're all gone.)
I got a brief answer from Jaromil: "yes why not"
What does the logo for the debian build look like? I tried to find it, but failed. Or maybe the examples I saw were too small.
I bumped the request up to our traveling guru at dyne.org. Be patient. He moves faster than email.
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.