You do not need to be root to use pmount.

Make sure you're a member of the plugdev group. Run groups to see what groups you're in. If plugdev is not listed, then run as root, adduser keos plugdev

Then the user must log out and log in again.

I'm not implying anything, and there's nothing in my posts to even remotely suggest that. Most of this thread consists of reporting and comparing observations, with documentation. This is normal problem-solving behavior. Jumping to conclusions doesn't solve anything.

jimmyjhn suggested in his last post that there was a recent change in the repo. He's right.
Here's the answer: https://dev1galaxy.org/viewtopic.php?pid=9636#p9636

I can also state that I recall someone bringing this to our attention in irc a few days ago.

I was using this when I posted before.

deb http://pkgmaster.devuan.org/merged beowulf main contrib non-free

and then I also tried https:

deb https://pkgmaster.devuan.org/merged beowulf main contrib non-free

I also have ascii, ascii-security and ascii-updates with same address (pkgmaster). The system is ascii. Beowulf is only used to check versions, but I did install something from beowulf as a test. No errors with apt-get update or apt update.

When you get to that window that won't let you do anything, press TAB and it will highlight the 'OK'. Then you can press Enter and it will bring you to the next screen.

Use TAB or arrow keys to navigate in debconf screens like that one.
Use Space Bar to select or unselect items.

That does help, thanks. You definitely installed from the desktop-live. If you booted into Italian, then any system messages would be in Italian. The English parts are from the installer script. The debconf dialogues for locales, tzdata and keyboard would have been in Italian, too. I can see that those ran correctly this time. I don't know why they didn't work for you the first time.

I'm still trying to figure out what installer you used. The one I wrote and maintained does not have any translation files. That's the only installer on the desktop-live iso. There are two versions of it: refractainstaller-yad, which starts from the desktop icon or menu and has a graphical interface, and refractainstaller, which runs in a root terminal or console.

If the installer gave you instructions in Italian, you must have been running the regular debian(devuan)-installer, which can only be started from the boot menu of the installer isos. (not the live isos).

Regardless of which installer you used, the dialogues for locale, timezone and keyboard should have come up at the beginning of the installation. If that did not happen, then yes, there is a problem, but you're the only one who has encountered it. More information would be needed to figure out why that happened.

You must use dist-upgrade or the equivalent (aptitude full-upgrade) to get to the next release. Warning: pinning ain't what it used to be. Stuff that's blocked on install is not necessarily (or maybe not at all) blocked on dist-upgrade. I've seen libsystemd0 come in like that on upgrading from jessie to ascii.

Yes, I experienced this on upgrades from lenny to squeeze to wheezy to jessie to ascii. I don't recall what happened from sarge to etch to lenny, but I'll bet it was similar.

The correction you requested:
While I have made a few experimental isos that started with a debootstrap install, I usually start with a netinstall iso and un-check everything except standard system utilities in the tasksel window. Add the cli refracta tools and make some config changes, and then make the no-X iso. 

For the desktop iso, I start with an install from the no-X. That way, I still have both systems and can update both no-X and desktop isos.

...and the one you didn't:

Older versions of refractasnapshot used the isohybrid command from isolinux. More recent versions make the isohybrid as part of the xorriso command.

I like the idea of changing an existing iso. David Hare (dzz of Exegnulinux and Refracta) wrote a script to do that, and that script was included in refracta8 (jessie). I should make sure it still works and include it in refracta9.

remaster-snapshot does the following:
# Four stages (script will execute one selected action only then exit):
# 1. Extract and unsquash a live-cd
# 2. Chroot the unpacked system with appropriate bind mounts
# 3. Prepare for "live" use and squash the unpacked system
# 4. Build a new ISO

Another place to customize a system is during the installation. Refracta installer has a point where it pauses to allow you to chroot into the installed system and make changes. You can edit configs and add or remove software at this point. (Note: you could also do those things in the live session, before running the installer, but adding software would use up a lot of RAM.)

Yeah, something is weird. I don't know what. I just tried it on four different systems, and in all cases, vlc will get upgraded. One system was installed by debootstrap last fall, has no task-* packages and has Recommends excluded. The other three were desktop-live isos - one from February, the official beta and the official rc.

What about the first command I suggested? Does it give you any useful output?

No, don't re-do your install. If you do, you'll get the task- package, and that might get in your way if you want to be selective about what parts to keep. (Try to remove one piece that the task package depends on, and your entire desktop goes on the autoremove list.)

I don't know if anyone gave you this link, but here are Irrwahn's instructions on which polkit libs you need:
https://dev1galaxy.org/viewtopic.php?pid=8217#p8217

Well, if you had a different desktop, it would be the right polkit. Maybe it would have worked better if you installed kde first. Not sure of that. If you choose kde from the installer, it installs task-kde-desktop, which would pull in the right libpolkit packages. But if you install the plasma-dekstop parts without the task- package, you get whatever kde thinks it should have.

I think I see the problem. Instead of depending on consolekit, it should probably depend on consolekit or elogind. But lightdm is not one of the packages that we change.

A bug report to devuan might be good to remind us that it's a problem, so that the solution becomes common knowledge. It also might motivate someone to fix it.

I have no idea what a bug report to debian would do. Theyre probably not interested in making a package depend on a package that isn't in their repo. (i.e. elogind)

# apt-cache depends lightdm
lightdm
  Depends: adduser
  Depends: dbus
 |Depends: <libpam-systemd>
    libpam-elogind
  Depends: consolekit
 |Depends: lightdm-gtk-greeter
  Depends: <lightdm-greeter>
    lightdm-gtk-greeter
    lightdm-kde-greeter
<snip>