Not sure about Crowz, but Devuan has a Removable Drives and Media app within Settings. If available, this might help you influence how the system reacts when you plug in removable storage?

Otherwise, perhaps you could perhaps research mounting manually with "lsblk" (to discover what your drive shows up as), "mkdir" to make a mount point, and "mount" command to introduce your drive to the system.

For example (don't copy and paste my ramblings)
If "sudo lsblk" shows your drive is /dev/sdc, and the partition you want to access is /dev/sdc1
"sudo mkdir -p /media/sdc1" will create a mountpoint and
"sudo mount /dev/sdc1 /media/sdc1" should make the contents readable. (perhaps not writeable without changing perms)

Maybe.

Of course, if you already have another device mounted as /media/sdc1, that might be a sign you need to adjust some things. Or wait until someone who actually knows what they are talking about, responds.

Good Luck.

For the sake of good order, it would probably be a good idea to unmount with something like:
"sudo umount -l /dev/sdc1"
before ripping out the removable.

That sounds like quite good news. Even if it is not worth opening the champagne, perhaps it's worth a lick of the condensation from the bottle.

As you  and others have observed, to achieve the goal of contacting or managing a server from your desktop, you need both a) a server and b) a desktop. You seem to have both, but not at the same time. It seems a bit like an ancient fable or parable, and you have to decide which of your babies to sacrifice.

It might be time to for your project to move into an acquisition phase.  To get closer to the goal, you probably need another Machine, either 

• 1) Real Machine - that is, another computer.  Options at this stage include, but are not limited to, beg, borrow, steal, rent, dig out of your pile of old hardware, dig out of someone else's old pile of hardware, or, as a last resort, buy? We know nothing of your situation, or ambitions for the server.  Amazon competitor? Pi-Hole? Bare ssh server on a dead-battery 256Mb 800 MHz P3 laptop so you can boast "I ssh'd into my server today" ? All valid ideals.

• 2) Virtual Machine (as rolfie suggested.)  Many (Most?) modern PCs can handle this, it's not too complicated to check the hardware. Your PC seems to have a 500Gb disk, 8Gb RAM, UEFI....so that looks promising? My Chimaera 1C2T Celeron seems (barely) usable with qemu/kvm, at least.    There are other unreal computing options, such as containers, but that's a bit out of my range, and no-one else has so far leapt in to suggest it, so that might be more of a struggle to get help here.

Good luck with your decision-making and strategising.

A reinstall cures many ills, and the experience of how easy it is to make a mess, can be valuable.

Before you do that, and if any valuable data is safely copied off, perhaps you could try to fix some things? That could also be valuable experience.
In many, many more words than rolfie:

Swap file:

The swap entry in your /etc/fstab , specifies UUID. A UUID can change, for example when a partition is resized or reformatted. Reformatting is something that is often offered during the install process. Perhaps this happened to your swap UUID? This can perhaps be fixed:

Your lsblk suggests that /dev/sda3 is your swap partition. From root id, the command

blkid /dev/sda3

might tell you if this partition is formatted with a swap filesystem? If I ran this on my PC (I use sudo to run root commands...):

$ sudo blkid /dev/sdb2
/dev/sdb2: UUID="f460228e-8511-4656-8536-c2d65a7e3fd5" TYPE="swap" PARTUUID="ff55585e-aced-344f-86df-02259684ca4d"

If I ran them from root, as you seem to do:

# blkid /dev/sdb2
/dev/sdb2: UUID="f460228e-8511-4656-8536-c2d65a7e3fd5" TYPE="swap" PARTUUID="ff55585e-aced-344f-86df-02259684ca4d"

The TYPE="swap" tells me this is a swap filesystem. If it was something like "ext4" or "LVM2_member" then we may have taken a wrong turning.

You should be able to (after making a backup copy of your /etc/fstab file) paste the *YOUR* UUID entry into your fstab. It does not seem to mind the "" quotes, so you can probably copy and paste.  Carefully compare the new fstab with the old one, to make sure that the UUID is the only thing that changed. You can post a diff here, if you can wait for feedback. For example, assuming your backup is /etc/fstab.bkp.20230716

diff /etc/fstab.bkp.20230716 /etc/fstab

should tell us that there is only a difference in the UUID for swap. I have sometimes made a mess of editing a critical system file and been saved by a nervous diff.

If you are happy that the change is correct, you could reboot and see if the change is picked up. However, a mistake in editing /etc/fstab could cause problems; Luckily, to avoid the risky reboot, there is a command (from root) that should verbosely try to activate any unused swap partitions listed in /etc/fstab:

swapon -av

If the planets align and it all works out, your next free -h will show an active swap? If not, you could post the output of the "diff", the before "free", the "swapon" and the afterwards "free".

Good Luck.

Useful feedback, so here is my interpretation (Please note that I cannot claim to be an expert...there are many things I do not know, including EFI's workings):

I am not aware of any mechanism (other than some sort of virtualisation) which would allow you to run a local server "install" on the same hardware and at the same time as your "devuan desktop installation". My understanding would be that, on any particular PC, you boot into 1 install at a time. The others sleep. So you cannot ssh into them. Typically, I would expect that you make the choice about which one runs, at boot time, in the boot manager (Typically GRUB, perhaps LILO?).

Does your boot manager offer you choices? Sometimes it is hidden so as not to delay the boot process or confuse the user.

The lsblk "MOUNTPOINT" column suggests you have only 2 mounted partitions: /dev/sda1 (efi boot) and /dev/sda2 (the root partition).
The fact that this is mounted, suggests to me that this is the home of your main devuan desktop, which you report is Devuan 4 Chimaera.
The other partitions are not mounted, so they are not doing anything.

The "os-prober" you reported suggests that the boot manager setup detected 2 "foreign installs" :
/dev/sda4:Trisquel GNU/Linux 11.0, Aramo (11.0):Trisquel:linux
/dev/sda5:Devuan GNU/Linux 3 (beowulf):Devuan:linux

That suggest to me that the boot setup has tried to set these options up in the boot manager menu. Do you see them? 

Perhaps these also use the EFI partition....I suspect I will never understand this.

Less important:
I see no sign of a mounted SWAP partition.  If I had seen the text "[SWAP]" in the "MOUNTPOINT" column, that would point to a mounted swap partition.
Not a problem, just a comment. You might have a swap file in sda1 (unlikely) or sda2 (quite possible). I usually manage swap partitions in my /etc/fstab.

So, to check if the beowulf server is installed on sda5: Can you boot into it, from the boot manager menu?

I don't have any actual *knowledge* to offer, but perhaps I could fling some comments at the wall?

Do both the pendrives give that "Input/output error while closing the filesystem" ? Such a message could lead a suspicious person to suspect that the drive is failing. Admittedly it seems unlikely that 2 drives would fail at the same time, but perhaps if they were from the same batch, e.g. bought in the same blister pack? Then again....2 months apart is not exactly "the same time"

I tend to take the idea of a hardware failure as a personal insult, especially if it is something I paid my own actual money for. But it does happen sometimes. You might save yourself a lot of pain if you can accept the loss and beg/buy/borrow/steal another drive?

Is there a chance you could try with another kernel, perhaps an older one?

Another desperate clutching at straw: could it be a power issue, with something power-hungry using the usb bus? do you have a powered usb hub available for experimentation?

Could the usb socket be experiencing mechanical stress, perhaps with the laptop on a nonlevel surface (such as, to pick a random example, a lap) and the flashdrive sticking out of the side, brushing against couch cushions or blankets? Or perhaps you have the "bulky devices in slots that are too close together" problem? Perhaps you have another computer available for experimentation.

OK, getting more desperate....how is your environment for static electricity?

Good luck.

Sounds like this might be workable, but I was really reluctant to try working from an install usb/CDROM repo once "network-manager" was purged. And the

apt install lightdm slim-

tip worked very nicely indeed.

So, thanks to all the tipsters

I am not sure how the Debianness of the inheritance gets in the way of Devuan informing its users that the default browser is no longer supported, so they can make alternate, suitably informed plans?

In my limited and dimly-recalled experience of informing users of problems and issues, the task is a LOT easier if there is someone else (Firefox? Debian?) to blame. (Of course, that's probably not something I would have said out loud at the time )

Come to think of it - is this an issue with Chromium as well?

I wonder if we could have some input from Devuan's Powers That Be on this subject? It seems Debian and therefore Devuan can no longer supply a supported Firefox, and users who wish to keep up-to-date must make their own plans? This might well be the sort of thing the "News and Announcements" section of the forum was designed for.

I can't see an official announcement on this forum, so I hope I can use puma's thread to offer congratulations and thanks to the team.

Would I have to enter these commands on every machine in the network, including the ones I have forgotten about, and the ones without shells?
I admit, it would be effective if I remembered them all, but somewhat inconvenient.

How about "arping -c 10 -d <ipaddress>"  ?  I just read about it now and the man says:

       -d     Find duplicate replies. Exit with 1 if there  are  answers  from
              two different MAC addresses.

That looks very promising - is it solid and reliable?

How about sudo nmap -sn  <network>  ?

Maybe I will test these if I need to continue my investigating. I could put the phone back, and see if they sniff it out.

Of course, due to PEBKAC I only thought of dupips when I noticed the (forgotten by me) persistent address on my phone. I mean, what kind of sick, twisted mind gives a phone a static IP?

Thanks for the r8168 tip, I hope I will not have to investigate it further, but it's "good to know"

Perhaps of interest: If I remove eth0 from /etc/network/interfaces, give it to NetworkManager to manage via DHCP, and assign a static IP by reserving it in the router - that *seems* to work fine.  That's a rather embarrassing admission of failure, though. And easily forgotten as I cycle through my collection of junkshop routers as old age, lightning strikes and power surges cause them to shuffle off this mortal coil. And inconvenient if I have to reconfigure  BOINC, ssh, hosts.allow and shares.

I hope it won't come to that?