Ok, yes that would be the isolinux (syslinux) menu. That boot case is supposedly the same for the daedalus iso although the actual boot menu is slightly different.

But it also depends on whether the legacy bios sees the USB as a cdrom at /dev/sdX or as a bootable partition at /dev/sdX1. There is then a slight difference between the chimaera and daedalus isos in  that the type code for the first partition is 0x00 (Empty) for the chimaera iso and 0x11 (Hidden..) for the daedalus iso. Possibly that difference is what causes your bios to treat them differently.

The upcoming rc4 will be "corrected" to use 0x00 as type code, and in addition include further changes towards handling Andre's use case.

@Andre4freedom before we close of "missing module" as reason, would you mind posting output of lspci -v from your Alma-linux. (That should tell explicitly which modul(s) are in use).

EDIT: actually, now I realize the installer pre-boot doesn't have ehci-pci (nor ohci-pci) which I think means it doesn't support USB2 or USB1. That's not ideal. Looks like there is an rc4 coming up shortly for that...

I assume you still see the bootloader menu?
If so, try by pushing TAB, then remove "nomodeset" and then push ENTER... does that start up the installer?

If you don't seen the bootloader menu then the problem is at the ISO format level. That's a bit harder to debug.
Does chimaera netinstall work for you?

Note: the dd command of post#4 above is typically good, though I think there might be bogus variants of dd on some (non-linux) platforms.

Thanks. Good information showing "normal" hardware, but I need more

In summary it seems that machine is able to load the pre-boot system if booted in UEFI mode, but not if booted in legacy mode. (is that correct? or does the installer start equivalently in legacy mode?)

One of possible reasons for such an outcome is if the USB stick requires a kernel module (device driver) that is missing from from the pre-boot system, and that is the information I am looking for.

For example, what does the Alma-linux system log say when the USB stick is inserted? Which kernel modules get loaded?.

Quite possibly we could turn this into a useful bug report; just describe in some detail which media you used and how did you prepare that? A memory stick or an actual CD? I assume you verified the sha256sum, but it's good if you confirm that.

EDIT: I seem to have ignored the title.. a USB would be a memory stick...

So how did you prepare it?

Could you run again and use the emergency shell to report the output from ls -l /dev

If you can install another USB stick, you could mount that and then copy /var/log/syslog to it, and put that into a code block of a post here.

what's the output of

# rfkill

(install it if you don't have it)

It is worth to highlight that the ramification of changing the "meaning" of "/bin/sh" is much larger than merely saving the typing of  two characters more in new bash scripts.

The "/bin/sh" binary is the most fundamental pathname of a GNU/Linux system since that binary is the one used by the execve system call. It affects all system scripts from top to bottom, from the very boot up of the system. So one must be very sure that the "new meaning" (bash) of "/bin/sh" is fully equal to the "old meaning" (dash) in terms of script interpretation for all existing "/bin/sh" scripts.

Probably "bash" is still a language superset of "dash". But "bash" has significant ongoing development and it is much more intended for interactive use. My worry would be that "bash" suddenly one day has a deviation from "dash" that makes a difference, possibly breaking my system in some obscure way.

Maybe clip out the two partitions into their own image files, and see if the file command tells... EFI partitions would be fat... with mtools you'd do

mdir -i part1.img -a

to see the files in that.

EDIT: I guess you know, but the clipping out would be dd commands like

$ dd if=sdc64gb.img of=part1.img skip=2048 count=32768
$ dd if=sdc64gb.img of=part2.img skip=34816 count=124700639

NI web search result: https://ffmpeg.org/ffmpeg-formats.html# … gment_002c

enjoy.

Thanks.

Yes, that installer is missing libgcc_s.so.1 (due to an undeclared dependency).

New ISOs are in progress that should be better in that, though you still need to add nopat by hand; that issue seems to be limited to virtualbox with EFI and it's not yet confirmed to be a universally useful fix.

No my issue was different.

I'm not sure what it is, @rolfie, but it all seems to work on virtualbox if you add 'nopat' to the boot command line (push 'e' at the startup splash, then add 'nopat' to the 'linux' line and boot with '^x').

This is regardless of whether the ISO file is writable or not.

Afaict that 'pat' feature is something new for the kernel's memory management and apparently some module(s) are not fully revised and tested with respect to it. Using the 'nopat' option presumably makes the kernel use different code paths that get around this.

Also, a similar issue turns up with EFI in qemu ... I can explore that myself