You are not logged in.
Your system is encrypted, so the /usr/share/... path isn't available to grub when booting.
The solution is to copy the /usr/share/desktop-base/grub-themes/desktop-grub-theme-files to /boot/grub/themes. This will provide the default layout in an unencrypted location. Every now and then the /etc/default/grub may get overwritten by updates. Then you have to fiddle again.
I have no idea what will happen if you simply comment the themes-line from /etc/default/grub. That may cause a real hickup...
This line
Found theme: /usr/share/desktop-base/grub-themes/desktop-grub-theme/theme.txtindicates that grub wants to read the path /usr/share/desktop-base/grub-themes/desktop-grub-theme. This path is available on an unencrypted system for grub and for the system when running update-grub at any time, no errros.
On an encrypted system, when grub starts, this path isn't available yet until the initramfs has opened the root directory. This is when you get the errors as from the initial post. When running update grub there is no error since then /usr/share.... is available.
You need to dig a bit deeper into the path on your selected server. The Daedalus directory it self was created in 2021, below you should find up to date previews, the latest seems to be dated March 27th.
BTW: basic non-free stuff is already integrated, there are no separate isos as with Debian.
You have to leave the Ventoj partitioning scheme for the boot stick alone as is. Don't try to modify this. Per Default there is a boot partition that hold everything for legacy and efi boot, and a partition for the iso's. I think there is no LVM involved if I am not mistaken.
It is not Ventoj that is causing problems, it is the installer itself. If you are manually directing the installer to the intended partitions for the installation everything works fine.
In manual partitioning mode you can see which devices and parititons are what for and select the desired spave for the system.
With a Ventoj multiboot stick never use automated install! You will need to use manual partitioning to have full control where the system goes. This works perfectly.
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.