No need for excuses. To fix that: you are allowed to edit your posts. In the bottom of the post your find 4 options, one is edit. This means you can delete the extra line.

To the installer: just did such an install of Chimaera into a VBox VM about a week ago, there it was no such issue. Looks like a bug in the latest installer?

rolfie

Just found something in a German laptop forum about rufus and Secure Boot: rufus does not write a valid Secure Boot signature. That means in your case rufus isn't the right tool.

rolfie

Edith: well, I have successfully used rufus for a lot of bootable USB sticks in the past. Legacy mode or UEFI, it always worked fine, but without Secure Boot. I always did disable this "feature".

When I boot one of the latest Devuan isos in VBox, I get:

UEFI Interactive Shell v2.2
EDK II
UEFI v2.70 (EDKII, 0x00010000)
Mapping table
	 FS0: Alias(s):F0c:;BLK0:
	     PciRoot(0x0)/Pci(0xF1,0x1)/Ata(0x0)
	BLK2: Alias(s):
	     PciRoot(0x0)/Pci(0xF1,0x2)/Sata(0x0,0xFFFF,0x0)
	BLK1: Alias(s):
	     PciRoot(0x0)/Pci(0xF1,0x1)/Ata(0x0)/HD(2,MBR,0x6B8B4567,0xFC8,0x5C0)
Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
Shell>

I am used to switch to FS0: based on the experience that some of the VMs won't autostart. Then I typically drill down the EFI folder and find some *.efi file which can be booted. Here I get on ls:

Shell> FS0:
FS0:\> ls

10 Files: boot.cat, debian, devuan, g2ldr, g2ldr.mbr, md5sum.txt, README.html, README.txt, Release_notes_chimaera_4.0.0.txt, setup.exe
5 Dirs: boot, dists, docs, firmware, pool

I have drilled down every single directory and searched for a *.efi file, no success. Using BLK1: is the same.

When I try exit on the shell, I get a menu, but no useful option I could start with the Boot Manager.

Nevertheless, found something new: when I exit the menu with the Continue option, I get presented a different mapping table:

Mapping table
	 FS0: Alias(s):F0c:;BLK0:
	     PciRoot(0x0)/Pci(0xF1,0x1)/Ata(0x0)
	 FS1: Alias(s):CD0c1:;BLK2:
	     PciRoot(0x0)/Pci(0xF1,0x1)/Ata(0x0)/CDROM(0x1)
	BLK4: Alias(s):
	     PciRoot(0x0)/Pci(0xF1,0x2)/Sata(0x0,0xFFFF,0x0)
	BLK3: Alias(s):
	     PciRoot(0x0)/Pci(0xF1,0x1)/Ata(0x0)/HD(2,MBR,0x6B8B4567,0xFC8,0x5C0)
	BLK1: Alias(s):
	     PciRoot(0x0)/Pci(0xF1,0x1)/Ata(0x0)/CDROM(0x0)

Drilling down FS1: brings an efi directory and a bootable bootx64.efi file. BLK1: is the above mentioned file system (10 files 5 dirs).

Strange behaviour.

rolfie

No. Me neither. What is the EFI partition in the Devuan isos?

I end up in the VBox efi shell and can't find any command that allows to boot the iso image. In the EFI directory copied from the Debian iso's there is a grubx64.efi re. a bootx64.efi. When that is added the iso starts automagically the installer.

rolfie

I can confirm that you can install Chimaera in EFI mode. I have performed such an install from I think the alpha net install end of April on an Acer Aspire 5. You may find one or the other thread from me around that time.

Suggestions:
- If you can disable SecureBoot.
- Set the Bios to no CSM, efi driver first, whatever the Bios allows. If in doubt, ask here.
- Make sure you boot your install media in efi mode. When booting, you will usually find your devices twice. Make sure you boot the one that is marked as efi. If not the install runs in legacy mode.
- To verify that the installer is in efi mode, switch to a console as Ralph has suggested, and make sure you have a directory /sys/firmware/efi/efivars. If this isn't present, you are not installing in efi mode.
- grub is installed in efi mode without asking where to. Thats normal.
- After first boot you should have a folder /boot/efi/EFI/debian. In there you should see 5 or 6 files, one of them called grubx64.efi (non-secure boot), another called shimx64.efi (I hope the name is right, I never did a Secure Boot installation and usually delete all related stuff) for secure boot plus some others.
- Check with efibootmgr if you get an output or an error telling you that efi isn't supported?
- I had an issue with that after first boot the efivars were not loaded. I think mounted them, re-installed grub-efi-amd64 and then it worked. Don't know if this still is an issue. Refer to my older threads.

Good luck, rolfie

I have switched my home network completely to Chimaera. 2 PCs, a file server, a laptop.

rolfie

From https://files.devuan.org/devuan_beowulf … _notes.txt:

Pulseaudio
 - If you install a desktop environment from the installer iso, you will
   automatically get the debian-pulseaudio-config-override package,
   which will ensure that pulseaudio is running. If you're running a
   window manager, you may need to install the override package to get
   sound. Alternatively, you may use the old method, described below.
   
 - If you have no sound, make sure the following line in
   /etc/pulse/client.conf.d/00-disable-autospawn.conf is commented as
   shown here:

   #autospawn=no

Maybe this helps.

rolfie

Got 4 PC (one rarely used still on ASCII, one on Beowulf, two multiboot PCs now mainly working with Chimaera for productive work), a file server (upgraded from Beowulf) and a laptop with native Chimaera (set up in April). They all are encrypted, the system always sits on a encrypted LVM, the /home on a separate encrypted drive. On some of them other encrypted drives are loaded by an entry in the crypttab or via a separate script. Everything works very smooth and nice.

I use Chimaera now on all PCs that my wife and me work with regularly. Its rock stable. Very few glitches.

Lets us know details where you stumbled or had issues. Since an encrypted LVM is not absolutely straight forward, maybe its worth to try the basic setup in a VM?

rolfie

Thanks for the heads up, I was looking for such a script and did not find anything useful by the means of Nemo (Cinnamon desktop). In fact there is a cgroups script in /etc/init.d without a LSB header. Here are the first few lines:

#!/sbin/openrc-run
# Copyright (c) 2017 The OpenRC Authors.
# See the Authors file at the top-level directory of this distribution and
# https://github.com/OpenRC/openrc/blob/master/AUTHORS
#
# This file is part of OpenRC. It is subject to the license terms in
# the LICENSE file found in the top-level directory of this
# distribution and at https://github.com/OpenRC/openrc/blob/master/LICENSE
# This file may not be copied, modified, propagated, or distributed
# except according to the terms contained in the LICENSE file.

description="Mount the control groups."

cgroup_opts=nodev,noexec,nosuid

depend()
{
	keyword -docker -prefix -systemd-nspawn -vserver
	after sysfs mountkernfs
}

....

Script by the openrc team. Worth a bug report?

rolfie

Short update: this script is not present under Beowulf/openrc/Cinnamon

Sharing a LVM logical volume should work fine without any problems as long as its not used for distribution specific configuration data. LVM2 is mature, and there should be no major difference in the LVM implementation between distributions. Booting into one or the other should not matter for a data storage, and as long as you use a mature file system like ext4 on the share.

I have split my /home for my multiboot setup with Beowulf and Chimaera into a partition that holds all office data like pictures, LO files etc, and a distribution specific part that holds all the hidden config and cache files. The office share is linked into the distribution specific part during boot.

rolfie