You are not logged in.
Pages: 1
Cool!
I haven't yet got around to play so much with docker, but it's beeing used more and more for labs and such at the company I work for. So it feels very good to know that I can, with your work, use Devuan with docker whenever I'll come around to it!
I'm a bit confused.. Is is only fdisk you cannot run? Or is there other commands as well that does not work?
Maybe this is related to fdisk for you:
https://dev1galaxy.org/viewtopic.php?id=3547
Could you do apt-get install fdisk and post what it says?
Thanks for the info, maybe it's time for me to get this machine to at least dualboot windows/devuan and try it out then!
That is very nice work!
I did switch from Mullvad to an other provider just because of that reason.
There is also an old https://github.com/mullvad/mullvadvpn-app/issues/452 about this. Though the response from one of the devs there is not really getting any hopes up..
Sadly this is on a Windowsmachine at the moment, have anyone played Stellaris successfully on Devuan?
As I'm mostly in a terminal on Devuan I play tint!
How nice that your system now seems functional! I too have read some stuff lately about systems with low ram situations.
https://www.phoronix.com/scan.php?page= … ad-Low-RAM
....and this article about the situation was posted just today:
https://www.phoronix.com/scan.php?page= … ry-Monitor
I don't know how much of this is actually connected to your problem, but it is interesting that enabling swap helped you out.
I've installed rust through their curl-method found at their website, which has worked out very well. Though I'm still educating myself in the language and hasn't done much more than the tutorials in rust book..
I did a quick search for an explanation for why rust chooses to install this way rather than through package-managers. I couldn't find any good answers, but I do guess this is because all crates and such becomes managed centralized, so you will not end up with a lot of packages in different distros that is different versions of crates.
It would be very nice to get a definitive answer for this, if anyone here has this knowledge!
Hi, have you looked at Maemo leste yet? It sounds like what you are looking for, it is based on devuan and seems to be supported for that Motorola device you have!
https://maemo-leste.github.io/
Here is the instruction for getting Motorola Droid 4 to work: https://leste.maemo.org/Motorola_Droid_4
Maybe the system interrupts reported in /proc/interrupts can help you? If you can observe abnormally large values for a device then maybe that is the one, otherwise you hopefully can exlude some factors.
You can view it with cat /proc/interrupts or watch cat /proc/interrupts to get a live output. My recommendation for best troubleshooting would be to save the output to a file and on a schedule with cron or likewise.
Could you elaborate on which graphiccard model you are using and also what driver is active for it, nouveau or Nvidia proprietary?
You can try to use bellow to find which driver is in use:
lspci -nnk | grep -i vga -A3
Are you able to test your system with an other card?
Hi. Just want to say I also had this problem for a long time and can not remember when it appeared. The solution that worked for me was what people here have suggested, commenting out the lines: allow-hotplug eth0,,, iface eth0 inet dhcp
Pages: 1