You are not logged in.
Hi! I tried to install devuan chimera netinstall booting with the 'devuan_chimaera_4.0.beta-20210906_amd64_netinstall.iso' file and if i used UEDFI only, the installation did not copied grub to the installation disk, but if i booted under 'BIOS Legacy' mode, it worked perfectly.
The disk is an SSD drive, and i installed with the 'Guided' and 'encrypted luks' automatic installation, selecting separated '/' and '/home' partitions.
Its not supported to install in UEFI only mode? its a Dell laptop model 'Latitude 5480'
Offline
Yes, the netinstall is supposed to work in UEFI mode, and there are many cases were it has done so.
One of the issues that may come up with the grub installation step is that for some reason the "efivars" have got filled up with some kind of dump files. This can be handled by the following slight manual hands-on just before selecting init system:
Shift to virtual terminal 2 by pressing Ctrl-Alt-F2, and push Enter.
Check if this might be the problem by command: ls /sys/firmware/efi/efivars/dump-*
If that results with lots of output, then continue with step 3;
if there is no such file, then this is not your problem, so skip step 3.
Remove the dump files with command: rm /sys/firmware/efi/efivars/dump-*
Return back to installer at virtual terminal 1 by pressing Ctrl-Alt-F1, and continue.
Offline
Other potential causes of a lack of UEFI variable support and ways to fix them are listed here:
https://wiki.archlinux.org/title/Unifie … le_support
if i used UEDFI only, the installation did not copied grub to the installation disk
What does that mean, exactly? What actually happens when you try? What do you see in the installer? Are there any errors? If so did you check TTY4 for the full message?
If the installer proceeds without error then what happens when you start the machine up afterwards? What do you see?
Brianna Ghey — Rest In Power
Offline
What does that mean, exactly? What actually happens when you try? What do you see in the installer? Are there any errors? If so did you check TTY4 for the full message?
Hi! if im in UEFI mode only, the installer works normally, but i noticed that it didnt ask me about the disk to copy grub, it only says that its running grub-mkconfig or something like that, but didnt ask me the disk to implement the boot and grub, that shows when i use legacy mode.
In UEFI only mode, also, when i reboot, it shows an error saying that i dont have any OS installed, as its like the disk doesnt have any boot installed (i think its related to the installer not asking about the disk to install grub at the end) i didnt check TTY4 as i didnt knew it showed messages, i will try to reinstall anytime soon to check those things.
Offline
if im in UEFI mode only, the installer works normally, but i noticed that it didnt ask me about the disk to copy grub, it only says that its running grub-mkconfig or something like that, but didnt ask me the disk to implement the boot and grub, that shows when i use legacy mode.
That is the expected behaviour. UEFI systems use the EFI system partition to store GRUB's core.img (grubx64.efi) and the motherboard NVRAM to store the boot entries so there is no need to specify the target drive. The UEFI grub-install command does not expect a block device as an argument and will not recognise it if it is provided; the equivalent option for UEFI systems would be --efi-directory (pointing to the EFI system partition).
In UEFI only mode, also, when i reboot, it shows an error saying that i dont have any OS installed, as its like the disk doesnt have any boot installed
Did you try disabling Secure Boot? Devuan chimaera should support it but some motherboards require that .efi loaders be authorised in the firmware ("BIOS") settings first.
Brianna Ghey — Rest In Power
Offline
Hi
It might as well be the authentication keys used by secure boot. They need to be set to something like custom. Mine was set as an HP key. And that will not work except for Windows.
Have a nice day
Lars H
Last edited by larsH (2021-09-10 16:48:31)
Offline
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
Last edited by rolfie (2021-09-10 19:10:56)
Online
I think that I once had to manually create an EFI partition on one of my disks, before running the installer, (not sure if it was Devuan or another distro), then mark it as 'boot' & something else with 'manage flags' when partitioning - may or may not work for you.
Offline
After several installations of Devuan in UEFI mode with the refractainstaller my experience is as follows:
- better make the disk partioning before running the installer
- never forget the EFI partition
- also never forget to write a fat filesystem onto the EFI partition
- run the installer
- repeat the install-grub procedure manually after installation
- boot the machine in EFI mode
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.
Last edited by berni51 (2021-09-11 09:22:30)
The good ol' days will not return, and the rocks might smelt and the sea may burn.
Offline
Bernie, the OP in this thread is using a netinstall iso, not a live iso.
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.
Offline
Tried to install the devuan_chimaera_4.0.beta-20210906_amd64_netinstall.iso in a Virtualbox VM in efi mode. Got two issues.
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
Online
1) Why doesn't it boot? What does happen on the attempt?
Offline
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
Last edited by rolfie (2021-09-12 10:03:02)
Online
VBOX doesn't see the EFI partition of the devuan iso?
Offline
No. Me neither. What is the EFI partition in the Devuan isos?
Last edited by rolfie (2021-09-12 10:20:50)
Online
The ISO has a "dos" partition table that presents it as having two partitions:
1) first partition of type 0 spanning blocks 0-759807
2) second parition of type ef (=EFI) spanning blocks 4040-5511
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?
Offline
@Ralph: thanks for taking up this side issue. Maybe we should ask Golinux to split out this as a separate thread.
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
Online
I haven't used vbox in a long time, but I've always had to get out of the uefi shell with ESC or exit (or both) to get to a menu that lets me boot from a file. Drill down until you find grubx64.efi or other uefi boot file.
Offline
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
Online
Hi, I have the same problem but with the desktop version: devuan_chimaera_4.0.beta-20211004_amd64_desktop.iso in a hp notebook, the installer failed with grub-install dummy, I solved the grub installation problem deleting the dump-* files (thank you):
Yes, the netinstall is supposed to work in UEFI mode, and there are many cases were it has done so.
One of the issues that may come up with the grub installation step is that for some reason the "efivars" have got filled up with some kind of dump files. This can be handled by the following slight manual hands-on just before selecting init system:
Shift to virtual terminal 2 by pressing Ctrl-Alt-F2, and push Enter.
Check if this might be the problem by command: ls /sys/firmware/efi/efivars/dump-*
If that results with lots of output, then continue with step 3;
if there is no such file, then this is not your problem, so skip step 3.Remove the dump files with command: rm /sys/firmware/efi/efivars/dump-*
Return back to installer at virtual terminal 1 by pressing Ctrl-Alt-F1, and continue.
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.
Offline
Thanks for spotting and reporting the spurious "bewoulf".
I think you would also reenter the boot menu with the command menu.
That "grub_verify_string" issue needs some further exploration. Thanks.
Offline