Firstly, you have prepared the USB stick correctly. It does present itself as a disk image with two partitions where the first is an iso9660 partition (CDROM format) and the second is a FAT32 partition (also called vfat).

And the vfat partition is also an EFI boot partition that should be browseable with an EFI shell... are you able to do that?

I believe beowulf had a grub setup for EFI boot. Which files do you see in that partition with the EFI shell?

EDIT: yes, follow rolfie's advice..

update-rc.d $service $action

EDIT: I'm pretty sure there is a man page for it...

Mmm, I take it that you followed the instructions and verified that the network works, rather than merely just assuming that it works because "it worked before"?

If you do have that network connection verified with a positive ping response, then it would appear being either an intermittent problem (typically due to DNS failure), or an active TCP blocking (while allowing ICMP traffic) in between. You might need to engage your service provider for the latter.

I'd guess you a had a disruptive space on the linemaking it be "RESUME= none" .

Since the file gets processed as a shell script (i.e. sourcing it into the exection of /usr/sbin/mkinitramfs) you got to experience the shell script difference between the two lines lines:

RESUME=none
RESUME= none

The first line sets RESUME to "none" within mkinitramfs while the second line sets RESUME to  the empty string for a sub shell attempting to execute a program named "none".

It's a simple mistake to make and clearly the usability coefficient for initramfs-tools has room to be raised. In fact, one could say that that way of loading variables has big clown feets well into the security risk space.

Please show your file /etc/initramfs-tools/conf.d/resume.

Is there another file in /etc/initramfs-tools/conf.d/ ? If so, which, and please show it too.

What do people expect from going to Microsoft for software? Sanity?

Well, dbus service activation pre-dates systemd, but nowadays there's activation script mangling added... you can if you wish translate that systemd activation script into a proper dbus activation script and then get the normal dbus activation happening.

This forum does not offer inline display of images... or does it? Yes it does, if you have configured your profile thusly.

Click on the "Profile" link, then click on the "Display" menu entry and then decide about whether to set (or not) the toggle for "show images in posts", followed by a light poke at the "submit" button.

Right. Yes, I mistook it for full-disk encryption.

WIth only the root filesystem encrypted the kernel and initramfs would be involved. And it needs the initial udev run to handle USB; you've tried unplug + plug in while it's waiting for input?

Upgrade of kernel should not in itself have effects on the initrd except for possible differences in the module setup. Though there may be interesting effects in process handling, and especially in this case there is an inherent race between udevd handling USB and cryptsetup reading password.

You can investigate the race option by locating the cryptsetup invocation in the scripting, either "/etc/initramfs-tools/..." or "/usr/share/initramfs-tools/...", and introduce a "sleep 5" before it (then update-initramfs and reboot).

Apparently your system has older versions those packages, and your command asks for upgrading anything upgradable. You might try

$ apt-cache policy libjavascriptcoregtk-4.0-18 libwebkit2gtk-4.0-37

to get more information before accepting... or maybe that's too late now?

(I edited this post since my first suggestion was bogus)

The devtmpfs filesystem is set up and initially populated by the kernel, and that uses 50% RAM as its limit.

The first mounting happens in the initrd's init scripts which are provided by initramfs-tools at /usr/share/initramfs-tools/. In my case it's at /usr/share/initramfs-tools/init:36, where you may add a size=nnn limit. Then use update-initramfs so as to include your fix in the initrd, and then reboot. Perhaps like the following hands-on:

# sed '/devtmpfs/s|-o |-o size=100M,|' -i /usr/share/initramfs-tools/init
# update-initramfs -u -k all
# reboot

EDIT: This way worked for me and it's as early as possible (without rebuilding the kernel).

Sure does...

And you were right in that the libseat integration had lost the code path handling "devices added while VT inactive". I.e., the device got added "as per normal" and that of course failed upon opening file descriptor which resulted in Xorg dropping it. This lost code path captures the device when inserted, in a separate list, and then that list is used for "re-inserting" the device (as per normal) when VT is activated.

A patch for this is now moving through the QA and packaging steps. (step h)