The officially official Devuan Forum!

You are not logged in.

#1 Re: Devuan » As Debian 11 moves closer to Devuan. Is there any reason to stay on De » 2021-04-08 17:52:19

@Head_on_a_Stick I did not mean "upgrading" from Devuan to Debian unstable but from Debian testing to Debian unstable.

#2 Re: Devuan » As Debian 11 moves closer to Devuan. Is there any reason to stay on De » 2021-04-08 16:14:27

For all who want to try it themselves, here is how I managed to get Debian 11 with sysvinit working:

- Install Debian testing using die DI3-alpha
- Edit sources.list and upgrade to unstable
- Install sysvinit and reboot (apt install sysvinit-core && reboot)
- Install your favorite desktop via tasks, e.g. for lxqt: apt install libpam-elogind dbus-x11 task-lxqt-desktop

I haven't tested this in depth, but the desktop seems to work so far.

#3 Re: Devuan » As Debian 11 moves closer to Devuan. Is there any reason to stay on De » 2021-04-05 14:00:42

@sgage I apologize if this sounded insulting to you - this was absolutely not my intention. I am aware that Devuan had (and has) good reasons to run and maintain its own infrastructure. The term "actual work" was directed towards work for systemd removal/init diversity and was meant in contrast to the infrastructure work. Yet, I never questioned that any of these was time-consuming. On the contrary, I rather wanted to express that I wished we could save some effort on the latter and direct it to the former category.

#5 Re: Devuan » As Debian 11 moves closer to Devuan. Is there any reason to stay on De » 2021-04-04 20:48:16

That's really great news and I highly appreciate the efforts and the collaboration that seems to enable running Debian with (at least) sysvinit again - though I have to admit that I didn't try this yet.

Assuming it becomes feasible to use Debian without systemd, I don't think it makes sense to use Devuan just for the mentioned political or "trust" reasons - at least not for me. Actually, by using Devuan you have to trust Debian as well as Devuan is pulling most binary packages from Debian - doesn't it?

If things really turn out for the better in Debian, wouldn't it become more practical to reduce Devuan to "just" a pure Debian-blend with alternative inits preconfigured and systemd-depdendent packages blacklisted?

Please don't get me wrong. I love Devuan and this community. Yet, I wonder if all the effort spent in running and maintaining an own infrastructure could not be better put into the actual work needed for init diversity? With this being said, I have to admit that the wounds from the community split will certainly not heal overnight. But as an end-user who wants to run Debian without systemd, I hope we are getting back on track.

#6 Re: Hardware & System Configuration » ARM Cortex-A9 » 2021-03-27 12:40:40

Should be armhf. But maybe this question would be better fit in the dedicated ARM builds subforum?:

#7 Re: ARM Builds » Repartioning the SSD after flashing a Devuan Beowulf image » 2021-02-28 17:37:32

I also highly recommend using partition labels over UUIDs. You can find a detailed example how they can be used in my generic aarch64 tutorial here: … 4-install/

#8 Re: ARM Builds » Plans for generic ARM installer images that use the EFI boot process? » 2021-02-28 17:32:19

Afaik, there is already a generic aarch64 ISO that works fine and comes with GRUB already. It's the mini.iso that can be found here: … t/mini.iso

It works fine in QEMU so I assume it should also work with u-boot.

Personally, I like the idea of the OP. Sure, you need to flash a board-specific u-boot once into the SPI. But once you've done it, installing any EFI-compatible OS should be as easy as doing the same on x86_64.

Yet, I'm not sure if having u-boot is enough or if you won't need a 2nd stage bootloader such as TianoCore. But if it already works with u-boot, why not give it a try?

#9 Re: ARM Builds » armhf not possible on cubietruck » 2021-01-24 13:37:14

The keyboard issue might be related to this (I think the u-boot shipped by Debian is still affected?): … 00162.html

#10 Re: Installation » Installing on a new laptop » 2021-01-12 21:19:13

Well, bullseye is already in the first freeze as of today, so I assume things will get rather more stable over time since the release is not too far away (I expect it in May/June).

#11 Devuan » Pkgmaster/mirrors delayed (3 days behind Debian in unstable)? » 2021-01-12 21:10:42

Replies: 1

Hi folks,

I am running a system here using the unstable kernel via the linux-image-arm64 package. When I run apt update, I do not get any updates proposed. However, my package version is currently


While Debian reports that


is supposed to be there since 2021-01-12

I assume that this is a delay due to the mirrors carrying the package not being up to date?

#12 Re: ARM Builds » armhf not possible on cubietruck » 2021-01-09 19:33:30

To add on that: Another thing you could try would be using a newer u-boot like the u-boot image from unstable paired with the partition.img from stable. I don't remember how this was exactly, but it could be that this keyboard issue was fixed in a newer u-boot release. Then, you could enter the setenv/saveenv commands directly using the attached keyboard without manipulating the boot.cmd/boot.scr.

Anyways, you should now have quite a few approaches to try. ;-) Good luck!

#13 Re: ARM Builds » Installing Devuan on the Pinebook Pro (mainline u-boot + kernel) » 2021-01-09 19:29:33

Well, tbh I have the pinebook pro because it was the first kinda-powerful and kinda-freedom-friendly arm64 laptop that was available. Opinions about it vary, and personally I prefer old Thinkpads over it (especially due to their much better input devices - keyboard, trackpoint). Yet, the PBP is a really interesting device with a pretty decent screen and long battery life.

I am pretty sure bullseye will have quite a good ootb experience on it, however, I really dislike that the regular installer does not support installing to f2fs filesystems so I will probably continue doing installs in the fashion described in the article. However, having a stable (packaged) kernel and packaged bootloader will be definitely an improvement over the current situation.

#14 Re: ARM Builds » armhf not possible on cubietruck » 2021-01-07 02:44:30

Sure, serial adapter is possible as well but this is cheating. ;-) No but it requires opening the case each time which can be annoying, and eventually you want to have working HDMI output in your installed system as well. With that being said, it is never a bad idea to have a serial console at hand anyways.

You are right about the USB issue, I completely forgot that. The boot.scr has some kind of binary format that is generated from boot.cmd. This can be done using the mkimage command as described in the sunxi wiki:

As an alternative, you could try to boot using extlinux.conf instead of boot.scr. I prefer this over the boot.scr method used by Debian.

Alternatively, you could also try to set the parameters using uEnv.txt.

Good luck, and maybe you get it working before your usb-serial-adapter arrives. :-)

#15 Re: ARM Builds » armhf not possible on cubietruck » 2021-01-06 04:38:54


afaik this is a cubietruck-specific issue. Try the following in u-boot:

setenv bootargs console=tty1 fb=false

Btw.: Welcome to the forums!

#16 Re: ARM Builds » Installing Devuan on the Pinebook Pro (mainline u-boot + kernel) » 2021-01-05 22:33:31

Head_on_a_Stick wrote:
kuleszdl wrote:

I don't see much sense in using the backport kernel as it (afaik) does not get regular security updates

The backported kernel is drawn from testing and is updated from there so it's usually a couple of weeks out of date but that's surely better than having to keep track of upstream manually and compiling a fresh kernel locally every time there's an update.

That's true which is exactly why I usually prefer to use the kernel from unstable instead of the one from backports.

kuleszdl wrote:

However, the packages in Debian unstable (5.10 currently or very likely also 5.9 in backports) do *not* work as the kernel is compiled with said configuration parameter that prevents the display from working.

Sounds like you should submit a bug report to Debian then. Just be sure to reproduce the issue with a Debian system, some of the developers can be funny about bug reports from Devuan users.

I'll look into it but I'm pretty sure someone else already reported it as this issue also turns up on all "regular" installations of Debian unstable on this device.

#17 Re: ARM Builds » Installing Devuan on the Pinebook Pro (mainline u-boot + kernel) » 2021-01-05 15:55:53

I assume it should also work from the backports repo. However, I don't see much sense in using the backport kernel as it (afaik) does not get regular security updates and 5.9 is EOL in upstream already. However, the packages in Debian unstable (5.10 currently or very likely also 5.9 in backports) do *not* work as the kernel is compiled with said configuration parameter that prevents the display from working.

Regarding the blobs: Okay, this was new to me. I always thought Debian included the upstream kernel from kernel,org without deblobbing it. However, it seems like Debian indeed deblobs it. Therefore, it would be proabably better to use the sources from the kernel package in Debian instead of pulling the kernel directly off

#18 ARM Builds » Installing Devuan on the Pinebook Pro (mainline u-boot + kernel) » 2021-01-05 05:41:39

Replies: 6

Dear Devuan friends,

I've written a guide on how to get Devuan 3 (stable) installed on the Pinebook Pro using the vanilla kernel, vanilla u-boot and no third party repos. Both the kernel and u-boot still require manual compilation as the default configuration files do not fit the device, however, their source code does not require any unofficial downstream patches.

Of course, many things can be further improved with unofficial patches. Yet, the target audience of this guide are those who prefer a vanilla, mainline experience. Here's the link:

Feedback is warmly welcome and highly appreciated.

#19 Re: ARM Builds » mnt reform support? » 2020-12-28 01:49:31

Well, not all software is optimized for multiprocessing loads. I used an x86 cpu with cores but very slow per-core performance (AMD Opteron) and processing larger TEX documents on it was no fun at all. So in the end it really depends on what you use your box for. In general, I think the MNT Reform should be up to most everyday tasks and its batteries should last much longer than on a X200.

Apart from blobs, my main concern with the Pinebook Pro is the keyboard and (especially) touchpad when compared to the Lenovo machines that shine here. This tought me that the general ergonomics should be taken into account very seriously. I really hope the MNT Reform can get much closer here than the Pinebook Pro did. But please don't get me wrong - the Pinebook Pro isn't worse than many "consumer" laptops here, I am just used the Thinkpad experience and that's what I miss there.

Regarding RISC-V: Yes, the port is not officially supported but most packages seem to build fine. I tried to find information on whether or not risc-v support is planned for Debian bullseye but was unable to find any info on that. So I guess the actual problem with risc-v in production on Debian is simply getting packages and timely security updates...

#20 Re: ARM Builds » mnt reform support? » 2020-12-25 14:43:57

Yes you are right - the RK3399 is about the speed of the P8600, maybe even faster in some situations. Since I have both machines here I could run some benchmarks if you have something particular in mind?

And well, the LS1088 would be interesting as well. However, a single A53 core is not very fast, and therefore singlecore performance would be awful. Also, the Ten64 seems to be rather power hungry and I am not sure how this chip would perform with passive cooling in the MNT Reform.

Since your requirements seem to be freedom, security and performance I guess the current MNT Reform could be still a viable option as the X200 looses a lot in terms of security (especially in terms of virtualization). And the next option would be probably an upgraded MNT Reform if it gets released next. Yet I hope they will skip ARM and go directly for RISC-V. The mentioned SiFive chips also have no out-of-order execution, so they are not a bad option. Another interesting option on the horizon is Alibaba's 16-core RISC-V chip, but I doubt it is targeted at mobile devices at this stage: … -risc.html

#21 Re: ARM Builds » mnt reform support? » 2020-12-24 18:57:27


I have both a pinebook pro as well as several core2duo Lenovo Thinkpads (such as X200) and also considered getting an MNT Reform. Overall, I think that the MNT Reform is a great project and I hope they will be able to reuse most stuff (such as the case) for a future model with a different PCB. In particular, I am hoping for RISC-V using one of the SiFive cores that are already almost available for Mini-ITX desktops:

When considering ARM64, both the rk3399 and NXP's LS1088A might be an option. The LS1088A is used in this box which I find interesting as well:

However, the rk3399 has the issue that it needs a blob for DDR4 training, but this afaik applies to the current MNT Reform as well. Future Rockchip SoCs might be interesting as well, but if you consider that the pinebook pro still does not run an official version of Debian or Devuan shows that new SoCs really need some time for being supported well enough without tons of unofficial patches.

When comparing performance, I found to be an interesting option as it supports multiple architectures. So, if you want to compare the a typical Core2Duo P8600 with the RK3399 the data looks roughly like this:

P8600: 250 (single), 500 (multi)
RK3399: 250 (single), 700 (multi)
iMX8MQ: (unfortunately not benchmarked)

So YES, the rk3399 is almost as fast as an P8600. BTW: The fastest libre x86 option from the core2duo generation is a quadcore CPU in a T400 or T500 (requires some modding):

Q9000: 300 (single), 1000 (mutli)

However, if you consider running a "me cleaned" X230 with an i7 CPU as a viable option as well you will notice that the X230 is still waaay faster (not talking about quadcore i7 in a W530):

i7-3620M: 650 (single), 1500 (multi)

Overall, I am pretty optimistic that we will see some very interesting new options in 2021 and 2022 both based on ARM64 and RISC-V. Regarding PPC64LE (POWER9, POWER10), I am not that optimistic, at least for mobile.

#22 Re: Installation » Installing on a new laptop » 2020-12-13 12:55:50

Instead of switching to chimaera - did you try using beowulf with just the kernel from unstable or backports?

#23 Re: ARM Builds » Edev1 Devuan Builder » 2020-08-06 14:12:01

Hi, I appreciate your effort but I doubt that building hardcoded kernels is the proper way to go. The "universal" Debian/Devuan kernel supports at least some of the mentioned boards quite well. Newer boards might run better with newer kernels from unstable.

I mean, if you want to provide such kernels you should build a repository where you package, test and update these kernels as well. Since this is probably too much effort, it might be better to simply use the packaged and SoC-optimized kernels from Armbian as they receive updates regularly.

#24 Re: Installation » backports » 2020-07-30 13:41:34

This is true for the kernel but there are other cases where using backports might be a good idea. For instance, for a long time the version of certbot in stable was outdated and not working anymore, so it was literally useless while the version from backports worked.

#25 Re: Hardware & System Configuration » How to tell initramfs to continue booting? » 2020-07-19 02:08:21

Meanwhile, I worked around this issue. It seems that the cryptroot-unlock script does not work on newer kernels (5.7+) from dropbear-initramfs when there is an external display available but not connected.

Board footer

Forum Software