Please check the Release Notes (https://files.devuan.org/devuan_chimaer … _notes.txt) for the path/su issue.

How did you do your install? Sounds a bit like Expert Mode and leaving out one or the other step ...

rolfie

Not any file system on any USB stick will found on /dev/sd(X), it always will be on /dev/sd(X)1 or higher.

Use any stick with FAT32, you have to mount it with /dev/sd(X)1.

rolfie

On the top of the forum page is a link to Devuan.org where you can find the official documentation and several howtos.

Myself I have upgraded my wifes PC and my file server from Beowulf to Chimaera without any issues. My PC is using parallel installation of Arch/Beowulf/Chimaera. I have moved my activities from Beowulf to Chimaera early summer this year before Chimaera even got stable.

General advice: disable any foreign repositories during the upgrade.

rolfie

Thank you, drilling down into modules and devices showed no /dev/mapper nor cryptsetup traces.

Rebooted from the netinstall in rescue mode: installed cryptsetup-bin and cryptsetup-initramfs, now it works. Both packages need to be added to the installer.

rolfie

Wouldn't be that optimistic. Devuan uses a different mode than Debian for efi boot, and that works fine on real HW. Just causes issues in VBox. Haven't got anything that the admins work on this topic.

The workaround described in my lengthy post works, just managed to install from the Daedalus preview.

rolfie

Chimaera: On my lightdm login screen I have a small icon in the middle of the bottom that opens a screen keyboard that can be operated with the mouse. Maybe that helps.

rolfie

Just tried it on my Chimaera box (Arch and Beowulf in parallel installations): Adding that line to /etc/default/grub does not make any difference on efi installations.

rolfie

Libreoffice has dropped Type1 font support a while ago. You need to find replacements, like ErlerDingbats.ttf instead off ZapfDingbats.

rolfie

Addition to my remark in post #7: The Secure Boot mechanism in Debian & Devuan is fixed to support Debian with a fixed entry called debian in the efi-variables called efivars. The installer (no matter if Debian or Devuan) installs 5 files in this directory, two of them being the already mentioned shimx64 and the grubx64. As explained shimx64 is meant to be starting the SB mode but also can start the non SB mode, grubx64 the normal mode. Per default, shimx64 is written into the starter for the efi mode. shimx64 seems to have issues when the base directory isn't called debian.

These boundary conditions cause problems when you want to set up an efi multi distribution setup as you have. I been through all the problems with this, here is my cook book. I have set up my current workstation (AMD X570, Ryzen 3700X, Sapphire xt5500 graphics) 18 months ago with Arch, Beowulf and Chimaera. Initially Beowulf was the main working spot, early summer this year I moved to Chimaera for daily work.

1.) Disable Secure Boot in the Bios and delete all signing keys.
2.) No CSM, pure EFI setup.
3.) Install the distro, reboot, setup sources.list ....
4.) Remove SB files: apt remove grub-efi-amd64-signed
5.) Reinstall bootloader into individual directory (only installs grubx64), example for Beowulf: grub-install --bootloader-id=devuan3 --no-uefi-secure-boot
6.) Check setup with efibootmgr: efibootmgr -v
7.) Cleanup /boot/efi/EFI: remove residual files from directories called debian and devuan.
8.) Cleanup efivars with efibootmgr: efibootmgr -b 000x -B

Set the boot order to the desired option with efibootmgr, or use the Bios Boot Override to boot one of the other possible options. All my 3 options are clean, os-prober never gave me such an option. I like it this way, since I normally boot one distro for working purposes.

My opinion to the automatic partitioning: when I read about all the issues with /boot being too small /root being to small in various Debian/Devuan forums and see what the SW is doing there, I must say: Forget it, that was ok 10 15 years ago, and has not been adapted in any way to today's disk sizes. It sets up sort of a bare minimum size that very often struggels when you add a kernel or a bit more than the bare minimum SW. I am used to use only manual partitioning, even in a VM, even if it is a bit more cumbersome. I usually get what I want and never ran into partition too small type of problems.

HTH, rolfie

Very simple: firefox-esr is not a genuine Devuan package, it is a Debian inheritance.

Also SLIM is no more maintained since 7 or 8 years now. Its sort of deprecated. Lightdm is working fine (for me at least).

rolfie

Well, different approach. I first want to try if I can get my approach to work. Thank you anyway.

rolfie