You are not logged in.
The installation of the clearlooks-phenix-sapphire-theme changed /etc/grub/default back to desktop-base and the themes there. On my encrypted Daedalus this produced the initial error in grub, an update-grub did NOT fix this. I copied clearlooks-phenix-sapphire-theme to /boot/grub/themes and changed the /etc/grub/default to point to the /boot/grub/themes-directory, and everything is fine again.
Could it be that grub searches for the theme on the encrypted system device? Check /etc/default/grub.
When this is the case you may need to move the theme files to the unencrypted /boot.
Daedalus: rsyslog 8.2302.0-1devuan1 reads
#!/bin/sh
if [ -d /run/systemd/system ] && [ -x /usr/lib/rsyslog/rsyslog-rotate.real ]; then
/usr/lib/rsyslog/rsyslog-rotate.real "$@"
elif [ -x /etc/init.d/rsyslog ]; then
invoke-rc.d rsyslog rotate > /dev/null
fiThis is not the Chimaera backports package!!!
Edith: And logrotate does seem to work on my laptop.
Just looked into the Daedalus version, that looks not literally the same but as far as I can tell shows the desired two options.
So last year i installed Devuan Daedalus on my ddr3 desktop and everything was fine. All partitions were made custom by me (1 for swap, 1 for /boot/efi -esp- 1 for /root and last but not least a seperate /home partition). I chose openrc and mate desktop. Everythin was fine until recently!!!
Last week i unplugged my ssd to plug a win7 (a friend's one not mine i don't use windows) ssd and restore some files. When i plugged back my devuan ssd i could not boot into system. The same ssd could boot on my other desktop but with messed graphics and of course could not boot onto my laptop.
Obviously this is an efi installation. When you removed the SSD with Devuan and put in another device, the Devuan boot entry in the efi flash was removed when booting. That's why you can't directly boot into the previously working Devuan system. This seems to be a built-in efi functionality.
As a fix, boot the installer medium again, call up the rescue mode, chroot into the Devuan installation on the SSD, and re-install grub. You may also use a life system, chroot is a bit more complicated than with the installer.
Good luck.
When you look at your log you see fuse being removed and fuse3 being added. OK?
After some more unsystematic fiddeling I compared the two /etc/network/interfaces files and found that in Daedalus the initial eth0 wired connection still was enabled. Wired at home was no problem. Guess what, after reboot I got into the hotel's network.
This post is from my laptopn running Daedalus via wifi.
Thanks for the suggestion, rolfie
As far as I remember when I installed wine a while ago, when you just specify # apt install wine you just get wine64, the additional architecture does not matter. i386 is pre-requisite to do an # apt install wine32.
Yes, initially only the main thing,
http://hotspot.nonius.hsia/Hotspot/index.php?now on your suggestion I copied the complete entry from the cronicle (its quite long) and changed the IP that was used. Firefox opens the page, but instead of waiting for my entries and the Enter button, it tries to jump to the hotel's home page immediately. Very strange.
On the Back button I can stop FF to allow my entries, but it does not work.
BTW, I have Firefox ESR installed on both releases.
I am abroad with my laptop, and can't get into the hotels wifi network with Daedalus.
Details: got an Acer Aspire and as well Chimaera as Daedalus on the machine, Cinnamon DE, wifi drivers loaded, ufw and network manager installed, both installations detect the hotel's network. They have no security running, just a login page requesting a password.
With Chimaera up and running, internet access works. Got a request within Firefox that asked for the hotels guest password. This post is from Chimaera.
But I would like to get Daedalus to do the same thing because I have copied the evolution mail file from my desktop at home running Daedalus and would like to use it. Looks like the database is incompatible to the one on Chimaera, and working with more than one mail account via web interface isn't fun.
Daedalus also sees the hotel's network. But for some reason I do not get the pw request in Firefox. I have played around a lot, disabled NoScript and UBlock, checked all my settings if I am too strict, to no effect. Meanwhile I seem to have generated a list of numbered connections shown in the network connections screen. On Chimaera I only have one called "Automatic Hotel xyz".
Currently I am out of ideas why I do not get the pw request. What do I need to check for a systematic troubleshooting?
Thanks,
Welcome. Devuan also works fine in efi mode, you just have to get used to it and the slight differences in behaviour and tooling.
Just an example: on my Acer Aspire I had to set an admin password before I could disable SecureBoot and install Devuan in efi-Mode. Ask their Support!
Well, I have my desktop running with Daedalus, lightdm & Cinnamon, up-to-date, openrc and amd64, traditional unencrypted /boot, a luks-encrypted container holding a LVM for / and /swap. Working fine, just tried it, no shutdown delays.
Update: also checked my laptop running Daedalus with similar setup: no problems with shutdown delays.
I looked into my update history. The last update of the cryptsetup-stuff was before Chrismas. Why do we suddenly have a problem?
Well, there is package called ttf-mscorefonts-installer that pulls the standard Windows fonts ...
Ok, another loop. You definitely use a 5600XT for display, not the built in graphics from the CPU? Its a NAVI1, but a later modification. For firmware support you may need to follow HoaS' suggestion.
Backports handling: if you want to install a package from backports, you explicitly must specify this as I showed in my example. Just enabling backports in the sources.list and an install won't pull anything from backports. Intentionally. Pinning makes sure ....
You did not downgrade, but also didn't upgrade. When you pull a package from backports leave backports enabled, or you may get a downgrade later. And you won't get fixes from backports.
Good luck ...
Ok, this is a slightly different situation, your 5600G CPU isn't comparable to a 5x00XT graphics card. And despite your post the 5.10 kernel series is stock Chimaera, not backports.
For full support please enable chimaera-backports main contrib non-free in your sources.list. The perform:
# apt update
# apt -t chimaera-backports install linux-image-amd64 firmware-amd-graphicslinux-image-amd64 is a meta-package that pulls the latest backports kernel (currently some 6.x version) and makes sure that its being upgraded when required. And also the graphics firmware has an update in backports.
Give it a try, should improve your system ...
@rolfie - Thanks. Yes, I have found lots of topics, but nothing about the release itself. I just got a new-to-me card (amd RX 5600XT) and it's working ok after passing kernel params to stop the crashes.
Still got a PC running on a Ryzen7 3700 and a 5500XT, stock Chimaera with backports kernel, my wife's desktop. No kernel parameters required, just firmware-amd-graphics. You should stick to Chimaera until Daedalus is becoming stable.
My desktop was upgraded to a 6700XT, that does not work fine on Chimaera, it need more recent mesa and other stuff. This is running Daedalus. No kernel params, again just firmware-amd-graphics.
Use Daedalus as search pattern in the forum search and you will find a bunch of topics listed.
I myself use it productive already on a brand new graphics card that does not work well in Chimaera. More than two months now, no major issues. I have also installed it on my laptop in parallel to Chimaera.
New feature dripping down from Debian into testing/unstable = Daedalus & Ceres.
With todays update session I received several firmware updates. Looks like the merge has been adapted.
I guess the merge needs to be adapted/completed.
# apt policy
Paketdateien:
100 /var/lib/dpkg/status
release a=now
500 http://deb.devuan.org/merged daedalus/non-free-firmware amd64 Packages
release v=5.0,o=Devuan,a=testing,n=daedalus,l=Devuan,c=non-free-firmware,b=amd64
origin deb.devuan.org
500 http://deb.devuan.org/merged daedalus/non-free amd64 Packages
release v=5.0,o=Devuan,a=testing,n=daedalus,l=Devuan,c=non-free,b=amd64
origin deb.devuan.org
500 http://deb.devuan.org/merged daedalus/contrib amd64 Packages
release v=5.0,o=Devuan,a=testing,n=daedalus,l=Devuan,c=contrib,b=amd64
origin deb.devuan.org
500 http://deb.devuan.org/merged daedalus/main amd64 Packages
release v=5.0,o=Devuan,a=testing,n=daedalus,l=Devuan,c=main,b=amd64
origin deb.devuan.org
Mit Pinning verwaltete Pakete:I guess that change has not been considered by Devuan yet. the sources.list from my test machine reads:
deb http://deb.devuan.org/merged daedalus main contrib non-free non-free-firmware# apt update works, but apt list does not find any packages from the new repo https://deb.debian.org/debian/pool/non- … e-nonfree/, example:
# apt list firmware*
Auflistung… Fertig
firmware-ast/testing 20140808-7 all
firmware-ath9k-htc/testing 1.4.0-108-gd856466+dfsg1-1 all
firmware-b43-installer/testing 1:019-7 all
firmware-b43legacy-installer/testing 1:019-7 all
firmware-linux-free/testing,now 20200122-1 all [Installiert,automatisch]
firmware-nvidia-gsp/testing 510.108.03-3 amd64
firmware-nvidia-tesla-gsp/testing 510.108.03-3 amd64
firmware-realtek-rtl8723cs-bt/testing 20181104-2 all
firmware-realtek/now 20210818-1 all [Installiert,lokal]
firmware-sof-signed/testing 2.2.4-1 all
firmware-tomu/testing 2.0~rc7-2 all
firmware-zd1211/testing 1:1.5-8 allDaedalus/Testing: Just stumbled across a new feature imported from Debian: the package firmware-linux-nonfree is gone, there is an additional entry required in the sources.list to get access: "non-free-firmware" after main contrib non-free.
It looks like all the packages have been renamed somehow, need firmware-amd-graphics, and can't find a replacement. This package no more exists.
Any hints? Searching the repo for parts of this name ends with "Search timed out. Please use a more specific pattern....."
Maybe I am wrong, but I think it is because the "enumeration" has been parallelised instead of looking at ata, then scsi, then usb in serial order. And since usb has become more important over the years chances are much higher nowadays that additional usb devices pop up as block devices.
Edith: Just checked, I already had issues with that when setting up my file server with Debian 3 Sarge. Adding/removing a scsi disk screwed the device naming, in my early Linux days I started to use uuid.