Create a file at /etc/modprobe.d/fix-my-sound.conf with this content:

options snd-hda-intel model=laptop position_fix=3 power_save=0 power_save_controller=N

Then rebuild the initramfs:

# update-initramfs -u -k all

And reboot.

No it isn't.

Some notes:

The official UEFI standard does actually support booting from an MS-DOS partition table. Whether the UEFI firmware in question supports that option is another matter entirely. I have two recent ThinkPads (E14 & P14s) that will boot in UEFI mode from an MS-DOS partition table.

I use SecureBoot with my own keys to lock out Microsoft. See also https://www.rodsbooks.com/efi-bootloade … ng-sb.html.

Devuan supports SecureBoot and should work just fine with it enabled. Recent machines may require that "third-party" certificates be allowed though. For example: https://download.lenovo.com/pccbbs/mobi … re_PCs.pdf

If the OP really is filling up their swap space then the real solution is to add more RAM. Adding more swap is just a work-around to help compensate for Linux's terrible OOM handling.

Apologies for the off-topic post but if the OP is struggling with this under systemd they can change the DefaultTimeout values in /etc/systemd/system.conf to avoid having to wait. Also, pressing <ctrl>+<alt>+<delete> more than seven times in two seconds should force a reboot without having to wait for the timeout.

A more "correct" solution would be to use the various x.systemd-* options for the share in /etc/fstab.

[/off-topic]

Or just make another swap partition and use both at the same time. Might be simpler.

EDIT: and faster, if they both have the same priority: https://tldp.org/HOWTO/Partition/setting_up_swap.html

Probably some stale configuration then.

Try moving the config stuff out of the way:

mv ~/.fluxbox{,.bak}

Then restart the desktop.

The chimaera live ISO works just fine with fluxbox:

That exact error is reported on the AUR package page. They used code tags there though

Did you try the sed command? All it does is add C_NUMERIC=en_US.UTF-8 to the beginning of the googleearth-bin line in /opt/google/earth/pro/googleearth.

Works fine for me in Arch using the AUR package that just downloads the .deb, unpacks it then packages it up again in a pacman-friendly format, so it should also work for you.

What errors are printed if you try to run it from a terminal?

EDIT:

$ pacman -Q google-earth-pro
google-earth-pro 7.3.6.9285-1
$

Just installed a fresh daedalus system (again) with the 2023-01-02 netinstall ISO and I cannot reproduce this problem:

I don't actually know what that "gnome system tools" thingy is so I just tried both time & date GUIs.

Is your system fully updated?

EDIT: and fuck me, is that desktop bloated. It's almost as bad as GNOME but without the sane UI.

I have heard rumours that it is possible to somehow install new packages via the interweb. Sounds like fake news to me but it might be worth looking into.

https://pkginfo.devuan.org/cgi-bin/pack … nf=0.99-10

If it is installed and you haven't used sudo or su - before attempting to run it I will be properly mad. You've been here long enough.

So check

rc-update
rc-status

It's a little bit different in Debian because traditionally run levels 2-5 are identical, unlike in other distributions (and even in some Debian derivatives) which use 3 for a console login and 5 for a graphical session.

Anyway I hate run levels, they're so limited. Targets ftw!

Indeed it does. Thanks dzz. I think the en_US.UTF-8 locale should be generated regardless of the selected system locale and I would have liked more choice in respect of filesystems (btrfs ftw!) but I do like that installer :-)

@OP: I also cannot reproduce this in EXE. You've clearly broken it. What did you do?