The officially official Devuan Forum!

You are not logged in.

#1 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!

#2 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.

#3 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!

#4 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....

#5 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....

#6 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!

#7 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.

#8 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

#9 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!

#10 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?

#11 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

#12 Re: Hardware & System Configuration » Custom Kernel Options » 2019-06-20 00:13:37

Update just in case anyone else ever runs into this issue as well.

Looking closer at the repo kernel it looks like the ACS Override patch is applied. So all that was needed was applying the ACS override patch as well as utilizing the pcie_acs_override boot parameter. While not an ideal situation due to the potential security issues, it doesn't seem to concern any of the major distro's?? Arch, Debian, CentOS, RHEL, Ubuntu, etc all seem to provide this patch within their kernel build.

ACS override worked but is a bad idea. Looks like upgrading to a slightly newer kernel and utilizing CONFIG_PCI_MMCONFIG=y accomplished the same thing without the need for the ACS override patch.

#13 Hardware & System Configuration » Custom Kernel Options » 2019-06-18 00:24:15

Replies: 1

Greetings everyone. Hoping some folks on the forum can point me in the right direction with this issue.

I'm working on a system that is utilizing KVM and PCI Passthrough of some Intel PCIe NIC's. The project is being done to be as minimal as possible so it's been a lot of from source with minimal dependencies. It's been an awesome learning experience so far but I'm getting to a point with PCI devices and Kernel configuration parameters that's beyond my current know-how. What I'm seeing is as follows:

On the current 4.9 kernel from the repo, my 4 PCIe NICs shows up each in their own IOMMU group. Nic 1 in group 12, Nic 2 in group 13, etc. This is great as I understand it this means I can detach each of these NICs individually from the host and pass them directly to one of the KVM guests. Having done this with one of the VM's so far all seems well.

So now I wanted to set this up on the slimmed down, minimal kernel. I've added the following configuration options in the custom kernel (I do realize that they should all be CONFIG_* and they are in the acutal configuration file):


Now when I boot the custom kernel, all four of the Intel NIC's show up in the same IOMMU group (group 6 if it matters). I could detach all of them from the host but I was hoping to avoid that if possible.

Again what's happening with this low-level PCI/kernel situation is outside of my current understanding but I'm trying to learn. I've tried doing a comm/diff of the configs from the custom kernel and the larger repo kernel one but that results in quite a bit of items that are enabled in the repo one (obviously since it has to be more generic). Does anyone have any tips or suggestions on how to track down which configuration option might be contributing to the differences in IOMMU groupings for these NICs?

#14 Re: Hardware & System Configuration » Secure Boot » 2019-05-21 00:00:58

Well good news the Toshiba worked! Was able to EFI-stub load without an initramfs and secure boot enabled. I'm hoping to repeat the steps on the HP workstation and see if I can get different results. Was shocked at how much simpler the Toshiba was than HP. Was able to do everything except toggle Secure Boot on in the Bios from within the CLI.

#15 Re: Hardware & System Configuration » Secure Boot » 2019-05-19 23:07:39

Head_on_a_Stick wrote:

If you think the modules are the problem then try configuring the kernel without any modules at all (ie, with all the options built-in).

Should've reported back on Friday. I did just this and still ran into the same issue. Without any sort of display, I can't see anything during system boot up with SB enabled and custom certs... So no idea how to troubleshoot this (thought maybe serial console but system doesn't have one of those either, figures...). Thought about a USB to serial adapter but not sure if it would work before Linux take over though. Any ideas?

I'm going to sacrifice my trusty Toshiba testing laptop to the Secure Boot deity and see if the nvidia card is the issues in the Z420 tower. This Toshiba appears to have integrated everything so I'm hoping that there won't be any crazy OROM's to deal with. I'll report back with the results.

#16 Re: Hardware & System Configuration » Secure Boot » 2019-05-17 14:55:16

Thanks HoS. Was aware of the CONFIG_EFI_STUB in Devuan/Debian kernels. Should have mentioned that this kernel is attempting to be small, specific, and without the need for an initramfs (again for 'fun', haha).

Secure boot Custom keys have been enabled on the firmware. That's what causes the machine to go into the flashing red light of death. It won't do that until I put the custom keys onto the system and enable secure boot in firmware.

Been looking into it more today and have been wondering if the kernel's modules aren't being signed during the build process? I am new to that whole process though. Have been reading about CONFIG_MODULE_SIG_* parameters today but I'm confusing myself I think.

Can I pass my db priv key and db crt to the kernel build process to have the kernel automatically sign itself and associated modules during the make process? The kernel docs seems to suggest so: … gning.html but I'm not sure where to put the pem/crt files that I've already generated so the kernel build process uses them.

I suppose the other option is to just manually sign all of the modules after the kernel build process with the proper kmodsign command?

Sorry for all the questions but I do appreciate your help!

#17 Hardware & System Configuration » Secure Boot » 2019-05-17 01:24:37

Replies: 6

Greetings! I've been spending a decent amount of time looking into EFI-Stub loading and Secure boot. I'm hoping to find someone who may be able to help at this point as I'm not sure where to proceed. Full disclosure this whole project is currently just an academic endeavor! If I can get this working, I plan to document the process as much of the current documentation seems to assume everyone wants to use Shim and leave the MS certs on their box (seems like this would defeat the whole purpose of custom keys though, correct?).

I've managed to compile a kernel with EFI-Stub and get it to boot without Grub (quite awesome functionality, imo). Now I'm wanting to setup my own Secure Boot keys so that my system will only boot my signed kernel. This seemed like a pretty easy feat until starting down the road... At the moment, I'm able to generate and sign my own PK, KEK, and db. sbsign signs my kernel and sbverify states that it has a valid signature matching my db cert. I can then use KeyTool to 'install' the keys (db, KEK, PK - in that order) on the system without errors. Upon enabling secure boot in EFI, the system reboots to a blank screen and then ultimately errors out with 6 red LED flashes of the power light (according to HP this means no graphics).

The hardware is an HP Z420 workstation on the newest UEFI release with a Quadro K2000 GPU. I'm thinking it has something to do with OROMs but I'm not entirely sure. Was hoping that if I exported the original HP certs and concatenated/signed them with my custom ones I'd be good to go but apparently that's not the case.

The system will boot with the factory certs enabled and Shim available though. So it seems like something in the boot process might require MS' cert and it wouldn't surprise me if the nVidia card was the culprit. Long story short, has anyone been able to successfully purge MS certs and boot entirely from their own self signed certs?

If the commands run are needed, please let me know but I've been using the following resources primarily (obviously not following the gentoo/arch and shim/grub specific parts): … ecure_Boot … ng-sb.html

#18 Re: Off-topic » Something is wrong with my Devuan setup because my containers work » 2019-05-04 00:12:08

kuleszdl wrote:

@aut0exec: This is what I put in /etc/rc.local to make the systemd-containers happy (maybe also more, I don't remember anymore):

mkdir -p /sys/fs/cgroup/systemd
mount -t cgroup -o none,name=systemd systemd /sys/fs/cgroup/systemd

Thanks. I'm not opposed to just purging systemd out of Debian either, haha. I'm also assuming those commands where done on the host right?

#19 Re: Installation » Beowulf netinstall no more finds kernel modules » 2019-05-03 11:48:24

rolfie wrote:
aut0exec wrote:

I believe the first link is the newest netinstall for beowulf: … s/netboot/

However, I'm still getting the same issue with it as well. sad

Look at the date of this iso. It is from April 2018, outdated. Fooled me too...


Holy crap! It is 2019! Sorry about that, I retract my previous statement....

#20 Re: Installation » UEFI Installation Woes » 2019-05-03 11:34:33

Red, I saw your post in another thread and SWEAR I did just that and still had the same issue but this morning it worked and the installer is displaying properly... So thank you again!

#21 Installation » UEFI Installation Woes » 2019-05-03 03:12:20

Replies: 2

Went to reinstall Devuan on another HD in a Toshiba C-50 using UEFI and keep running into an issue where the installer displays only on the top third of the screen. I remember having this issue before but I don't recall what I did to solve it. Switching to CSM works but I need UEFI enabled to work with secure boot (I believe).

I thought that it was solved with a kernel parameter at boot (something with efifb maybe) but nothing has worked yet. I've tried efifb=off, vga=efifb:off, and the every popular nomodeset but nothing has worked. Any one have any thoughts or know how to solve this? It occurs on Devuan ascii and beowulf (4/14) net installs as well as Debian buster net install.

#22 Re: Installation » Beowulf netinstall no more finds kernel modules » 2019-05-03 03:02:58

I believe the first link is the newest netinstall for beowulf: … s/netboot/

However, I'm still getting the same issue with it as well. sad

#23 Re: Off-topic » Something is wrong with my Devuan setup because my containers work » 2019-05-01 23:55:56

kuleszdl wrote:

Haven't heard this argument before. Now I am wondering what is wrong in my Devuan setup since the lxc containers seem to work in Devuan even with sysvinit although UNIX is dead.

Interesting! I'm messing around with containers on Devuan at the moment as well. It's been very seamless so far. Only real issue was the Devuan template (off github) was a little outdated and bloated but some easy modifications and voila! Out of curiosity, what distros are you running in containers? I've been meaning to try to build a Debian/Ubuntu container but was wonder how it would handle any systemd dependencies so I've not done it yet...

#24 Re: Devuan » What happened at » 2019-04-05 11:29:13

cynwulf wrote:

There are a few notable issues with this:  Just because it's April 1st, doesn't mean a website which appears to have been cracked on that date hasn't actually been cracked and that simply because it appears to be an April 1st hoax, doesn't mean that it automatically is one, simply by virtue of it being April 1st.

Social engineering, i.e. lulling victims into a false sense of security or simply playing to their greed, arrogance / self importance are all more important in stealing data than the actual exploits / tools used.

I don't see the main problem as being with the prank page, but in how the whole prank was perpetuated on the project's mailing lists, at the expense of many of those around the world who may not see the significance of April 1st.

I'm over the whole situation at this point but this post is where my head was. It wasn't actually April 1st when I tried to visit the website. It was around 1900 on March 31st. Sort of assumed it was a joke but still took precautions just in case (after the Linux Mint fiasco a few years ago, I didn't want to risk it.)

End of the day, Thanks Devuan Devs, still loving the distro and started converting my Pi's over to Devuan as well!

#25 Re: Devuan » What happened at » 2019-04-02 12:13:00

Panopticon wrote:

After reading those dyne messages i didnt realise how serious some members took this. From my point of view i knew instantly it was a joke but if people have their fingers on kill switches then that would be a rather serious security concern. Maybe something a little less concerning for next years april fools. I like what void linux did, its no longer available to see but they made their homepage look like arch linux with the A for Arch upside down so it looked like a V for Void linux!

Not particularly serious but I put off package updates and disabled repo's on ~20'ish systems as a precautionary step. I 'thought' it was a joke as well but the inability to still continue on to the homepage or anything else on the site definitely had me worried. I think ChuangTzu had the idea of an announcement about "Systemd is inevitable and Devuan 3 would run it." Would've been a much better April Fool's prank! Still love the Devuan project and will still run the distro!

Board footer

Forum Software