Continuing on the bleeding edge, having pipewire start with no delay on kernel 6.14.0-rc7.

Also hit a bug when rebuilding kernels (several weeks) after the i386 -> x86_64 migration:

/usr/src/linux/tools/objtool//fixdep: Exec format error

/usr/src/linux/tools/objtool/fixdep which was in the kernel tree and had been built for i386 didn't get rebuilt for x86_64, even after a make clean

I had to manually remove the fixdep binary and it was rebuilt for x86_64 on the next kernel build.

I have completely removed the i386 architecture from the machine that I upgraded to amd64 - it wasn't easy and it took a long time (nearly 3 weeks), mainly as I was using Ceres and couldn't use the crossgrader package for some of the process and had to obtain amd64 packages at the same version as i386 using debsnap  -d . -a amd64 package-name package-version-number from package devscripts to obtain most of the packages from https://snapshot.debian.org .

For Devuan-specific packages, I used https://pkginfo.devuan.org/cgi-bin/policy-query.html, and in one case had to build the version of avahi packages that I needed from source at https://git.devuan.org/explore/repos searching for the package, then selecting "tags" and downloading the appropriate version of the tar.gz file and apt-get build-dep avahi and debuild -b, also from devscripts to build a package with the same version number.

I had already started the process of cross-grading using the information at https://wiki.debian.org/CrossGrading and was getting bogged down. One of the linked references, https://anarc.at/services/upgrades/cross-architecture/ was more helpful given my situation.

Having installed enough important amd64 architecture packages under i386 architecture and being able to boot into amd64 architecture was a start, but aptitude doesn't have the capability to easily add packages in a new architecture at the same version as in the old architecture, and dpkg, even after obtaining all the amd64 packages and first installing library packages then everything else, took multiple passes of manually installing packages, getting dependencies matched, and running dpkg --configure -a.

I then had a frozen mouse pointer at the desktop manager login screen when running the boot disk I had upgraded from i386 to amd64, whereas an exiting installation of Devuan/amd64 on the same hardware had no such problem.

The cause was a previously commented out autotune script in the powertop package that must have been re-enabled in the i386 to amd64 upgrade process, and I even found my old Debian bug report about it from over three years ago. Removing the powertop package was the simplest fix.

Answering my own question, thanks to the #devuan irc channel,

https://git.devuan.org/devuan/avahi/src … -15devuan1, then selecting tags had a link to a source tarball for each of the versions, and I built version 0.8-15devuan1 myself using dpkg-buildpackage -b.

From what I could find on lore.kernel.org and past discussion on irc with AMD developers, the in-built GPU in APU's and newer amdgpu-using discrete GPU's have issues getting into the correct state from a kexec restart.

Tried to get kexec to work again, maybe not possible on this hardware "AMD A10-6800K APU with Radeon(tm) HD Graphics".

In single user mode, I used the kexec-load-kernel script from kexec-tools 1:2.0.29-2. That appears to work.

In the /etc/init.d/reboot script I've tried both kexec -e just before the reboot -d -f ${netdown} line and also:

reboot -d -f -k ${netdown}

which is supposed to attempt a kexec load.

Still getting a hardware reboot.

Is anyone successfully using kexec on x86_64 architecture?

Something broke again, I  can't start wireplumber from .xsessionrc after doing an upgrade to libglib2.0-0t64 2.82.4-1, it works fine with liblib2.0-0t64 2.82.3-2. (I can start wireplumber from the command line though).

.xsessionrc wireplumber start-up command:

/usr/bin/daemon --bind --respawn --pidfiles=$XDG_RUNTIME_DIR --name=pipewire-wireplumber /usr/bin/wireplumber

Reported as Debian bug #1089865.

EDIT - thanks to @steve_v for the suggestions. I should have enabled debugging by using daemon -d invocation of the pipewire programs run from .xsessionrc and have noted this as a comment in the .xsessionrc file.

For some unknown reason, after upgrading libglib related packages again I could not reproduce the problem and I have asked for the Debian bug report to be closed.

It sucks to be a vacuum cleaner.

Hmm, upgrade

[UPGRADE] base-files:amd64 13.3devuan1 -> 13.4devuan1

failed because I had symlinks from /bin -> /usr/bin and /sbin -> /usr/sbin still present.

However, a lot of scripts in /etc/init.d still have /bin and /sbin hard-coded, and removing those symbolic links causes a boot failure.

I've put package base-files on hold for now.

@GlennW my current solution is:

~/.xsessionrc

/usr/bin/daemon --bind --respawn --pidfiles=$XDG_RUNTIME_DIR --name=pipewire /usr/bin/pipewire
/usr/bin/daemon --bind --respawn --pidfiles=$XDG_RUNTIME_DIR --name=pipewire-pulse /usr/bin/pipewire-pulse
/usr/bin/daemon --bind --respawn --pidfiles=$XDG_RUNTIME_DIR --name=pipewire-wireplumber /usr/bin/wireplumber

Currently working fine, but if the packages related to pipewire get upgraded, one may need to exit the desktop session, and if sound isn't working on logging in again either do:

init 1

then

exit

to get the desktop session login manager up again,

or in extreme cases shutdown the computer and reboot.