Run apt update once and confirm.

EDIT for some background: The root of this problem is that the InRelease file for debian-security previously had the wrong "Label" setting of "Devuan Security", and that is what has got loaded onto your system while updating devuan-secuirty before while in testing.

Apt keeps a copy of all the "dists" files, such as

/var/lib/apt/lists/....InRelease

and it's that file that has

Label: Devuan Security

on your system, whereas the one in the remote repo was corrected to have

Label: Devuan-Security

when also it changed to

Suite: stable-security

That is what the Apt system (by apt-get) discovers and complains about. The apt program does the same, but then reacts by asking you to confirm that the new file is good rather than  just discarding it.

@abd, perhaps you can enter an Alt-F2 shell, then capture and send the output of blkid and fdisk -l for me.

Note that the ISO has a first partition that "spans the whole drive", which in particular includes the partition table. If you then mess with the partition table, it upsets the recognition of that partition as an iso9660 filesystem, and the installer might not be able to mount it.

EDIT: in short, where the dialogs for manual selection of media ask for module and device, choose "none" for additional module, and use the device node name from blkid, for the first partition of the device with the ISO image.

That was a bit cryptic.

Do you mean that you did have "stable" or "testing" in your sources.list but you don't think of that as foreign repos?

Ok. Apparently the partitioner picks up all swap partitions (can't see sdg3 but taht'd be another swap partition). It should be possible to avoid that by deslecting those ("don't use this partition") via that previous dialog.

Looks funny yes, but it's hard to know what is happening when you start partitioning the installer disk, whose first partition (which spans the whole image) is mounted at that time.

Generally it's not a problem for the installer to install onto any other disk, whether USB or not, but installing over itself is probably stretching it too far.

If you for practical reasons or whatever really need the installed system to replace the installer on that USB, you need to exercise a fair bit of commandline fu to make that happen; e.g. by setting up an nbd disk image in RAM to install to, and then copy that onto the USB just before reboot... (not something I've done, but it could be fun )

... or maybe I have misunderstood your use case?

Misspelling; should be qemu-system-x86_64

Thanks. yes that's good confirmation.

The USB problem case came up because the "installer pre-boot" (on those isos) is insufficiently stocked with kernel modules, so it fails to operate that device to find the "actual installer". The onwards iso building is revised to comprehensively include all (current) block device options.

@sgage thanks for those.

It's quite peculiar that the chimaera and daedalus isos have different legacy boot behaviour since they supposedly are the same for legacy boot.

They do differ in UEFI boot loading where chimaera iso has grub whereas daedalus iso has syslinux.

Or, does the working chimaera iso come up as a grub boot menu for you?

Peculiar.
Would you mind booting up chimaera and show both ls -l /dev/ and lsmod from there?

Thanks!
Evidently the installer pre-boot is missing the scsi block device support.
There will be an rc3 drop shortly without that problem.

Yes I'll deal with reporting.

Which hardware is this?

EDIT:  Also, in the emergency shell: run "fdisk -l" and capture that output (too).

Sorry, I only use traditional ifupdown for my networking, and since you mentioned editing /etc/network/interfaces I thought you did the same.

By the looks of it the kernel recognizes the hardware. I would have thought the boot-up log would mention that hardware and which firmware gets loaded. At least there should be some mt7663* module loaded. You may check that with lsmod.

Surely someone that uses NetworkManager may have further ideas.