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

Note that there is a new installer ISO collection in progress, supposedly without this bug. It's expected to be available and mirrored in about 6 hours.

TL;DR: Basically the installer building had been changed from a simple strategic design into a series of specialized steps with the aim of addressing a couple of flaws that turned up earlier this year. This turned out to be broken fixing, and it's now reverted. And it appears those packages involved have been fixed up so ideally we are back on the mains street with the installer ISOs.

Right.

The file(s) with .shasum extension are actually text files with one line for each other file that it contains the shasum for (or sha256sum as is the case here). Note that "sha256sum" is just a checksum created by essentially adding the bytes of the checked file with some maths juggling so that the final "number" is a kind of fingerprint for it. Basically any change to the checked file would result in a different fingerprint.

So the .shasum file just tells what the checksum of the checked file(s) is supposed to be. You wouldn't really compute the sha256sum of those .shasum files... unless I suppose you want to compare different downloads of those .. and then "diff" or "cmp" would work as well.

The file ...shasum contains the sha256sum; you don't run sha356sum on it. E.g. download both, then run

sha256sum -c devuan_daedalus_5.0.preview-20230515_amd64_netinstall.iso.shasum

Note the -c.