FYI, setting the pass field to '0' will cause startup filesystem check/repair (if needed) to be skipped, this may or may not be what you want.

Nah, the question (is it one question or two? Internal or external drive? Which "file manager"?) is just vague, as usual.
The "automatically" in "automatically and without superuser password" kinda implies "without user action", hence myself (and chumpGPT) heading toward /etc/fstab.

Possibly. I vaguely recall gparted having an option to set a mount point (or maybe that was KDEs 'partitionmanager'), but that won't be any kind of "flag" set on the partition - it's offering to modify /etc/fstab for you.
I've never used it, and frankly I wouldn't trust it to not make a mess in my nice readable column-aligned file.

Don't mess with the line for the root filesystem, and it'll be fine.
Even if you did somehow manage screw that up, such things can be fixed by chrooting in from a livecd or the install media (as can 99% of "unbootable" situations in general).

Why are you asking a large language regurgitaion model for information that is readily available with a 15 second web search, or locally with:

man fstab

and

man mount

?
Fstab syntax is not complicated, and examples are all over the 'net.

For most purposes:
* Create a directory to use as the mount point and check/set permissions.
* Edit /etc/fstab to add a matching line, where the (space separated) fields are:
[device] [mount point] [filesystem type] [options] [dump priority] [check priority]
* Test that it works as intended with 'mount [mount point]'.

The first field can be a traditional device node (e.g /dev/sd[x][y]), any symlink under /dev/disk/by-[whatever] (e.g. /dev/disk/by-id/[drive model and serial number]), a 'UUID' tag (e.g. UUID=[filesystem UUID]), or a 'LABEL' tag (e.g. LABEL=[filesystem label].
Note that /dev/sd[x][y] names are assigned in the order the kernel detects devices, so they may shift around. That's why many examples prefer UUID, but there are several other options.
If you want to use UUID, you can print it with 'blkid -o value -s UUID [device node]'

Mount point can be any directory you like. Preferably an empty one, as mounting will "overlay" existing contents making it inaccessible (well, mostly, but that's into the weeds).

Filesystem type is self-explanatory, or 'auto' if you're lazy (or like to swap drives around).

Available options are explained in the mount manual, fstab takes the same format as the '-o' command-line option for the mount command.

The last two fields determine the order filesystems are dumped (don't worry about it) and checked. For non-root filesystems the usual is '0 2'.

** In case it's not obvious, where I say [foo], you're supposed to fill in your value and drop the enclosing [].

A couple of random examples from my systems, I prefer labels to UUIDs:

LABEL=spool    /mnt/spool    ext4    noatime    0    2

Unless it's a hotswap bay and I want to identify it by a specific SATA port, so any disk I put in it mounts at the same place:

/dev/disk/by-path/pci-0000:00:17.0-ata-1-part1    /mnt/bay1    auto    user,noatime,noauto,exec    0    2

If you mean polkit rules or fstab... They're answering different questions, because there are (at least) two mechanisms for "automatically" mounting filesystems.
/etc/fstab is system level, and is processed before any user logs in. If the filesystem is permanent and you want it always mounted regardless of what user or environment you are using, this is the most reliable method.

Polkit rules are used to allow an unprivileged user to mount things that are not in /etc/fstab, or things that are in /etc/fstab but don't have 'user' in the options field (since either of those scenarios would normally require root permissions).
Polkit is generally only used by graphical desktop/file managers, (i.e. not by the 'mount' command at the CLI), and will only help with "automatic" mounting if your GUI or file manager of choice has a facility of its own to "remember" mounted filesystems and re-mount them at login.

Filsystem uuids will end up in in grub.cfg if you use grub-mkconfig / update grub and haven't set GRUB_DISABLE_LINUX_UUID=true, and GRUB will pass them to the kernel and initramfs before fstab is read.
Partition and disk uuids are, as you say, irrelevant (unless you specifically choose to use partuuid as a search hint for grub)

It's proprietary, so who really knows?
"Negative feelings" about closed-source browsers and packages that are not compliant with Debian free-software guidelines or packaging policy, on the discussion board for a Debian-based FOSS distribution, are not particularly surprising.

That's really not a very high bar to pass, typhoid is "no worse" than lung cancer, but I for one don't want either.
Brave and the like are at least open-source, so any dubious "features" are readily inspect-able.

Everything is inline in the package postinst script, the repository configuration and key signature (base64, for reasons) are piped into the config files... Because of course that's how they do it - it's the best way to fuck around with the system (making sure their browser is the very highest priority in alternatives for example) and "support" multiple distros with a single .deb.
The crontab file is a symlink to /opt/vivaldi/cron/vivaldi, which is a copy-paste from the postinst and apparently rewrites the apt configuration and keys every day... Again, reasons, presumably.

Proprietary vendors are all the same when it comes to packaging, total disregard for established standards. Everything that can be an executable script is, windows lets vendors screw around however they like and execute whatever they want so that's how it must be done everywhere.

OP has 3 topics at this point, all whinging, and all full of the above.
Apparently any configuration choice (so far: root filesystem, partition layout, network configuration tools, boot media, DNS server / protocol, terminal emulator) that doesn't perfectly align with their preferences is some sort of "showstopper" disaster and/or conspiracy.

Is for you to:
a) Grow up, and realise that this is not Arch, it's a stable, general purpose distribution under no obligation whatsoever to embrace the newest shiny thing or cater to your peculiar tastes.
b) Post your commands and any "bunch of cryotic[sic] errors" encountered, verbatim and without shouting. Assuming you actually want assistance that is.

No, this is a bunch of whining and factually incorrect nonsense. Bug reports are submitted with reportbug or by email.

Specifically, no. I never cared enough to look into it. More generally:
There are about 50 different ways to build a bootable hybrid image, and most of them rely on the initramfs being able to find and loop-mount the image somehow.
That mechanism (and what kind of device and/or filesystem is searched) varies widely from one distro to another. They are looking for their image in their format on their filesystem... Not whatever "USB Maker 3000" decided to do.
Ventoty has a bunch of special-casing hacks to make this work, just not for Devuan.

The image boots fine from a raw device as intended, so this is a Ventoy problem for Ventoy to fix... If anyone actually cares that is.
Multi-boot USB drives are a hack, they've always been a hack, and it's not really on iso builders to pander to them.

Sure, but you'll need better bait to nerd-snipe me on that one. Bootloaders and initramfs scripts are tedious to test at the best of times, and 'need install media (once every 5 years at best)' x 'too lazy to fish out an old  $2 4GiB USB' = 'nanoscopic fleck of motivation'.

Bullshit.

Complete and utter bullshit.

Yes.

The installation image is ISO-hybrid, you're supposed to write it directly to a block device.

There's wrong, and then there's fractally wrong.

You are mistaken. Follow the instructions and write the .iso to an unformatted raw block device or optical media with dd or wodim.

If you insist on doing your own thing WRT install media and filesystems, because "other distros, blah, blah", that's up to you... And you get to keep all the pieces when it inevitably doesn't work.

Main memory latency is measured in nanoseconds, while even the fastest NVME SSDs are in the tens of microseconds. On older storage technology the gap is considerably larger.
An order of magnitude is "not noticeable"? That must be why Solaris started putting /tmp in RAM around 1994.

We're talking about Debian turning this on by default, not forcing you to use it. The vast majority of Debian (and GNU/Linux in general) deployments are servers, where 32GB is generally considered low-end. Setting the default to suit that use case while having minimal impact** on everyone else is perfectly reasonable.

Most mobile phones have more than 4GB of RAM these days, if you want to use antique hardware, that's cool... But expecting defaults in a general purpose distro to be tailored for that is ridiculous.

**
Devuan server, manual max size set, 38MB used:

tmpfs            2.0G   38M  2.0G   2% /tmp

Oh noes, 0.03% of precious RAM wasted on my 14 year old hardware.

My Gentoo desktop does not currently have /tmp in RAM, because I have a tendency to compile stuff there and old (bad) habits die hard.

It's optional, same as it always was:

# mount /tmp as a tmpfs.  Defaults to no; set to yes to enable (/tmp
# will be part of the root filesystem if disabled).  /tmp may also be
# configured to be a separate mount in /etc/fstab.
#RAMTMP=no

They "come up with this", because it's a thing many other distros do by default and many users used to do manually, which reduces SSD writes and improves latency for applications that make frequent use of /tmp.

"50% of my ram" is a default upper limit, actual memory consumption for tmpfs (unlike a traditional ramdisk) is dynamic.
On most systems /tmp is only a few MiB, and has negligible impact on available memory. If you want to stash huge files there for some reason, simply disable or configure it to your liking. See man tmpfs(5). Note that as per FHS, /tmp is not expected to survive a reboot either way.

/lib/init/tmpfs.sh, which is called from /etc/init.d/mountall.sh, which is illuminated by a couple of seconds with grep. I'm not sure what the big mystery here is.

"Quality control" WRT Debian and/or Devuan releases isn't about upstream software having bugs or not... It's whether buggy upstream versions are packaged for stable.
This is why we have the unstable -> testing -> stable workflow - packages that have serious bugs shouldn't be making it through testing... And they sure as hell shouldn't be the first thing a user interacts with in a release livecd or default install.

This particular bug in SLiM was raised in the excalibur RCs, and hasn't been satisfactorily addressed (nor has the one I reported). Those bugs existing is on upstream, but SLiM still being the default greeter despite them is a Devuan decision, and by extension, a Devuan problem.

Upstream bugs are not a distribution issue. Software selection, packaging, and sane defaults are.
If Devuan wants to package a different default desktop setup from Debian, the lack of QC on that setup is not something that can be blamed on Debian.
They use lightdm for their XFCE live image, did anyone think to ask why, or are we all too busy trying to deflect blame for the rushed, poorly tested, perpetually janky live releases?

SLiM is a mess, and has been for years. Stop using it as the default greeter. Problem solved.