You are not logged in.
Once the installer gave up and fell into a command prompt, I looked and verified that /lib/modules/XXXX/kernel/drivers/virtio/ is missing. But .../block/virtio_blk.ko and .../scsi/virtio_scsi.ko *are* present.
Peculiar. I just looked in the ISO's initrd.gz; the .../drivers/virtio directory is there and populated. Is something erasing it after boot?
Offline
whereas the Devuan ISO only has an MBR. Presumably it's the lack of GPT that makes the Devuan ISO non-bootable for your UEFI use case.
It's good you had an alternative method for installation.
I experienced the same problem but with a chimaera reinstall on an UEFI system. Before the upgrade to daedalus had catastrophically failed.
After reboot the system ended with a prompt of some sort (grub could not find a bootable partition). From there I managed to install the efi-grub and then could successfully start the chimaera again.
With the same USBStick I installed several old Laptops with BIOS.
The history of this problem seems to reach a bit more into history at least back to chimaera.
The devil, you know, is better than the angel, you don't know. by a British Citizen, I don't know too good.
One generation abandons the enterprises of another like stranded vessels. By Henry David Thoreau, WALDEN, Economy. Line 236 (Gutenberg text Version)
broken by design :
https://bugs.debian.org/cgi-bin/bugrepo … bug=958390
Offline
Well, the particular issue with the attempt of using the daedalus installer as cdrom on UEFI appears to be that the boot loader syslinux64.efi (duly named BOOTX64.EFI) has some difficulty with that use case.
Using the same ISO as disk image on UEFI runs the same program without error.
Note that the chimaera ISOs (as well as the debian ISO) use grub rather than syslinux for UEFI boot, and apparently the grub boot loader lacks that sensitivity to that use case difference (i.e. whether the media is presented via a cdrom drive or a disk drive).
Perhaps it's simply that the boot loader gets mislead by the difference in sector size (where a cdrom has 2k sectors and a disk has 0.5k sectors). Unfortunately there are layers upon layers of compiled software involved so it's far from trivial to investigate these details. OTOH it's FOSS, so it just takes a bit of interest and skill to drill down into the particulars to determine the technical cause, and possibly correct it.
And there are of course other ways to achieve the goal of a "cdrom on UEFI" installer...
Online
I have the same issue with the offline *desktop* iso, since I have to set up without any way to connect to the internet at first.
Offline
Yes, the bootloading doesn't work via cdrom drive for UEFI bios.
It (generally) works via disk drive for UEFI bios, e.g. with the media on a USB stick.
Online
Note that the updated Devuan daedalus installer ISO set 5.0.1 now also handles the use case of booting from CDROM on UEFI.
The issue indeed was that the boot loader got confused about the iso9660 block size (2k) differing from the expected block size (512) for the EFI filesystem. To fix that we forked syslinux, added a corrective patch and published to Devuan experimental. The patched software was next used for building the updated ISO set.
Online
Note that the updated Devuan daedalus installer ISO set 5.0.1 now also handles the use case of booting from CDROM on UEFI.
The issue indeed was that the boot loader got confused about the iso9660 block size (2k) differing from the expected block size (512) for the EFI filesystem. To fix that we forked syslinux, added a corrective patch and published to Devuan experimental. The patched software was next used for building the updated ISO set.
Very cool! Thank you for the heads-up, Ralph.
pic from 1993, new guitar day.
Offline
Hello,
ok the netinstall iso 5.1 is now working on an efi system. However, there are other problems with Devuan 5.0 installation
1. on an intel i5 11th generation machine the sound hardware (Tiger Lake Smart Sound ) is not found: "Hardware not found".
Debian 12 finds sound hardware.
2. on an intel i5 7th generation machine, the installation stops right at the beginning with "kernel panic".
The laptop has 2 hard drives. one nvme with 128gb and one ssd with 1tb.
According to the bios, the following naming:
HDD0 = SSD
HDD1 = nvme
in the installation programme the following naming:
/dev/sda = SSD
/dev/sda1 = /home
/dev/sdb = nvme
/dev/sdb1 = /boot/efi
etc.
in the running system with lsblk the following naming:
/dev/sda = nvme
/dev/sda1 = /boot/efi
etc
/dev/sdb = SSD
/dev/sdb1 = /home
Devuan 2,3,4 had no problems with this naming, neither did Debian12.
I have no idea what is going wrong.
could you help please?
Offline
1. If the hardware works with Debian 12 it should work with Devuan 5 since that's the same software apart from the squashing of the systemd infestation. You will need to analyse more in detail which software was used in the working setup and make sure the same software is used, possibly in later versions.
2. How come your nvme drive is not named /dev/nvmen0?
Online
The nvme might be physically an older M.2 ssd with sata interface.
Last edited by delgado (2023-09-21 05:41:12)
Offline
Thank you very much for the quick answers.
Devuan 5 installation
1)
On intel i5 11th generation machine installation runs without problems except sound.
pavucontrol says:
virtual output device : dummy output (but no sound, vlc)
Hardware output device: no output device available.
lspci | grep -i audio: finds Tiger Lake Sound System blabla
Alsa on boot with dmesg |egrep -i "alsa | snd :
[ 1.550730] snd_hda_intel 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040100
[ 1.550951] snd_hda_intel 0000:00:1f.3: Digital mics found on Skylake+ platform, using SOF driver
and kernel modules loaded by Alsa with lsmod | grep "^snd" | cut -d " " -f 1 :
snd_hda_codec_hdmi
snd_hda_codec_realtek
snd_hda_codec_generic
snd_soc_dmic
snd_sof_pci_intel_tgl
snd_sof_intel_hda_common
snd_sof_intel_hda
snd_sof_pci
snd_sof_xtensa_dsp
snd_sof
snd_sof_utils
snd_soc_hdac_hda
snd_hda_ext_core
snd_soc_acpi_intel_match
snd_soc_acpi
snd_soc_core
snd_compress
snd_hda_intel
snd_intel_dspcfg
snd_intel_sdw_acpi
snd_hda_codec
snd_hda_core
snd_hwdep
snd_pcm
snd_timer
snd
On Debian 12 sound worksfine.
2)
On intel i5 7th generation machine:
I think delgado is right with his assumption and the nvme has a sata interface, laptop is about 7 years old. Model name is HFS128210A
Again, Debian 12 has no problem with naming, nor does Devuan 2, 3, 4.
I use Devuan since Vs 1 on that laptop
Best regards hellou
Offline
1) make another thread for this, and use code tags.
2) use partition UUID or filesystem labels.
Online
Tested the devuan_daedalus_5.0.1_amd64_netinstall.iso in a VBox VM overwriting an older installation.
Successful efi installation with Acceleration - Paravirtualisation = none.
Offline
The 5.0.1 Release doesn't solve my problems with Supermicro servers. Same behaviour, install medium is not recognised as UEFI boot device in boot menu.
What's worse: I've got now the first batch of servers on my desk that don't have BIOS boot at all any more. These machines are pure UEFI machines that don't even have legacy option roms or CSM support any more. They absolutely need a proper GPT partition map in order to boot at all. I'm totally screwed there.
Example: https://www.supermicro.com/en/products/ … 0d-8c-fn6p
I wonder why there is a problem anyway. Debian Bookworm does it right, so Devuan could just copy the Debian procedures verbatimly 1:1, without having to fix Syslinux etc. Or just do it like the 4.0.0 release media - they do work.
Frank-Christian
Last edited by fchk (2023-09-23 16:25:58)
Offline
Security
HardwareTrusted Platform Module (TPM) 2.0
Silicon Root of Trust (RoT) – NIST 800-193 CompliantFeatures
Cryptographically Signed Firmware
Secure Boot
Secure Firmware Updates
Automatic Firmware Recovery
System Lockdown
It may be something to do with the above security 'features' - maybe try removing 'secure boot', or possibly that TPM module(?).
Offline
It may be something to do with the above security 'features' - maybe try removing 'secure boot', or possibly that TPM module(?).
Secure Boot is disabled. Debian 12.1 just installs fine.
Frank-Christian
Offline
Hey all,
During the following week I'll have time to shuffle some machines and hard drives here and go through some detailed tests to try and reproduce what I can in the remaining install ISO issues, or analyse possible reasons for cases where outcomes differ between Bookworm and Devuan. I'm wondering if graphics modes might be related.
fchk: The supermicro case is particularly curious. Same make and model USB stick for both Debian and Devuan images? Booting from same USB port?
hellou1: For the i5 with intel sound and video drivers - on a similarily old laptop I've had to manually mess with firmware to get things to work with Debian 11 and prior - but if your issue is similar that case would probably be an issue outside of the scope of the installer. Daedalus worked right away but this was a different install method. I will double check a full Deadalus ISO install though to see.
I will report back.
Offline
fchk: The supermicro case is particularly curious. Same make and model USB stick for both Debian and Devuan images? Booting from same USB port?
These servers have an Aspeed IPMI controller for remote KVM (basically hardware VNC), and you can upload an virtual Floppy or CDROM image. The IPMI processor is an USB device to the PC and then acts as an USB Floppy or an USB CDROM drive.
Devuan 5 is the only distro I've ever had problems with. Neither Debian or Devuan 3 and 4 had any problems.
Frank-Christian
Offline
@fchk, if a 5.0.2 ISO with proper GPT saw the light of day, would you prefer it being netinstall, server or desktop?
Online
@fchk, if a 5.0.2 ISO with proper GPT saw the light of day, would you prefer it being netinstall, server or desktop?
I'd prefer desktop.
Thanks.
fchk
Offline