The officially official Devuan Forum!

You are not logged in.

#1 Re: Devuan » Does anyone else use FreeIPA? » 2019-11-14 03:03:08

I've wanted to use FreeIPA but haven't spent the time to go through the process. Did you happen to write up the steps and changes you made to make it work in Devuan?! I'd definitely be interested.

#2 Re: Hardware & System Configuration » eth0 losing static ip » 2019-11-06 00:56:54

e97 wrote:

thanks @aut0exec ! I suspected it was another network control manager but couldn't figure out what it was. Its disabled and removed.

Reset dnsmasq as well because I probably misconfigured it resulting in a conflict with my router. 

With those changes, everything seems good.

No problem and glad all is well!

#3 Re: Devuan Derivatives » Parrot OS and Devuan » 2019-10-29 00:42:30

golinux wrote:

A note from Parrot OS:

we are not based on devuan yet, and the rolling branch is still based on debian testing

meanwhile we have an experimental lts branch that tracks devuan, and we plan to release a lts version of parrot (5.0) for both x86 and arm architectures, and keep it aside to the rolling edition that will remain the same as now (but amd64 only)

the eta is "when it's ready"


Man... I wonder if they need people to test that LTS branch?!

#4 Re: Hardware & System Configuration » eth0 losing static ip » 2019-10-29 00:38:08

Had this problem when network manager is installed on the system. NM likes to randomly start controlling the NIC. You're supposed to be able to issue:

nmcli device set <ethX> managed no

In practice it rarely stays consistent and in theory NM isn't supposed to be managing stuff in the interfaces file either. I usually resort to adding the following in




Then restart network-manager and networking. The output of nmcli should state that the interface is no "unmanaged".

root@Devuan:~# nmcli
eth1: unavailable
	"Broadcom Limited NetXtreme BCM5755 Gigabit Ethernet PCI Express"
	ethernet (tg3), DE:AD:BE:EF:00:01, hw, mtu 1500

eth0: unmanaged
	"Realtek RTL8169 PCI Gigabit Ethernet Controller (GA311)"
	ethernet (r8169), CA:FE:C0:FF:EE:01, hw, mtu 1500

lo: unmanaged
	loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536

My preferred route is to just remove network manager all together with

apt purge network-manager


#5 Re: Devuan Derivatives » Parrot OS and Devuan » 2019-10-27 16:07:59

Yup Radare is in there but the cutter you mentioned isn't the "right" cutter: Check this out:

I would LOVE to see a Devuan "pen-testing" distro to be honest. I'd work to create my own but if I'm being honest, I'm not qualified to build a distro, haha. Would be a very long road!

Your linked thread is interesting. How you had any progress since your last post??

#6 Re: Devuan Derivatives » Parrot OS and Devuan » 2019-10-25 23:22:43

stanz wrote:
aut0exec wrote:

...and like a bunch of the pre-installed pieces of software they were including....

Would ya share which installed software, you like?
I'm jus` doing alittle recon. wink

Happily! The big ones here were: Radare and Cutter, vscodium (not because I want it, work does), the collection of wireless tools (don't need them currently but plan to learn how to use them). I'm sure there will be others but haven't had much more than a week to mess around with it. Are you building a distro (A devuan based distro like this would be really slick)??

#7 Re: Devuan Derivatives » Parrot OS and Devuan » 2019-10-24 02:39:01

Freemedia, Thanks for the info. The 2017 items were the ones I kept finding. Was hoping since Devuan had seen several releases that perhaps Parrot had switched over by now. Looks like they're still tracking to make the jump so I'll sit tight!

#8 Devuan Derivatives » Parrot OS and Devuan » 2019-10-24 00:18:49

Replies: 9

Just wondering if anyone had heard anything more about the potential change of Parrot OS switching from Debian to base off of Devuan instead? I booted an iso recently and like a bunch of the pre-installed pieces of software they were including but was saddened to still see Systemd there.

#9 Re: Other Issues » When Beowulf will become a stable? » 2019-10-22 01:00:49

fsmithred wrote:

We are very much alive.

Been running across lots of people who know about Devuan as much as they know Ubuntu! I've been shocked a few times to hear folks speaking of Devuan. Not that it's a bad thing at all just caught me off guard.

#10 Re: Other Issues » Beowulf and Avahi-daemon » 2019-10-18 15:21:54

fsmithred wrote:

Put APT::Install-Recommends "no"; in /etc/apt/apt.conf.d/norecommends and Recommends will be excluded on upgrades as well as installations.

Maybe aptitude why avahi-daemon will tell you something useful.

Another TIL! Thanks red...

So initially aptitude responded with 'hplip' so it was removed and then after another run, it came back with the following:

user@userpc:~# aptitude why avahi-daemon 
i   task-cinnamon-desktop Depends    task-desktop
i A task-desktop          Recommends avahi-daemon

So looks like cinnamon has some sort of dependency on avahi-daemon in beowulf?

#11 Re: Other Issues » Beowulf and Avahi-daemon » 2019-10-17 01:46:45

Thanks golinux. That was a good TIL for me! Removed everything in the output and Apt upgrade still wants to reinstall avahi-daemon though. This is the weirdest thing. I have at least three other Beowulf and ceres machines running cinnamon and none of them do this!

After removing everything I decided to reinstall the components I actually did need but noticed if '--no-install-recommends' I was able to prevent avahi-daemon from reinstalling while still upgrading the other software! Tried the same thing with 'apt upgrade' and it exhibited the same behavior. I don't have any apt pinning or odd configurations to my knowledge either. Wondering if I should just reinstall, haha.

#12 Other Issues » Beowulf and Avahi-daemon » 2019-10-16 00:49:40

Replies: 4

Switched one of my Cinnamon Ascii systems over to beowulf repo's and with a few exceptions (self induced issues) everything upgraded without a hitch! I know Beowulf isn't officially released but I've been using it on a bunch of other machines with no issues so far.

Anyways, generally want nothing to do with avahi-daemon so I purge it almost as soon as I see it on a machine. For some reason though 'apt upgrade' is wanting to reinstall it after it has been purged. I can't seem to track down where the dependency is that might be requiring avahi either. Anyone have any suggestions? This is a new one for me...

#13 Re: Other Issues » Latest repositories ----help! » 2019-09-13 01:56:30

Probably not the right forum category for this kind of post...

What exactly are you looking for? Security items are generally made available as quickly as possible when you stick to the stable releases though.

#14 Re: Hardware & System Configuration » Secure Boot » 2019-09-04 01:31:15

seeker wrote:

I was wondering if it is worthwhile to convert my traditional boot install to a UEFI boot install. Not sure if there are any advantages.

I've been converting new installs to it but definitely not going back to switch MBR systems to UEFI unless absolutely necessary. Mainly just because of not wanting to switch the partitioning over.

In contrast to ToxicExMachina, I've enjoyed UEFI, there's a bunch of nice things about it (Secure Boot, efibootmgr, doing away with MBR partitions, etc), To each their own though. If you have a spare machine, try a new install and see what you think. You probably won't notice many differences until you start messing with the boot components (Grub mainly, haha).

#15 Re: Installation » Devuan Fails to Install on Usb Sata Disk » 2019-08-16 00:41:33

Agree with Dutch_Master.

While I don't have other distro's installed on it, I do have a USB stick that boots a Devuan Ascii instance just fine. So it definitely can be done!

#16 Re: Other Issues » Ceres will not update » 2019-07-29 01:10:05

mknoop wrote:

Hmmmm .... curious.

When I was having problems getting ceres to update, because of the system clock issue, I typed "apt-cache search ntp".  It came back with nothing.  Now the search comes back with a lot of things, including ntp.  Perhaps the aborted update messed up the available package listing.

As an aside, I don't actually need ntp for the virtual machine.  I just forgot to click the box in the machine settings for how to handle the hardware clock from the host.  This had not been causing any problems with updating until a few days ago.

To my understanding; If you hadn't been able to pull the package lists (apt update), then apt-cache wouldn't have had anything to search. Once you corrected the clock, I bet you ran and apt update which would've pulled down all the package lists and now apt-cache has stuff to search.

#17 Re: Devuan » What should I know before "diving in" » 2019-07-26 01:34:14

reunite_pangaea wrote:

I'm a Mint user who, maybe this week, will start a dual boot with Devuan.

While I am a Mint user, I've had experience with Arch and Ubuntu minimal before and I've installed Devuan on VirtualBox. But is there anything I should really know before installing it directly?

And yes, I know the whole "back up your current system before installing a second OS" thing and I intend to do so.

Welcome! Former Mint user as well... You'll like Devuan; I've been running ASCII, Beowulf, and Ceres with Cinnamon on a number of different machines and everything still feels like Mint but runs so much better!

#18 Re: Desktop and Multimedia » Random freezing on desktop » 2019-07-25 02:35:58

I had this problem earlier last week but was using Ceres. Screen freeze was random and unpredictable. Would be fine for only 2 minutes one boot and then it would be fine for hours the next boot. Ever since installing the nVidia proprietary driver the system has been stable and running for almost a week with no freezes. Machine is a HP Z420 with a Quadro K2000.

Since you mentioned that Windows also had the problem though, I'd be more inclined to think that you have a possible hardware issue. The card swap might be worth it to keep yourself from going crazy trying to find a software fix for a hardware issue....

#19 Re: Installation » I can't install beowulf using mini.iso » 2019-07-23 00:48:50

fsmithred wrote:

I used the one on this page, but I think it's the same one. … s/netboot/

The kernel in my beowulf is dated July 19. The mini.iso is dated June 27.

Did an UEFI install with the June 27 ISO end of last week and ran into same problem as OP.

Issue was fixed here by getting the system booting manually through the grub CLI (set root and all that stuff) and then noticed that /boot/efi/EFI didn't contain the usual "debian" or "devuan" directory so ran

grub-install --bootloader-id=devuan

. It's been a few days now and I've definitely slept since then so YMMV.

If needed, I can go boot that system up again and review what was done; hoping I saved my history....

#20 Desktop and Multimedia » Cinnamon settings and Beowulf/Ceres X86_64 » 2019-07-21 18:24:06

Replies: 1

I've run across this on a few installs recently and wanted to document it for anyone else running across the same issue.

Fresh install of Beowulf/Ceres and utilizing the Cinnamon DE will likely result in the Cinnamon settings menu not opening. Not a huge problem and it is being tracked upstream at but the TL;DR of the issue is to do the following:

1) sed -i 's/Image\.VERSION/Image\.__version__/' /usr/share/cinnamon/cinnamon-settings/bin/
2) cinnamon-settings

Hope this helps!

#21 Re: Devuan » RC script templates » 2019-07-16 00:38:07

Ralph, Thanks. This is some good info! I'll keep looking for that old tool but the files you recommended, look to be a good start place for now. Much appreciated.

#22 Devuan » RC script templates » 2019-07-15 00:49:22

Replies: 2

Not sure where to put this and my Google searches are turning up nothing useful; I'm hoping someone here remembers the command I'm looking for though!

I feel like way back in the good ole days there was an '*rc*' tool that would auto-generate the shell of an rc script for you and then you just simply had to modify the necessary items for your daemon/process/etc within the script. Does this sound familiar to anyone and if so what was the utility? Thought I had hit the jackpot with 'sysv-rc-conf' but that's more of a 'chkconfig' tool it seems...

*I am aware that I can copy most any other rc script in order to accomplish this task but now I'm trying to make sure I'm not going crazy and making up tools! big_smile

#23 Re: DIY » Microcode updates built into a Kernel » 2019-07-12 11:41:46

Head_on_a_Stick wrote:

It would make more sense not to have it baked in because live updates would not be possible if it was.

Hmm you don't think you'd still be able to late-load a newer one? Luckily for this, anytime there would be an update a new kernel would be rolled out anyways so late-load wouldn't really be needed!

#24 Re: DIY » Microcode updates built into a Kernel » 2019-07-10 00:26:39

Thanks HoaS, I did get it working today.

I was reading the CONFIG_EXTRA_FIRMWARE_DIR as a temporary place to hold firmware until it was compiled into the kernel but it seems that's not the purpose of that parameter. Seems that the configuration parameter simply states where within the root file-system the microcode resides and then the kernel loads it from that path on startup? I was naively assuming that the firmware was actually built into the kernel and then loaded from within the kernel itself rather than from an external source like initramfs or rootfs. Is that assessment correct?

#25 DIY » Microcode updates built into a Kernel » 2019-07-09 00:54:00

Replies: 4

Greetings again, back with another fun one! Still working on this custom setup and realized that the CPU microcode didn't contain any of the patches for those wonderful Meltdown, Spectre, and other bugs from the past year. So I set off to roll the processor microcode into the custom kernel (not using an initramfs and would prefer to apply the patch as soon as possible in the boot process still).

So some quick Gentoo and LFS research showed that baking in firmware into a custom kernel was pretty simple or so I though! So the necessary 4.9 kernel configuration parameters appear to be the following:

CONFIG_EXTRA_FIRMWARE="Intel_ucode/xx-xx-xx"   - xx-xx-xx being the proper code for the Intel CPU

## Not sure what this one does and can't seem to find a clear explanation of what it is for

So going forth with the configuration options above, I placed the Intel microcode into the directory kernel/firmware/Intel_ucode and then proceeded to build the kernel. Watching the build output I see the process pick up the microcode (three lines; there's a MK-FW, AS, and then an LD line referencing the Intel Microcode). However when I boot the kernel on the device the kernel doesn't appear to load the updated microcode but I do know that the microcode is the right one for the CPU as I can late load it and it'll work.

Anyone have an idea what I'm missing/doing wrong?

Relevant post on the topic:
1) … -fs.2Fdisk
2) … mware.html

Board footer

Forum Software