You are not logged in.
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 PackagesFirst thing to try is adding 'nomodeset' to the linux line of the boot command. Press 'e' at the boot menu to edit the selected item. Don't make it a permanent change, because once you install the nvidia driver, you may need to boot without 'nomodset' to prevent the same problem you're having.
Also, if you changed the resolution in /etc/default/grub, you may need to put it back to 640x480. I think I had to do that on one box with asrock motherboard.
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.)
yad_0.38 for gtk2 debs here -
http://distro.ibiblio.org/refracta/file … _packages/
(The ones for jessie seem to work fine in ascii, so use the jessie build for i386.)
This one isn't in the sha256sum file on that page:
yad_0.38.2-1-gtk2-ascii_amd64.deb
2d0aa1dfd0a6f410e3e440fa36b875cea141ead16b2598655098e38570b013ea
image=/media/username/9d2c1561-d6d7-4651-9373-bcd440c289dd/boot/vmlinuz
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.
I was going to suggest that you get one working and then edit the boot menu manually. You beat me to it.
Maybe you need to change the path to the salix kernel to image=/boot/vmlinuz
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
GUID partition table
For a GPT, ensure bit 2 of the attributes is set for the /boot partition using gdisk. In other words, the "legacy_boot" flag must be set. Using sgdisk the command is:
# sgdisk /dev/sda --attributes=1:set:2This would toggle the attribute legacy BIOS bootable on partition 1 of /dev/sda. To check:
# sgdisk /dev/sda --attributes=1:show 1:2:1 (legacy BIOS bootable)
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=1to this:
dd bs=440 count=1 conv=notrunc if=/usr/lib/syslinux/mbr/gptmbr.bin of=/dev/sdaIf you want to use UUID instead of device names in the menu, edit the 'append' line to replace
root=/dev/sda1with something like
root=UUID=xxxxxxxxxxxxxxxxxxx(replace xxxxx... with the correct uuid.)
There should be lots of instructions for using lilo with debian. They'll all be old, but they should still work. It's been years since I've used lilo. Some of what you posted looks familiar, and some is new to me.
More recently, I've tried extlinux, which might be easier than lilo.
https://dev1galaxy.org/viewtopic.php?id=555
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
@Panopticon:
Yes, with no root account, you would use the sudo equivalent. I don't think you need the -i.
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
I think you'll need a second desktop file. Change the "Exec=" line to use the fusermount command. Change the icon associated with the desktop file so it looks different. (That's just another line in the desktop file.)
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.
If you're having trouble making a live iso, run refractasnapshot -d to get a more verbose error log (/var/log/refractasnapshot_errors.log). The most common cause of a failed build is to run out of space.
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
I downloaded the package last March (Wow. Good thing I don't use it.) from the palemoon website, and I think they redirected me to Steve Pusser's repo. I'll do that again right now.
Note that the output of apt-cache policy does not show the package as coming from a repository. It just lists /var/lib/dpkg/status instead. It know the package is there, but it can't tell where it came from. Packages installed with dpkg and packages installed from a repo that is no longer in the sources will show up that way.
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/statusDifferent versions, but in each case it's the newest version that apt can see.
No bash?? What shell are you using? Did you make the scripts posix compliant?
Yes, splash is optional.
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?
I just checked one of my ascii installs, and /usr/sbin/anacron is a real file. There are entries in /var/log/syslog, and it looks like it runs when I boot the VM. My anacrontab looks like yours, there are files in /var/spool/anacron for cron.daily .weekly and .monthly with timestamps that match what syslog shows. And my /etc/default/anacron says "No".
'apt-file find /usr/sbin/anacron.orig.anacron' turned up nothing. Maybe dpkg -S would show something on your end. Or 'grep anacron /root/.history' to see if you did something and forgot about it.
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@yeti:
What kind of results do you get with the language selector in lightdm with xfce? If you have at least two languages configured in the system, can you log out and switch language at the login screen? For me, it does not work correctly in devuan or debian (tested yesterday with a fresh Stretch install).
If I select a language at the login screen and then login, I don't get that language. If I then reboot and login, I might get the language I selected last time, whether or not I selected a language this time. LXDM, on the other hand, seems to work just fine.
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.
In your bug report, you stated that the problem exists in debian.
I confirmed, its a problem in display managers .. all the debian (and
obviously in consecuence now devuan) display managers are broken..
That agrees with what I've seen for lightdm in debian. I don't know about the other display managers.
For the installer isos, you choose the keyboard layout at the beginning.
For the live isos, you select 'Other language' from the boot menu and edit the language and keyboard codes for your locale.
If that's not working for you, you must be doing something wrong.
puff the problems with multiple locales are still present and get boring, seems devuan only served good in servers.. for desktop get in a pain if are multi language env
PD: solution was send to the bug tracker.. responses are ... well silenced.
You could have at least provided the bug number in your post. I assume you mean this one:
https://bugs.devuan.org/db/12/129.html
I suggest you do the installation in your first chosen language, and then install lxdm afterward to be able to switch languages at the login screen.