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.

See https://wiki.debian.org/DebianRepository/Format for details.

You may browse the ISO to find out whether or not firmware is there. Though even if so it obviously wasn't loaded "automatically".

It may be worth to note, that all Devuan installer ISOs still come with all firmware in the ISO pool, for installation.

The ISO also has a top level /firmware directory with links to the actual firmware packages within the ISO pool, although that (i.e. having links) doesn't actually work with some CD drives. There have further been some number of installation systems where the installer fails to find the firmware for one reason or another, typically because it fails to mount the ISO. In that case it's handy to have it available on something that can be mounted.

Nowadays (daedalus) non-free firmware packages have been moved into a non-free-firmware section rather than as  previously being in the non-free section.

But that doesn't change the principle that all ISO includes all firmware packages on the ISO. Instead the ISO has that section as well as any firmware still in non-free.

Sounds like the kernel of the installer cannot handle that GPU. As @fsmithred says, try changing the vga= parameter of the boot line; see eg https://en.wikipedia.org/wiki/VESA_BIOS … de_numbers for options.

EDIT: as a fyi note, although the Devuan installer uses the debconf installation principle, which is the same principle used in the  debian-installer package/project, the ISO building is by different software (https://git.devuan.org/devuan/installer-iso). The Devuan installer only offers the text mode process, and it does not include the gtk mode process.

The installation principle is to boot up a generic kernel+initrd (the installer) and then expand that by loading modules from the ISO appropriate for the target system while stepping through installation until there is a target filesystem set up. At that point, it runs debootstrap for a base system, transfers the so far captured setup details, and then starts installing packages via a chroot into the target system. It's the packages themselves that provide the second part dialogs through their postinst scripts.

I suppose this particular issue concerns the installer's kernel+initrd and how it interacts with the GPU.