(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

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

Hi,

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?

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

Hi,

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?

Regards.

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

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 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #1 SMP Debian 4.16.12-1~bpo9+1 (2018-06-03)
root@iris:~#

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/
root@iris:~#

(with both kernel versions)

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

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.

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 ;-)

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 https://bugs.devuan.org/

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
root@iris:~#

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

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

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

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?

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:
https://wiki.gentoo.org/wiki/Hdparm#OpenRC

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

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

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
 ...
lib/udev/rules.d
lib/udev/rules.d/56-lvm.rules
lib/udev/rules.d/69-lvm-metad.rules
lib/udev/rules.d/50-udev-default.rules
lib/udev/rules.d/60-persistent-storage.rules
lib/udev/rules.d/80-drivers.rules
lib/udev/rules.d/55-dm.rules
lib/udev/rules.d/60-persistent-storage-dm.rules
 ...