You are not logged in.
Indeed. It may however be helpful (albeit not essential), but it seems only on machines/servers that don't run X persistently.
"Under Linux systems where X runs by default on the target GPU the kernel mode driver will generally be initalized and kept alive from machine startup to shutdown, courtesy of the X process. On headless systems or situations where no long-lived X-like client maintains a handle to the target GPU, the kernel mode driver will initilize and deinitialize the target GPU each time a target GPU application starts and stops. In HPC environments this situation is quite common. Since it is often desirable to keep the GPU initialized in these cases, .. "
nvidia-persistenced has no real purpose unless you want to use CUDA.
If you don't need CUDA then you can just delete it, nvidia works fine without it.
There was (is still?) a bug in the code that dates back to 2014 that can lead to it not initialising properly.
See my post dating back to April 2020.
So what are common Devuan users to do? Starting up ntp fails again (sudo service ntp start), even though the clock somehow updated automatically much later during this same session!
I use chrony. It seems to work reliably.
https://chrony-project.org/comparison.html
NB. the comparisons shown on this page are with ntp not with ntpsec.
I made a desktop choice at installation. That i remember. Which one, i don't :-)
I'm gonna check it out, i'll let you know if it worked for further generations who stumble upon this post.
If you have Cinnamon then there an option Menu>Preferences>System Info that will tell you about your system.
Also in a console/terminal you can run neofetch, or for absolutely everything inxi -F (if not already installed both come in packages with the same names).
On my system neofetch provides this:
marjorie@grendel:~$ neofetch
..,,;;;::;,.. marjorie@grendel
`':ddd;:,. ----------------
`'dPPd:,. OS: Devuan GNU/Linux 5 (daedalus) x86_64
`:b$$b`. Host: MS-7C56 1.0
'P$$$d` Kernel: 6.1.0-11-amd64
.$$$$$` Uptime: 1 day, 15 hours, 59 mins
;$$$$$P Packages: 2892 (dpkg)
.:P$$$$$$` Shell: bash 5.2.15
.,:b$$$$$$$;' Resolution: 1920x1200
.,:dP$$$$$$$$b:' DE: Cinnamon 5.6.8
.,:;db$$$$$$$$$$Pd'` WM: Mutter (Muffin)
,db$$$$$$$$$$$$$$b:'` WM Theme: Blue-mint (Menta)
:$$$$$$$$$$$$b:'` Theme: TraditionalGreen [GTK2/3]
`$$$$$bd:''` Icons: menta [GTK2/3]
`'''` Terminal: gnome-terminal
CPU: AMD Ryzen 5 5600G with Radeon Graphics (12) @ 3.900GHz
GPU: AMD ATI Radeon Vega Series / Radeon Vega Mobile Series
Memory: 5729MiB / 13876MiB You can certainly do it from Bullseye (11) to Chimaera (4).
The instructions are here:
https://www.devuan.org/os/documentation … o-chimaera
The instructions you quote for Stretch (10) to Beowulf (3) are the 'official' Devuan instructions.
https://www.devuan.org/os/documentation … to-beowulf
and should also still work, at least on bare metal, as the source and destinations systems are both essentially frozen.
This does assume that the repositories are still there: Beowulf is now quite old.
If you coming from Bullseye (or earlier) you can convert that and then upgrade to Daedalus: although the upgrade process to Daedalus hasn't yet been formally documented several of us have done it and reported back to the Forum as to how we did it. It's pretty straightforward.
As to converting from Bookworm to Daedalus there aren't as yet any instructions for this on the Devuan site.
I have seem some discussion of the issues on the Devuan DNG list and it doesn't seem quite as straightforward if systemd is already installed (as you seem to have found).
The problem seems to be with removing systemd at Pid 1, and not locking the system.
Others more involved than me may be able to better answer how, if at all, this can be done.
And if it is possible then no doubt the instructions on how to do it will be published when Daedalus goes live.
Just surmising that there's no one here who:
1) has chosen Gnome as their DM and
2) has an Nvidia graphics card and
3) has chosen to try Wayland and has got it working successfully.
On your second point nvidia-persistenced has no real purpose unless you want to use CUDA.
If you don't need CUDA then you can just delete it, nvidia works fine without it.
There was (is still?) a bug in the code that dates back to 2014 that can lead to it not initialising properly. Nothing to do with systemd, just poor code.
See my post dating back to April 2020.
Bookworm is now on version 12.1 which is usually taken as a sign that initial bugs have been sorted and sysadmins. can safely upgrade.
So I would expect Daedalus, which exactly the same packages as Bookworm in most cases should equally be ready, apart from the installation isos which are still being tested.
Most security updates appear on Daedalus as soon as they appear on Bookworm since Devuan merges Bookworm packages with the very limited number of 'devuan modified' packages. For example the Zenbleed AMD firmware patch appeared very quickly.
For myself, having upgraded my desk PC from Chimaera to Daedalus a few weeks ago without issue I've now upgraded my two others machines, one a mail server and all seems good.
I'm not affected personally as my AMD 5600G is Zen3 not Zen2,
Nevertheless a AMD-microcode fix for Chimaera, Daedalus and Unstable landed this morning as a security update.
However as the end of that security-tracker (https://security-tracker.debian.org/tra … 2023-20593) it says:
3.20230719.1 ships the first batch of fixes, only for 2nd gen Epyc CPUs, further
CPUs to follow in later releases
This is the one we have now got. Epyc is a database CPU.
So there are still fixes to come for the other Zen2 (Ryzen) CPUs which aren't fixed yet.
More info here:
https://web.archive.org/web/20230724143 … bleed.html
If you haven't got the microcode fix there is a workaround mentioned in this article:
Workaround
It is highly recommended to use the microcode update.
If you can’t apply the update for some reason, there is a software workaround: you can set the chicken bit DE_CFG[9].
This may have some performance cost.
Linux
You can use msr-tools to set the chicken bit on all cores, like this:
# wrmsr -a 0xc0011029 $(($(rdmsr -c 0xc0011029) | (1<<9)))
Yesterday I upgraded from Chimaera to Daedalus without any issues. Here are the steps I followed:
Edit /etc/apt/sources.list to point to daedalus $ sudo apt-get update $ sudo apt-get upgrade $ sudo apt-get dist-upgrade # at the end there are some errors having to do with old version of linux kernel $ sudo apt-get autoremove --purge # this removes the packages that caused errors $ sudo apt-get dist-upgrade # now it completes without any errors $ sudo apt-get autoclean Reboot
I'm assume that we will be providing a note on how to upgrade as well as how to install from new and how to convert from Debian.
So I thought it might be useful to document my experience and any trip hazards I encountered.
I upgraded just over a week ago, using the same steps as described above.
Where it asked about if I wanted to accept new default config files I chose to keep those I already had.
I was already using the most recent backported 6.1 kernel prior to the upgrade.
A simple replace edit of sources list is however not entirely sufficient as you should add the 'non-free firmware' to each line.
With that change I had no problems in the upgrade as such.
I use unattended-upgrades to install any security package updates daily.
I had to change the line "o=Devuan,n=chimaera-security" to "o=Devuan,n=daedalus-security" in /etc/apt/apt.conf.d/50unattended-upgrades.
My motherboard (a MSI B550) use a custom chip to monitor fan speeds in particular.
There is a corresponding kernel module but it was not loaded. I ran
sudo modprobe nct6687.koto load it and then sensors could see it.
Grub no longer runs osprober by default. If you have been using it to create grub menu items to boot to alternative OS on your machine you will need to as root restore it in the file /etc/default/grub by un-commenting the line
#GRUB_DISABLE_OS_PROBER=falseand then run update-grub as root.
Also relating to grub the menu on my PC now works with my usb keyboard (it didn't on Chimaera).
rsyslog creates fewer log files, such as /var/log/mail.{info,warn,err}. The messages are still there in /var/log/mail.log.
If you have another program reading any of these, e.g. fail2ban, you will need to get it to read /var/log/mail.log instead.
Similarly /var/log/{messages,debug,daemon.log} are also no longer being updated. Their messages are still there in /var/log/syslog.
All these (and their log-rotated counterparts) can now be removed.
Logrotate itself is working as expected on my PC.
Just for info. I run Cinnamon. After the upgrade Gnome programs (such as Evolution and System Monitor) now duplicate the Max/Min/Close symbols and Title that are in the Window Title Bar in the top line of the program. Nothing fatal but it looks odd.
There are some changes in Bookworm (and hence Daedelus) that don't affect my PC but might others e.g. the packages that set the system clock and reduced accessibility support.
Changes to Bookworm (and by default Daedulus) are covered in the release notes' Chapter 5 Issues to be aware of for bookworm https://www.debian.org/releases/bookwor … on.en.html
I upgraded to Daedalus two day ago.
I use dnscrypt-proxy. It was previously running on Chimaera.
The package version installed and running is 2.0.45+ds1-1+devuan1
So clearly a Devuan compliant version.
There are a number of packages in Debian that have had to be modified to run without systemd. I assume that this is one of them.
From the user Desktop (I use Cinnamon) Synaptic is authorised to open a root graphics session (gtk) through pkexec (which is what pops up the authorisation requester) and behind that is polkit.
Might be worth having a look in /var/log/auth.log to see if it's throwing errors.
On my PC a recent synaptic session was logged in /var/log/auth.log like this:
Jul 3 17:33:18 grendel polkitd(authority=local): Operator of unix-session:1 successfully authenticated as unix-user:marjorie to gain ONE-SHOT authorization for action com.ubuntu.pkexec.synaptic for unix-process:13922:214554138 [/bin/sh /usr/bin/synaptic-pkexec] (owned by unix-user:marjorie)
Jul 3 17:33:18 grendel pkexec: pam_unix(polkit-1:session): session opened for user root(uid=0) by (uid=1000)
Jul 3 17:33:18 grendel pkexec[13925]: marjorie: Executing command [USER=root] [TTY=unknown] [CWD=/home/marjorie] [COMMAND=/usr/sbin/synaptic]My software stack is:
Host: grendel
Kernel: 6.1.0-0.deb11.7-amd64 x86_64
compiler: gcc v: 10.2.1
Desktop: Cinnamon 4.8.6
tk: GTK 3.24.24
wm: muffin 4.8.1
dm: LightDM 1.26.0
Distro: Devuan GNU/Linux 4 (chimaera)
There are some changes to how logging works in Bookworm mentioned in the release notes, see sections 5.17-5.19.
It's not clear how these changes propagate through to Daedalus when it's either a new install (as I surmise yours was originally) or if you upgrade from Chimaera.
Hi,
You have posted the output of lshw as an image - the font is tiny and I, at least, find it unreadable, so it's hard to help you further.
This is my output of the same command on my PC posted with code delimiters.
I'm running a AMD B550 motherboard with a AMD Ryzen 5 5600G with Radeon Graphics.
sudo lshw -C video
*-display
description: VGA compatible controller
product: Cezanne
vendor: Advanced Micro Devices, Inc. [AMD/ATI]
physical id: 0
bus info: pci@0000:30:00.0
version: c9
width: 64 bits
clock: 33MHz
capabilities: pm pciexpress msi msix vga_controller bus_master cap_list rom
configuration: driver=amdgpu latency=0
resources: irq:37 memory:d0000000-dfffffff memory:e0000000-e01fffff ioport:e000(size=256) memory:fcb00000-fcb7ffff memory:c0000-dffffCan you do the same, please?
Also it would be helpful if you can say what you are aiming for in video,
Is grub failing completely?
Usually you can successfully boot into the previous kernel from the grub menu.
Hi Ralph. Yes, perhaps I'm just not very good at expressing my understanding of this.
The Debian wiki says:
Starting with Debian 10 Buster, nf_tables is the default backend when using iptables, by means of the iptables-nft layer (i.e, using iptables syntax with the nf_tables kernel subsystem). This also affects ip6tables, arptables and ebtables.
You can switch back and forth between iptables-nft and iptables-legacy by means of update-alternatives (same applies to arptables and ebtables).
So I suspect that in the default installation the fail2ban configuration assumes that iptables is installed, calls iptables and uses iptables-nft to translate.
Not quite the same thing as going nftables native.
Hence it seems that the simplest solution for the OP is, as you have said, to reinstall iptables.
In your /etc/fail2ban/jail.conf I notice you have:
208:banaction = iptables-multiport
209:banaction_allports = iptables-allportsIn my version (which works) I have:
# Default banning action (e.g. iptables, iptables-new,
# iptables-multiport, shorewall, etc) It is used to define
# action_* variables. Can be overridden globally or per
# section within jail.local file
banaction = nftables[type=multiport]
banaction_allports = nftables[type=allports]also my /etc/fail2ban/jail.local starts:
[DEFAULT]
banaction = nftables
chain = input
[apache-auth]
enabled = trueNB all my subsequent jails after [apache-auth] are for postfix/dovecot as I only actively use apache to get my letsencrypt certificates (a webpage also exists).
So your fail2ban is calling iptables for banactions when you've deleted it. My version just invokes nftables.
The problem maybe that the switch from iptables to nftables is still incomplete in Chimaera and the default version still uses iptables commands that are then translated to nftables syntax. The underlying kernel module *is* now nftables.
My mail server was originally created in Beowulf ad novo using the guide that I referenced so is strict nftables (no iptables) while my own workstation is still using iptables (it began as asciii). Both were subsequently upgraded to Chimaera. The workstation doesn't need fail2ban.
Wondering if you've ended up with some form of hybrid iptables/nftables fail2ban config.
can you post the contents of your /etc/fail2ban/jail.conf and /etc/fail2ban/jail.local file?
I used this guide to set up my mail system (with apache2 and postfix/dovecot support)
https://workaround.org/bullseye/firewal … igation-2/
I just needed translate the usual systemd systemctl call to sysvintit service calls.
Marjorie wrote:It seems to be a graphics issue
Try a newer firmware version:
The 2022-12-14 snapshot (of firmware-amd-graphics] will probably fix things with no need to run an outdated kernel with known, published vulnerabilities.
The .deb from unstable should be safe to install in a stable system because it has no dependencies:
Well that may help.Thanks.
You do have to upgrade firmware-linux-nonfree from stable to backports first before the more up to date firmware-amd-graphics will install.
Installed it, upgrade to the latest 6.0.0.0 backported kernel and Zoom and Signal now start OK. Suspend-resume works for a while after resume and then freezes, as before.
Not sure why a still current and supported LTS kernel is considered "outdated kernel with known, published vulnerabilities", though I note that all the backported kernels lag the latest version.
mainline: 6.2-rc6 2023-01-29
stable: 6.1.9 2023-02-01
stable: 6.0.19 [EOL] 2023-01-12
longterm: 5.15.91 2023-02-01
longterm: 5.10.166 2023-02-01
longterm: 5.4.230 2023-01-24
longterm: 4.19.271 2023-01-24
longterm: 4.14.304 2023-01-24
longterm: 4.9.337 [EOL] 2023-01-07 I have a 5600G running Chimaera.
AMD issued fixes for the integrated graphics in the 5600G in backported kernel 5.15, this also fixed an issue I had with the lack of a driver for the sensor (nct6687) on my MSI B550 motherboard.
I have since attempted to install more recent backport kernels but I found that they have issues. In particular Signal Desktop (from the repositories) and Zoom (from Zoom) often almost froze when starting. It seems to be a graphics issue.
This may well have been fixed in newer kernels than the ones I tried but if you are still having issues having followed Rolfie's advice I suggest you try 5.15 (LTS until at least October 2023).
I still get freeze issues with 5.15 if I try to suspend and resume. Hibernate and resume works fine.
Love the gone "pear shaped" humor. You remind me of an old friend.
I swapped your nftables.conf code for mine - do I need to reboot for it to take effect?
EDIT 1:
Rebooted - no joy.
EDIT 2:
# nft -cf /etc/nftables.conf reports no errors.
(as root)
service nftables status
will tell you if its running.
service nftables restart
or
service nftables force-reload
can be used to restart or just reload the conf file respectively. Or a reboot will also work.
as well as status run
nft list ruleset
and post it so we can check its working.
If it is working then I expect your problem is elsewhere.
Try a port scan from another machine on your network to see if ports 80 and 443 are open.
You could try this nftables.conf.
This is based on mine, which works, the only changes are that I've pruned the additional ports I've opened on mine for email, ntp, dns, monitoring.
#!/usr/sbin/nft -f
flush ruleset
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
iifname lo accept
ct state established,related accept
tcp dport ssh ct state new accept
tcp dport http ct state new accept
tcp dport https ct state new accept
# ICMP: errors, pings
ip protocol icmp icmp type { echo-request, echo-reply, destination-unreachable, time-exceeded, parameter-problem, router-solicitation, router-advertisement } accept
# ICMPv6: errors, pings, routing
ip6 nexthdr icmpv6 counter accept comment "accept all ICMP types"
# Reject other packets
ip protocol tcp reject with tcp reset
}
}The IP in your most recent post is not a private address - it appears to belong to an ISP - indicating that you may be trying to run a public Internet-facing webserver from a machine on your home network...?
As he has a fixed IP from his ISP (though I recall he does describe it as immutable not fixed) that isn't necessarily an issue: I have a fixed IP from my ISP (Zen) and it hosts both an accessible (apache) website and my (postfix) family mail server.
And we were able to access his website too at one point before it all went pear-shaped.
But as your (dcolburn) server is on a network behind a router can I assume that you have opened the relevant ports on the router as well as your server's (nftables) firewall?
But from devuan repo 340.108 is working but not perfectly installs (nvidia-settings launch only from terminal and i need to delete some modprobe nvidia files because do not want see warnings during booting process)
In order to run nvidia video drivers the init will have to insert the nvidia kernel module, done by a modprobe. I have a pc (not my main pc) with an nvidia card and it invariably came up with an insert nvidia kernel module fail message early in the boot process though it would go on and succeed subsequently 'tainting the kernel'.
If you have deleted some 'modprobe nvidia files' you may have disabled this insertion.
When you change the kernel version the nvidia kernel module also needs to be recompiled and to do so requires that you have the matching kernel headers as well as the new kernel itself. If everything is present it does this automatically, however the PC will then need to be rebooted.
Alternatively use either
sudo service nginx restartor
su -
service nginx restartdepending on whether you have a root password or not.