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?

Not sure why your install has that issue; there should be an r8196.ko kernel module availabele on your system, and assuming that to be the module for handling RTL8111/8168/8411, the kernel should have loaded that.

Try with modprobe r8169 to see if it looks happier, and if that works, then add r8169 to your /etc/initramfs-tools/modules file before using the command update-initramfs -u -k all in order to prime your initrd to load the module on boot.

@Marjorie: I think it's slightly misleading to say that the kernel module is nftables; rather it's the netfiltering subsystem that is targeted by either (or both) iptables rules and nft rules. And the main change in iptables is in using the netfilter socket for its kernel interactions rather than ioctls that it used previously. I guess you are clear on this, but generally there's a lot of confusion on this topic.

Basically nft rules and iptables rules do the same things with different syntax. As far as I know they are alternatives for the same function, except that iptables allows use of ipset, which is something that hasn't got into nft yet.

@bai4Iej2need, you could also just install iptables, couldn't you?