Thanks GlennW, I tried changing the runlevels, but I'm still getting the message about empty runlevels. For some reason update-rc.d is not properly parsing the file. It's so strange! I also had to install a script for nftables, and it worked fine.

I wish I'd looked at the rc directories before changing the iwd script to see if it was installed wrong from the start. That could have been the problem from the beginning.

I've got the orphan-sysvinit-scripts package on all my systems now, that's a good one to have.

Edit - update:

I used `update-rc.d iwd enable [runlevels]` to force the service to start when I wanted it to. It still doesn't explain why the default method fails, but at least it works now, and the service starts at boot!

Thanks, I believe we may already be using the same script, as the /etc/init.d/iwd script that was installed on my system says it was generated by sys2dv:

#!/bin/sh
# Generated by sysd2v v0.3  --  http://www.trek.eu.org/devel/sysd2v
# kFreeBSD do not accept scripts as interpreters, using #!/bin/sh and sourcing.

I think the sys2dv script would work fine as it is, if it weren't for the known bug with the Atheros hardware, which was apparently fixed for the newer chipset (ath10k) but not my older system (ath9k.) This is a really old system (2008) and I don't think anyone at iwd or the kernel cares about fixing it anymore. I'll have a look at the sysd2v script source and see if I can figure out where I need to introduce the 2-second delay that the systemd unit fix would normally provide.

Some systems have capacitors that will hold the CMOS memory for up to an hour after you remove the battery. Others have non-volatile memory, though, and can't be reset that way. I have an old Dell laptop with an unknown admin password and I haven't found any way to reset it.

I looked up the xfce4 metapackage because that was the way Danielsan cited it, but certainly, your minimal install would be a lot leaner, about 90% by the looks of it. I was actually considering xfce recently until I saw the elogind dependency. I'm not trying to change anyone's mind about the issue, but there's a thread about it here if anyone's interested:
https://dev1galaxy.org/viewtopic.php?id=5909
I haven't checked to see exactly which of those core packages is dependent on elogind, so it may be possible to use significant parts of xfce without elogind.

Why do you say that? The gitlab shows commits as recent as two weeks ago.
https://gitlab.freedesktop.org/xorg/app/twm

Don't you need to tell the package manager not to upgrade the package as well? I recently had to install an older version of a package, and I also told aptitude to put a hold on it. In my case, it was because newer versions of the wacom driver had pulled support for serial tablets, which broke a ton of older tablet PCs.

(I figure it's a good idea whenever such things are discussed to post a link to Don'tBreakDebian as a warning to those unfamiliar with the risks of such practices.)

I currently have cwm installed on all my Devuan machines. It takes a bit of time to get used to the complete lack of window decorations, but once you learn the keyboard shortcuts, it's really not an issue. Configuration is extremely easy via the .cwmrc file.

If you decide to try cwm, you'll probably want to replicate some of the functionality offered by DEs and more advanced WMs. I currently have some hotkeys bound to scripts that adjust my volume and screen brightness using amixer and brightnessctl. They call xosd to briefly display the current settings.

This behavior is due to the Debian alternatives system. When both `less` and `more` are available, man will default to using less as its pager, because it has a higher priority. If you remove less, the system will fall back to more. You can see information about pagers installed on your system with `update-alternatives --display pager`.

Unfortunately the LESS environment variable only applies to the less program, not more. more is extremely primitive, even the manpage mentions it, and steers uses toward less. dave doesn't explain why he wants to use more specifically, but I always assume people have their reasons in such situations.

I tried to replicate dave's issue on 2.39.3, and while more didn't clear the screen without the -c or -p option, I noticed a different issue. When I printed from redirected output (i.e., not from a regular file) the -c or -p option would not clear the screen. Everything worked as expected on 2.33.1, so I think it's another bug. It seems util-linux is all over the place lately.

I encountered the exact same error during my latest bootstrap. I got around it by bootstrapping with --variant=minbase, then installing the packages that required the systemd shim after chrooting into the new system. It wasn't really any extra trouble, as I had a substantial list of additional packages to install anyway.

Right, and that was the only part I had to edit. If you used the current script as-is, it never actually loads your ruleset. I'm not sure why he set it up that way, maybe to force you to actually read it before using it?

Another thing that might trip some people up is the fact that 'service nftables status' doesn't actually print anything, the way a lot of service scripts do. It just sets the exit value, so you will need to check that somehow. For example, this will give you a typical status message:

printf "nftables is "; if service nftables status; then printf "running.\n"; else printf "stopped.\n"; fi

Of course, you can always modify the init script to print a status message automatically.

Hi rdav, I'm happy to see you've solved your issue! I'll go ahead and answer your question anyway, in case someone else needs this information in the future. I created a file named /etc/X11/xorg.conf.d/20-intel.conf with the following contents:

Section "Device"
      Identifier "Intel Graphics"
      Driver "Intel"
      Option "DRI" "3"
EndSection

It's also necessary to have the xserver-xorg-video-intel package installed. In most cases, people will have installed X11 via the xserver-xorg virtual package which pulls in all of the drivers automatically, so installing this package manually isn't required.

Of course, the Intel driver will only work on systems with Intel iGPUs! The Xorg documentation recommends using the modesetting driver with later versions of Intel iGPUs, but apparently the Intel-specific driver will also work with them. My system has a 2nd gen i5, and I haven't noticed a difference either way.

Thanks stopAI! I didn't realize that pipewire-pulse was a separate program from pipewire itself. Apparently it can even send audio over the network, which is something I just happened to be looking for today:
https://gitlab.freedesktop.org/pipewire … rk-support