It's probably been close to a year since I've tried the nvidia driver on this rig (GeForce 210). I didn't have any trouble installing it. I did have to specify using an older version of gcc to match the one used to compile the kernel, but that's normal, and the installer will tell you if you have a mis-matched gcc.

I see same version of libc6-dev in devuan and debian jessie.

 *** 2.19-18+deb8u10 0
        500 http://pkgmaster.devuan.org/merged/ jessie/main amd64 Packages
        500 http://pkgmaster.devuan.org/merged/ jessie-security/main amd64 Packages
        500 http://auto.mirror.devuan.org/merged/ jessie/main amd64 Packages
        500 http://auto.mirror.devuan.org/merged/ jessie-security/main amd64 Packages

Parrot is based on buster. The devuan equivalent is beowulf, but there are no beowulf repos set up yet and no work done on buster/beowulf versions of software. That would account for "breaking things all around."

Here's something you could try if you have a few spare GB of hard disk space...

1. Get Parrot Now, install it. (is is even supposed to be installed?)
2. Don't update it, and wait until we have beowulf repos up and running.
3. Upgrade it to devuan.

Another option would be to get the package list and try to recreate it in devuan.
From within a running parrot session, run dpkg --get-selections > parrot_package_list
It might even be possible to recreate it in ascii (or get something that's close to the original.)

When you are in the process of booting devuan, the filesystem that holds the devuan kernel is not mounted on /media/username. You need to tell the bootloader the location of the kernel before anything is mounted.

I don't think the lack of an initrd in salix should have any impact on devuan. Lilo is happy to boot an OS with or without initrd. It's just a matter of getting the stanza right.

If you're using gpt with bios, the procedure is slightly different. You may need to do the following steps first.

https://wiki.archlinux.org/index.php/sy … tion_table

Then follow the instructions in the first post, except for the dd command.
Change the following

dd if=/usr/lib/EXTLINUX/mbr.bin of=/dev/sda bs=440 count=1

to this:

dd bs=440 count=1 conv=notrunc if=/usr/lib/syslinux/mbr/gptmbr.bin of=/dev/sda

If you want to use UUID instead of device names in the menu, edit the 'append' line to replace

root=/dev/sda1

with something like

root=UUID=xxxxxxxxxxxxxxxxxxx

(replace xxxxx... with the correct uuid.)

The first checkbox adds the primary user to the sudo group.
The second checkbox does the above and also disables the root password and edits two files in your home so that admin apps will ask for your user password instead of a root pass.

~/.gconf/apps/gksu/%gconf.xml
~/.su-to-rootrc

I don't have a good answer for your second question, but I have seen similar behavior - apps requiring root privileges either won't start from the menu or if the user is in the sudo group, those apps start without asking for password. Here's one of several discussions about it. To find more, search the forum for terms like policykit, polkit, consolekit, udisks, libpam.
https://dev1galaxy.org/viewtopic.php?id=675

One workaround would be to edit the .desktop files for the affected apps. For example, edit /usr/share/applications/synaptic.desktop and change
Exec=synaptic-pkexec
to
Exec=gksu synaptic
or something like
xterm -e 'su -c synaptic'

This might also work (please let me know if you try it.)
sudo synaptic

If/when gksu goes away, you can edit the Exec line in the .desktop file to use xterm. For example:

Exec=xterm -e 'su -c synaptic'

An xterm will pop up to let you enter the root password.

I can't explain why it would be gtk3 related, but I can offer a way to test that theory. Here's a yad package compiled with support for gtk2 instead of gtk3. Install this one and see if it does the same thing. (sorry, no i386 package)
http://distro.ibiblio.org/refracta/file … _amd64.deb

Sorry to say that palemoon is not in the devuan repo. You're getting a false positive.

Your system:

palemoon is already the newest version (27.7.2~repack-1).

My system:

palemoon is already the newest version.
$ apt-cache policy palemoon
palemoon:
  Installed: 27.3.0~repack-1
  Candidate: 27.3.0~repack-1
  Version table:
 *** 27.3.0~repack-1 0
        100 /var/lib/dpkg/status

Different versions, but in each case it's the newest version that apt can see.

I've thought about adding extlinux support to refractainstaller, but I didn't think there was much interest. Nice to see that there is. I've also thought about adding support for grub to refracta2usb. Maybe those things will actually happen some time.

So, uh, what is /usr/src/refracta-tools and where did that come from?

It's safe and normal to have multiple versions of gcc. If you upgrade from one relase to another, you will accumulate versions of gcc. In fact, I've usually found it necessary to have multiple versions for properly compiling modules - debian typically ships with a version of gcc that's newer than the one that was used to compile the kernel. The proprietary nvidia installer complains if there's a mis-match of gcc versions.

Looks like there's a newer version of 4.9 in jessie-security:

~$ apt-cache policy gcc-4.8
gcc-4.8:
  Installed: 4.8.4-1
  Candidate: 4.8.4-1
  Version table:
 *** 4.8.4-1 0
        500 http://pkgmaster.devuan.org/merged/ jessie/main amd64 Packages
        500 http://auto.mirror.devuan.org/merged/ jessie/main amd64 Packages
        500 http://debian.csail.mit.edu/debian/ jessie/main amd64 Packages
        100 /var/lib/dpkg/status

~$ apt-cache policy gcc-4.9
gcc-4.9:
  Installed: 4.9.2-10
  Candidate: 4.9.2-10+deb8u1
  Version table:
     4.9.2-10+deb8u1 0
        500 http://pkgmaster.devuan.org/merged/ jessie-security/main amd64 Packages
        500 http://auto.mirror.devuan.org/merged/ jessie-security/main amd64 Packages
 *** 4.9.2-10 0
        500 http://pkgmaster.devuan.org/merged/ jessie/main amd64 Packages
        500 http://auto.mirror.devuan.org/merged/ jessie/main amd64 Packages
        500 http://debian.csail.mit.edu/debian/ jessie/main amd64 Packages
        100 /var/lib/dpkg/status

After our previous exchange, I checked my laptop, and the default governer was powersave. Good for a laptop, but that's where I build isos. Been using cpufrequtils since then, and I just now installed and tried linux-cpupower.

cpupower set -b 0 gives me slightly higher speeds than cpufreq-set -g performance but in both cases, speeds drop at idle. I don't know if recompiling the kernel without the governers is necessary or even possible or if it would work. You might be able to just unload the module(s) to get constant full speed.