I wouldn't say there's anything's wrong with it, but it's in an entirely different class from the other WMs being discussed here. It's not so much a window manager as a full-blown desktop environment. I checked in aptitiude, and installing XFCE4 on my system would require downloading 500 MB of new files. It depends on PulseAudio and a whole bunch of other things I don't have installed. By contrast, cwm is less than 200 KB, and twm, if you include the menu package, is less than 2 MB. They don't depend on anything that's not already installed on my (very basic) system.

I'm not saying that makes them better, it's just a different way of doing things. It certainly makes them more suitable for running on older hardware with marginal specs. I have Devuan running on one machine that's 15 years old, with a 1.4 GHz processor, and it's perfectly usable. I'm pretty sure it would chug with XFCE, and Gnome or KDE would almost certainly be unusable.

We were just discussing this issue in another thread, as I recently discovered the version of Firefox in the repositories does not require PA. According to other posters, it never has, so I must have been remembering some other distribution.

FWIW I also noticed my PA settings were being reset on every reboot with Devuan, but I only had it installed briefly, and never tried to fix the issue.

Is there an advantage to installing uBO through the repository? I wasn't aware of this option, so I had just installed it through the regular add-on mechanism. None of my other extensions (such as Greasemonkey, Dark Reader, or Gesturefy) appear to be available in the repositories, so I'm wondering why uBO was singled out for this treatment.

Thanks, I just tried mmdebstrap on an old MacBook and it worked perfectly. This tool, along with the arch-install-scripts, makes bootstrapping a breeze. I have a small stack of old laptops here I've been resurrecting, mainly as an experiment. Each one has shocked me with how completely usable it is with a lightweight Devuan installation.

Edit: I forgot all about the merged usr issue until I got farther along in the process. If you want to run a merged usr, mmdebstrap doesn't have the equivalent of debootstrap's --merged-usr option. However, the manual gives an example of how you can duplicate the functionality with hooks:

--setup-hook='for d in bin sbin lib; do ln -s usr/$d "$1/$d";
        mkdir -p "$1/usr/$d"; done'

Since I had forgotten about it until after the bootstrap was complete, I just installed the usrmerge package.

Sorry Marjorie, I'm not sure why I didn't see your post when I searched for help on this issue. I'm glad you went ahead and posted the whole script in this thread, since the maintainer has said he might remove it from future versions.

Edit to add: I see you also said this nftables init script is included in recent versions of orphan-sysvinit-scripts. I'm not familiar with that package, but I just read the description, and it sounds as if it should install the script for you automatically when you install the nftables package.

Looking at the end of your Xorg.0.log, I see it progressively failing to load various video drivers due to permission issues, then exiting with a "no screens found" error:

[   646.568] (EE) open /dev/dri/card0: Permission denied
[   646.568] (WW) Falling back to old probe method for modesetting
[...]
[   646.569] (EE) Unable to find a valid framebuffer device
[   646.569] (WW) Falling back to old probe method for fbdev
[...]
[   646.569] (EE) open /dev/fb0: Permission denied
[   646.569] vesa: Refusing to run, Framebuffer or dri device present
[   646.569] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[   646.569] (EE) Screen 0 deleted because of no matching config section.
[...]
Fatal server error:
[   646.569] (EE) no screens found(EE) 

A similar thing happened to me several days ago after an Excalibur update. The system had an Intel iGPU and had been using the modesetting driver, which stopped working for unknown reasons. I suspect it was related to the usrmerge issues, as it happened at the same time as other confirmed usrmerge issues. I was able to get X running again by forcing it to use the Intel driver. It's possible the modesetting driver would work again now that I've merged /usr, but I haven't had a chance to test it.

The issue JWM-Kit references likely doesn't affect you if you're running Windows 7. As far as I can tell, Windows' "fake shutdown" "fast startup" was implemented starting in Windows 10.

For those unfamiliar with this "feature," here's how it works. When you tell Windows 10+ to "shut down," it just... lies to you. It instead invokes sleep state S4, aka hibernation or suspend to disk. Whether or not you pull the plug at this point has no bearing, as power is not required in S4, because the system state has been saved to non-volatile memory. If you want Windows to actually shut down, you need to hold down Shift when you select the shut down option. Fast startup can also be permanently disabled in Power & sleep settings.

Thanks for the info, everyone. I was dreading having to install PA, but some applications absolutely require it.

Does anyone know if PW supports CLI control in the same way as PA, for example, with pactl & pacmd? I need it for my volume hotkey scripts, among other things. More on PA CLI control here:
https://shallowsky.com/linux/pulseaudio … -line.html

Apparently dpkg started displaying a warning about this issue to users sometime last year, I'm not sure if it still does. Someone filed a bug report about it last year:
https://bugs.debian.org/cgi-bin/bugrepo … 994388#132
More discussion at lwn.net, including a comment from the responsible party, and some critical responses:
https://lwn.net/Articles/889026/
I can't vouch for the accuracy of the comments, but one person in the lwn.net thread posted the following:

I may have encountered this issue today when I upgraded Excalibur on a couple of different laptops. I saw some eudev errors during boot, but I wasn't able to find any related info anywhere in /var/log. Is there somewhere else these errors might have been logged?

Anything that accessed the display backlight had stopped working: console blanking no longer turned off the backlight, and brightnessctl couldn't find the display. Also, I'm not sure if it was related, but X would no longer start with the modesetting driver. Oddly, it still worked with the Intel and nouveau drivers (on different machines.)

I went ahead and installed the usrmerge package. It failed on the first pass, but I got lucky, and only had to delete a few relatively unimportant files to get it to finish. Everything seemed to be working normally again on the next boot, with no errors reported.

Edited to add: I just ran usrmerge on the second laptop with zero errors, which was a pleasant surprise. The backlight is working again on this machine as well; however, a Minecraft server is still failing to start, so it appears I still have other issues. The Minecraft issue was due to a Java update, and unrelated to usrmerge. All is now working on this system as well.