The officially official Devuan Forum!

You are not logged in.

#1 Re: Installation » does Devuan have some mini netinstall Iso file for CD image » 2024-02-03 19:37:05

Testing or unstable from a mini.iso always fails, i think.

... and the mini.iso from ceres is actually older than the versions from daedalus...

#2 Re: Devuan » Praise for the security updates » 2024-01-27 22:01:42

... but the debtree doesn't directly highlight that xserver-xorg-core is itself forked - would be nice if there was some way to have an indication of that.

(I'm sure it's not recommended practice, but...)

emanym@euterpe:~$ for i in `apt-cache search xserver- | sed -e 's/ .*//'`; do apt-cache show $i | grep Filename ; done
Filename: pool/DEBIAN/main/x/xserver-xorg-video-qxl/xserver-xspice_0.1.5+git20200331-3_amd64.deb
Filename: pool/DEVUAN/main/l/lightdm/lightdm_1.26.0-8+devuan1_amd64.deb
Filename: pool/DEVUAN/main/x/xorg-server/xorg-server-source_21.1.7-3+deb12u2devuan1_all.deb
Filename: pool/DEVUAN/main/x/xorg-server/xserver-common_21.1.7-3+deb12u2devuan1_all.deb
Filename: pool/DEVUAN/main/x/xorg-server/xserver-xephyr_21.1.7-3+deb12u2devuan1_amd64.deb
Filename: pool/DEVUAN/main/x/xorg-server/xserver-xephyr-dbgsym_21.1.7-3+deb12u2devuan1_amd64.deb
Filename: pool/DEVUAN/main/x/xorg-server/xserver-xorg-core_21.1.7-3+deb12u2devuan1_amd64.deb
Filename: pool/DEVUAN/main/x/xorg-server/xserver-xorg-core-dbgsym_21.1.7-3+deb12u2devuan1_amd64.deb
Filename: pool/DEVUAN/main/x/xorg-server/xserver-xorg-dev_21.1.7-3+deb12u2devuan1_amd64.deb
Filename: pool/DEVUAN/main/x/xorg-server/xserver-xorg-legacy_21.1.7-3+deb12u2devuan1_amd64.deb
Filename: pool/DEVUAN/main/x/xorg-server/xserver-xorg-legacy-dbgsym_21.1.7-3+deb12u2devuan1_amd64.deb

#3 Re: Desktop and Multimedia » [SOLVED] Cloudflare WARP, how to install? » 2024-01-17 23:41:01


But why this two  dependencies take so much space?

They don't, gnupg2 is about 400K, libnss-tools some 4.7M (on chimaera),
leaves about 435 MB for the cloudflare package...

#4 Re: Installation » DropBox App Install » 2024-01-17 20:19:35

Why don't you setup an isolated VM and check it out yourself?

Alternatively -- and somewhat faster -- you can download the .deb package, unpack with:

dpkg-deb -x dropbox_2023.09.06_amd64.deb dirname

and see what's inside.

Unfortunately, it's just a python installer script and some library.

You could still use/modify that to download (not install or run) & poke around in whatever it downloads , but I'm not that curious...

#5 Re: Hardware & System Configuration » [SOLVED] boot log in daedalus » 2024-01-15 22:01:07


Is dmesg the command?

Yes -- on a console you should probably use:

dmesg | less

In a terminal it depends on how many lines you can scroll back.

It should start with something like:

[    0.000000] Linux version 5.10.0-8-amd64 ( (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.46-4 (2021-08-03)
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-8-amd64 root= ....

#6 Re: Hardware & System Configuration » switch to schedutil governor » 2024-01-10 00:08:10


Both 6.6.8 (from unstable) and  6.5.x (from backports) seem to prefer acpi-cpufreq on my 5900x:

root@calliope:~# cpupower frequency-info
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 2.20 GHz - 4.95 GHz
  available frequency steps:  3.70 GHz, 2.80 GHz, 2.20 GHz
  available cpufreq governors: performance schedutil

Do you enable the amd-pstate-epp driver anywhere, or is that used automagically?

#7 Re: Hardware & System Configuration » merged /usr » 2024-01-02 23:40:13

I vaguely recall early versions of the daedalus mini.iso installer failing when I opted out.
Current versions are fine -- I wonder if this is what fixed it ;-)

#8 Re: Other Issues » cryptsetup on embedded » 2019-05-30 23:00:48

d1str0 wrote:

No major difference.
This is what is new:

< name         : aes
< driver       : aes-arm
< module       : aes_arm

So aes-xts is still unsupported, even with those modules loaded...

I noticed on my desktop pc (amd64) that the xts module also uses or needs the gf128mul module.

Is that loaded on your banana pi?
Could also be compiled in the kernel, you can check for CONFIG_CRYPTO_GF128MUL= in /boot/config-<kernel-version> if that exists on your system or alternatively in /proc/config.gz (may be missing as well on your system).

#9 Re: Other Issues » cryptsetup on embedded » 2019-05-27 23:28:39

d1str0 wrote:

Before running cryptsetup luksOpen neither is loaded. After that, only xts is loaded. I can load ecb with modprobe, but cryptsetup gives me the same error.

No changes in /proc/crypto after loading those modules?

#10 Re: Other Issues » cryptsetup on embedded » 2019-05-06 23:14:37


you can check for supported encryption schemes with:

emanym@sybilla:~$ cat /proc/crypto

and get something like:

  name         : xts(aes)
  driver       : xts(aes-generic)
  module       : xts
  priority     : 100
  refcnt       : 5
  selftest     : passed
  internal     : no
  type         : blkcipher
  blocksize    : 16
  min keysize  : 32
  max keysize  : 64
  ivsize       : 16
  geniv        : <default>

Also, check whether xts and ecb modules are loaded with:

emanym@sybilla:~$ lsmod | grep "ecb\|xts"
ecb                    16384  0
xts                    16384  4
gf128mul               16384  1 xts

Did you use a devuan sunxi image for the installation?


#11 Re: Installation » Is There Any Way To Directly Install Ceres? » 2018-06-24 12:19:44

xD wrote:

I attempted to follow the steps I have used previously with the Debian mini.iso, but there doesn't appear to be an option on any of the Devuan isos for an Unstable installation.

Devuan has a mini.iso as well (it's in the package mirrors, not the iso mirrors).
The installer allows you to select testing and unstable as well as stable, but installing unstable (ceres) doesn't work.

The installation fails with a conflicting packages error when it tries to install both eudev and udev.

Installing testing (beowulf) from the mini.iso mostly works, but there were some hiccups there as well.

That appears to have installed something that is mostly buster with devuan sysvinit and keyring...

I'm not sure the mini.iso is an officially supported devuan installation medium, though ;-)

#12 Re: Hardware & System Configuration » Ascii: hdparm.conf ignored - udev problem? » 2018-06-23 19:37:59

kalle-del-haye wrote:
emanym wrote:

Strangely enough it works out of the box for me with an ascii openrc installation:

OK. Is this installation still existing?

I will keep it around for a while, openrc was on my todo list anyway ;-)

kalle-del-haye wrote:

Could you please, try the backports kernel?

So I did, and the results are the same (cold boot after disconnected power):

root@iris:~# hdparm -I /dev/sda | grep level
        Advanced power management level: 64
root@iris:~# hdparm -I /dev/sdb | grep level
        Advanced power management level: 254
root@iris:~# cat /proc/version
Linux version 4.16.0-0.bpo.2-amd64 ( (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #1 SMP Debian 4.16.12-1~bpo9+1 (2018-06-03)
kalle-del-haye wrote:

Thats the only difference I notice

Actually, there may be another difference, I typically pick  a targeted initrd on installations...

And now for the really fun part, I attached a , RUN+="/bin/date >> /home/emanym/udev-hdparm" to /lib/udev/rules.d/85-hdparm.rules, and ....

root@iris:~# ls /home/emanym/

(with both kernel versions)

I'm reasonably
sure I don't understand that ;-)

#13 Re: Other Issues » Where to express package requests? » 2018-06-23 11:10:42

There is an old package for unetbootin in wheezy, it is possible to build that from debian source packages on (debian)jessie at least. Building just a binary from more recent source also worked.

#14 Re: Hardware & System Configuration » [Solved] Screen output at boot time » 2018-06-22 23:36:40

Altoid wrote:

So ...
Now I have to see about why this is happening.
And how to get this to be permanent even if it means using the deprecated vga=XXX entry.

That option may not be deprecated in pclinuxos (yet) even if it is in devuan/related dists.

Anyway, grub on devuan recognizes dists based on /usr/lib/os-probes/mounted/90linux-distro and makes a config with /etc/grub.d/30_os-prober.

I'm assuming the pclinuxos grub does something similar, but editing the 30_os-prober file to handle devuan is probably not a great idea... Have a look at it to see what I mean ;-)

You could make a custom entry for devuan (on pclinuxos) in /etc/grub.d/40_custom based on the original menuentry from the pclinuxos grub, with an added vga= option. I assume that would end up last in your grub menu.

#15 Re: Hardware & System Configuration » [Solved] Screen output at boot time » 2018-06-21 23:10:49

Altoid wrote:

PCLinuxOS uses Grub2 2.02.0-3
Devuan uses 2.02Beta3-5

I don't know if there's any real difference between these two, but ...

Grub from pclinuxos  and grub from devuan may use slightly different boot command lines to boot devuan, you could check by doing:

cat /proc/cmdline

on both "devuan booted from devuan grub", and "devuan booted from pclinuxos grub", or by comparing the command lines used in both grub configs directly, something like

grep -A 13 evu /boot/grub/grub.cfg | grep vmli

in devuan and pclinuxos should work, although you would get multiple hits. Only the first one matters...

#16 Re: Hardware & System Configuration » Ascii: hdparm.conf ignored - udev problem? » 2018-06-21 18:04:37

kalle-del-haye wrote:

But Devuan with openrc (selected in the installation process) is not a "real" openrc system. All the init services are still classic sysV scripts in contrast to Gentoo, which is using openrc scripts (and conf files) for services.

I haven't looked at devuan with openrc yet, only a couple of arch versions. I *did* notice the jessie version of hdparm still has a startup script in /etc/init.d/hdparm that disappeared in the ascii version.

The jessie init script may work on ascii, but that's just another nasty hack ;-)

kalle-del-haye wrote:

I think this is really an eudev problem. A simple testing rule in /etc/udev/rules.d/ is executed by udevadm trigger but not at reboot.

Neither udev nor eudev seem to log anything useful beyond the rules files from the initrd, so I can't really help there.

The best idea is probably to file a (eudev) bug report at

I'll see if I can find some free partitions for an openrc devuan installation to try and reproduce the problem...

Strangely enough it works out of the box for me with an ascii openrc installation:

root@iris:~# hdparm -I /dev/sdb | grep level
        Advanced power management level: 254
root@iris:~# hdparm -I /dev/sda | grep level
        Advanced power management level: 64
root@iris:~# dpkg -s hdparm | grep ersi
Version: 9.51+ds-1
root@iris:~# dpkg -s udev | grep ersi
Version: 1:3.2.2+devuan2.11
root@iris:~# dpkg -s eudev | grep ersi
Version: 3.2.2-13
root@iris:~# dpkg -s openrc | grep ersi
Version: 0.23-1+b1
root@iris:~# uname -a
Linux iris 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64 GNU/Linux

Clean install, no desktop, just added vim, rsync and firmware for my graphics card...

#17 Re: Hardware & System Configuration » [Solved] Screen output at boot time » 2018-06-20 23:40:47

Grub, or os-prober actually, looks at any partition it can find for other operating systems, and 'guesses' how to boot that os.

The grub versions from devuan, debian(-derivatives), pclinuxos and manjaro are pretty good at guessing, some others make a mess of it.

The resolution of the grub menu at boot is determined by the grub configuration from the 'local' linux version, not the grub configuration of 'other' versions.

I'm not sure why it should influence the console resolution after linux was booted...

#18 Re: Installation » Installing devuan to lvm partitions within dm-crypt container » 2018-06-20 23:17:29

Vizitor wrote:

But, the question is: Does encrypted filesystem/partition/container in the end get proper unmount?
Because all those unmounting messages are ending with "failed".

I don't really know, however:

  • The "unmounting local filesystems" step (suppposedly) happens before the "stopping remaining crypt disks" step,

  • The "crypt disk" is a dm mapping to the lvm container, not the logical volumes inside the container,

  • The standard ascii version always fails as well, the modified versions just fail quickly,

  • The jessie version also fails, but only tries one time...

It might be possible to verify that filesystems inside the lvm container have been unmounted before the ...(failed) loop starts, but timing that would be tricky, and I'm not even sure about what exactly causes the delay...

Vizitor wrote:

I am concerned that over time, some files may become corrupted without noticing.

That's precisely the problem with this problem ;-)

#19 Re: Hardware & System Configuration » [Solved] Screen output at boot time » 2018-06-20 21:53:22

devuser wrote:

Sadly all i remember is that it was annoying to figure out but grub being bugged nowadays is of course also an (imo unlikely) possibility.

Rumour has it grub was designed by the same committee that designed the camel and the dodo ;-)

#20 Re: Hardware & System Configuration » [Solved] Screen output at boot time » 2018-06-20 21:51:35

Altoid wrote:

No ..
Won't do.

The graphics mode or the verbose boot?
For verbose boot use devuser's answer....

For grub graphics mode:
try interrupting grub before boot, and open a grub commandline by typing c (escapeto quit)

The videoinfo command should give information about available video modes, and the one currently selected (marked with a *).

It is possible to set the gfxmode directly in /boot/grub/grub.cfg, but not a good idea -- it would get overwritten on grub or kernel updates.

What happens if you boot devuan from the pclinux grub?

#21 Re: Hardware & System Configuration » [Solved] Screen output at boot time » 2018-06-20 17:59:19

Altoid wrote:

The thing is that the boot time output on my screen is not in it's native 1280*1024 but what seems to be 640*480 and I have not been able to get it to show in 1280*1024.

I have tried adding vga=791 or 792 to the grub stanza to no avail.
I have also tried GRUB_GFXPAYLOAD_LINUX 'keep'.

You could try changing the grub gfxmode in /etc/default/grub (line 23):

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480 <---

and run update-grub.

#22 Re: Hardware & System Configuration » Ascii: hdparm.conf ignored - udev problem? » 2018-06-20 11:10:48

Or could it related to openrc, which I'm using?

I doubt that, I tested yesterday on a clean ASCII install with sysvinit...

Actually, is there anything hdparm related in /etc/conf.d/?

The gentoo wiki suggests setting hdparm boot options there:

I haven't figured out a way to test anything yet, since hdparm starts at boot even if I remove it from the initrd...

I'm sure there is a sane way to solve this problem, but I'm not that familiar with the inner workings of udev, and only use hdparm to wipe disks anyway....

Funny this, running hdparm at boot seems to work out of the box on some devuan installations (jessie amd64, ascii i386, ascii amd64 upgraded from jessie) but not on every devuan installation I have -- even though they are all installed on the same machine...

#23 Re: Hardware & System Configuration » Ascii: hdparm.conf ignored - udev problem? » 2018-06-19 21:03:25

Hmm, this is weird, but anyway:

If udev only processes files from the initrd, it is possible to add what we need, by creating a file in /etc/initramfs-tools/hooks/hdparm, making it executable chmod +x $file), containing the following:


set -e


prereqs () {
	echo "${PREREQ}"

case "${1}" in
		exit 0

. /usr/share/initramfs-tools/hook-functions

copy_exec /lib/udev/hdparm /lib/udev
copy_exec /sbin/hdparm /sbin
cp -p /etc/udev/rules.d/85-hdparm.rules $DESTDIR/lib/udev/rules.d/
cp -p /etc/hdparm.conf $DESTDIR/etc

exit 0

With a simple config in /etc/hdparm.conf:

/dev/sda {
  apm = 64
  spindown_time = 5

Next, run update-initramfs -u -k 4.9.0-6-amd64 (or whatever your kernel version is), and check with:

root@iris~:lsinitramfs /boot/initrd.img-4.9.0-6-amd64 |grep hdparm

And sure enough:

root@iris:~# hdparm -I /dev/sda | grep level
        Advanced power management level: 64

So far, so good, but when I remove the hdparm stuff from my initrd, hdparm still starts at boot, and still reads /etc/hdparm.conf.

I'm reasonably sure I don't understand what happened here, but if you have a fairly high tolerance for nasty hacks you could try this ;-)

#24 Re: Hardware & System Configuration » Ascii: hdparm.conf ignored - udev problem? » 2018-06-18 18:42:08

Are there any files in /run/udev/rules.d/?

Does copying the 85-hdparm file to /etc/udev/rules.d/ change anything?

(Those should take precedence over /lib/udev/rules.d/)

Also, you could try changing the loglevel in /etc/udev/udev.conf, probably start by uncommenting, and see what pops up in dmesg.

There are some udev config files in the initrd.img as well, but i'm not sure hdparm would be included in a standard initrd:

root@sybilla:~#  lsinitramfs /boot/initrd.img-4.9.0-6-amd64 | grep udev

#25 Re: Hardware & System Configuration » Desktop resolution problem (AMD graphic card). » 2018-06-13 17:53:55

It should be possible to add some custom x-org configuration file in /usr/share/X11/xorg.conf.d, based on xrandr settings?

emanym@sybilla:~$ ls /usr/share/X11/xorg.conf.d/
10-quirks.conf  40-libinput.conf  70-wacom.conf

Board footer

Forum Software