You are not logged in.
@alexkemp
The vt's have nothing to do with X, they are steady. The underlying process is a getty.
e.g. you can switch from X to vt3 with Alt-Ctrl-F3, but from a vt to vt3 with Alt-F3 (with or without Ctrl).
Another point of view is to see a vt as text console and a X as graphical console.
$ ps ax | grep getty
1781 tty1 Ss+ 0:00 /sbin/getty --noclear 38400 tty1
1782 tty2 Ss+ 0:00 /sbin/getty 38400 tty2
(...)
1786 tty6 Ss+ 0:00 /sbin/getty 38400 tty6
"I also still do not know which program is supplying the Alt-F7 command."
Good question - never crossed my mind - vt's were present as far as I can think.
root@chimaera:~# cat /etc/pihole/setupVars.conf PIHOLE_DNS_1=127.0.0.1#5335
I have the same line for PIHOLE_DNS_1. There is an unbound running on my machine, configured for port 5335 to resolve DNS (setup as described in https://forum.kuketz-blog.de/viewtopic.php?f=42&t=3067 (german)).
Did you try a "common" DNS server, like rbit suggested?
Or what is your local DNS resolver on port 5335 and is it working?
Has anyone here at Dev1 installed/run Pi-Hole?
I'm running a pi-hole on chimaera, installed before migration.
(beside the adaption of the changed network device name) no further issues so far, but I'm not frequently updating.
Seems too late to edit the previous post. The essence is:
To fix package nvidia-persistenced for apt do:
/etc/init.d/nvidia-persistenced stop && apt-get upgrade
EDIT / mostly deleted.
Network setup for migration seems to rely on network-manager and NOT dhcp, to circumvent the device name change to eth0.
10 minutes later ... But that is not true for rrq's migration script.
Now I'm confused. I'll go for migration in chroot and look for the network afterwards.
Hi,
Scribus from chimaera should work on daedalus too.
It should not hurt to have chimaera in source.list addionally. Someone disagrees? Any package will be superseeded by an existing daedalus package.
Then acpid it is.
Thanks for clarifying the matter.
EDIT: It's working - solved.
Hello,
after migration from bullseye to chimaera the power button stoped working - in terms of 'does not initiate system shut down'.
The usual suspect would be a *smart* deskop power manger, but there is no X. It is a headless mini-server on older Fujitsu hardware (consisting of AMD notebook components, fanless).
What can it be? A missing or unconfigured package through the update, acpi stuff, ...
Thanks in advance and regards.
Well, hell is on fire, I started having DNS problems and therefore can't do any actions with apt.
Your network device name has changed with the migration. In my case ist was form enp1s0 in bullseye to eth0 in chimaera.
Did you look at ' /etc/network/interfaces' ? Or you may find affected files with, e.g.:
grep -r enp1s /etc/*
EDIT: Of course, sometimes it's better to just start fresh.
Could you please post what pkgs you have installed for gkrellm including plug-ins?
$ dpkg -l | grep gkr | cut -c 5-21,44-55
gkrellkam 2.0.0-2
gkrellm 2.3.11-2
gkrellm-bfm 0.6.4-6.1
gkrellm-cpufreq 0.6.4-6.1
gkrellm-hdplop 0.9.11-3
gkrellm-reminder 2.0.0-3.1
gkrellm-tz 0.8-2+b1
gkrellmoon 0.6-7
gkrellshoot 0.4.4-3
gkrelltop 2.2.13-1.1
$ cat .gkrellm2/plugin_enable
gkrellmoon.so
gkrellm looks comparabele to your screenshot. Pressing shift-pgup/down does no harm, as fsmithred reported.
Disabled are email and non-existing sensors. "Krell and LED updates per second" is set to 1. Program start-up took 2-4 seconds.
Maybe something in 'user-config'? - It has 144 lines, so just 22 for now.
Anything else that might help debugging?
$ head -22 .gkrellm2/user-config
### GKrellM user config. Auto written, do not edit (usually) ###
### Version 2.3.11 ###
enable_hostname 1
hostname_short 0
enable_sysname 0
mbmon_port 0
sticky_state 0
dock_type 0
decorated 0
skip_taskbar 0
skip_pager 0
above 0
below 0
track_gtk_theme_name 0
default_track_theme "Default"
save_position 0
chart_width 125
update_HZ 1
allow_multiple_instances 0
float_factor 1000
hostname sysname_mode 1
clock_cal clock_launch
No error on my daedalus box. Maybe the package works for chimaera too?
Nice transparent theme.
Thanks Head_on_a_Stick!
I have multiarch enabled and apt wants to install pulsaudio:i386.
$ sudo apt-get -s install pulseaudio
(...)
Note, selecting 'pulseaudio:i386' instead of 'pulseaudio'
The following additional packages will be installed:
libaudit1:i386 (...) pulseaudio-utils:i386 rtkit:i386
Is there a variant for multiarch?
Hello,
it is a daedalus installation with the 470-nvidia-driver (470.129.06-6).
The driver finally seems to work, but the "nvidia-persistanced" error remained.
---------
edit / update: replicated installation, error and fix
Problem: apt does not 'fully install' nvidia-persistanced.
But: It will succeed, if nvidia-persistanced is not running.
$ /etc/init.d/nvidia-persistenced stop
$ apt-get upgrade
And apt should be happy again.
---------
I leave the original post below, since it was posted and happend so on my box.
By now, I think I must have stoped the daemaon sometimes and forget about it.
end edit / update
----------
The following solved it in my case:
$ sudo rm /var/run/nvidia-persistenced/nvidia-persistenced.pid
$ sudo rm /var/run/nvidia-persistenced/socket
fixed it and
$ sudo apt-get upgrade
then succeeded in finalising the post-install-script and starting nvidia-persistanced.
Done.
Some remarks:
Probably, it is a good idea to gzip or move both files instead of deleting them.
It took some time to notice that it is just a daemon, that did not start.
$ /etc/init.d/nvidia-persistanced start
gave an error message respective a pid-file. Messing around with it may or may not result in other hints, if the above does not work.
apt insists to start the daemon by itself, so if you managed to start the daemon, you have to stop it before doing "apt-get upgrade".
Hope this is helpful.
Regards