I think you would also reenter the boot menu with the command menu.

That "grub_verify_string" issue needs some further exploration. Thanks.

but after the installation succeeded the system did not boot. I had secure boot disabled from previous beowulf installation and it showed the message

error: symbol `grub_verify_string' not found

so I had to reenable secure boot to make it work. Some minor issues not important are that the installation media still says beowulf and if you enter the help menu you need to restart the pc to proceed with the installation.

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

Ok, lunchbreak is over now. I have looked at the original iso and my creation, here is the output:

# fdisk -l devuan_chimaera_4.0.beta-20210906_amd64_netinstall.iso
Disk devuan_chimaera_4.0.beta-20210906_amd64_netinstall.iso: 371 MiB, 389021696 bytes, 759808 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x6b8b4567

Device                                                  Boot Start    End Sectors  Size Id Type
devuan_chimaera_4.0.beta-20210906_amd64_netinstall.iso1 *        0 759807  759808  371M  0 Empty
devuan_chimaera_4.0.beta-20210906_amd64_netinstall.iso2       4040   5511    1472  736K ef EFI (FAT-12/16/32)
# fdisk -l daedalus.iso
Disk daedalus.iso: 373,22 MiB, 391350272 bytes, 764356 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

The VM based on the daedalus.iso is running Mate desktop on encrypted LVM with openrc with daedalus in the sources.list.

I can't answer what VBox does not see. Does it make sense to show the printouts I am getting?

rolfie

Just the "normal" multi-boot set up.

Use "fdisk -l $iso" to review that ..
perhaps VBOX fails to see the partition table? Or that its  virtual UEFI implementation fails to see it?

1) Why doesn't it boot? What does happen on the attempt?

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

1.) The Devuan isos do not boot in VBox efi mode. My solution was: unpack the iso into a folder, add the EFI directory from a Debian iso, and create my own iso with Brasero. That boots directly.

2.) efivarsfs isn't mounted on the boots past installation. Added the following line to fstab, and now I have the efi variables available.

efivarfs /sys/firmware/efi/efivars efivarfs rw 0 0

I think both topics deserve a look at.

rolfie

FYI: gparted requires a graphical environment. If there are issues beyond that, please file a bug report for refractainstaller-base or start a separate thread about it. Thanks.

Running only the installer I often had the situation, that the system did not boot: No boot device found, Grub Rescue or a fragmented Grub screen - all this has happened in the past.

Honestly the Grub installation of the refractainstaller seems to be not perfect.

Regards
Berni

PS: Using the lates minimal-live I ran into a problem when choosing GParted during installation. GParted was not part of minimal-live, and the refractainstaller ended in an endless loop between selecting the partition tool and going ahed without partitioning. Choosing another tool (gdisk, cfdisk) always brought the indication "GParted is not installed".
That happened yesterday when setting up a Daedalus system, based on minimal live.
Finally some manual work as described afore was successful.