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.

Given that a .deb file is an ar archive file containing two .tar.gz files it might be within scope for you to repackage things yourself.

Well, no @Danielsan, you did not post output of ln -l /dev/disk/by-uuid

Kind of looks like something pre-grub tries to access the partition while the partition uuid is encypted.

Maybe ls -l /dev/disk/by-uuid or blkid would help identifying which partition it concerns.

Yeah, I'm guessing that when Microsoft bought github, they thought that people would show a "convenient mix of lazy and stupid" and pretend for themselves that Microsoft, by keeping keeping github services kind of the same at least initially, supports FOSS.

@MrReplicant, being defensive about sound behavioural advice won't serve you well in the long run.

Just to be petty: I think you really should have understood the sheer stupidity of including post #2 in post #3 especially when post #1 also was yours.

You see, a forum thread is generally intended to be a public group discussion where people advance the opening topic through a succession of discussion points adding expansions, explanations and viewpoints. It's not intended to be like a chat room with a series of (public) one-on-one exchanges. Hijacking the thread for a completely different topic, like we do here, is also very bad form.

It means in particular that each post implicitly concerns the thread topic as a whole. When you want to attach a note to something particular of a prior poster it might warrant  quote, but in general one would only use quoting for the purpose of remarking on or highlighting the particular choice of words rather than the semantics.

And, there is never any need to quote a whole post like you did in post #3, since you would then rather refer to it by its sequence number.

In any case, I should also thank you for opening this opportunity to make this kind of public statement about that style of posting that had started to infect this forum. It will be interesting to see how that pans out in other topics in the future.

Fair enough. You haven't said there is an issue.

You merely show that with apt preferences set up so as to not install dbus, then apt will not install anything that declares it depends on dbus.

What's the output of apt-cache policy dbus for you?