shmick/wiki
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Files
master
wiki/Solved_Issues.md

9.2 KiB
Raw Permalink Blame History

title, description, published, date, tags, editor, dateCreated
title description published date tags editor dateCreated
Solved Issues A knowledgebase of all vicious errors I came across, and how I slew them. true 2022-04-30T20:10:42.177Z wireguard markdown 2021-08-25T20:27:57.673Z

General Linux Things

Just because you run into errors in a specific distribution (Gentoo!) does not mean it is at fault - some things just happen, and you'll just have to accept that.

Docker doesn't use BtrFS

I'm not sure if this is an error bit or a configuration bit (I think it should do it by default), but Docker doesn't always (if at all?) use the BtrFS driver when actually sitting on BtrFS, which is a loss in efficiency and performance (I think). The Gentoo wiki's page on Docker also shows how to set it up to use BtrFS (coincidentally - lucky you!).

Docker also has an extensive page on BtrFS, though it seems a bit systemd-centric.

This will also be added to the install checklist, once I bother writing one.

Gitea denies SSH access despite good key

As I've learned the hard way, Gitea has its SSH directory under data/git (and under data/ssh, which is surprisingly irrelevant here), and any change in permissions of this directory will bork all SSH access.

If you come across denied SSH access with keys that worked before, or find the following in the log - Authentication refused: bad ownership or modes for file /data/git/.ssh (really seems obvious now, does it?), chmod the directory to 700, and the authorized_keys file inside it to 600.

Inappropriate ioctl for device when decrypting GnuPGP File

Like all great things Linux, the answer came from a random blog on the web.

Quote: To solve the problem, you need to enable loopback pinentry mode.

  • Add this to ~/.gnupg/gpg.conf: use-agent pinentry-mode loopback
  • Add this to ~/.gnupg/gpg-agent.conf, creating the file if it doesn't already exist: allow-loopback-pinentry
  • Restart the agent with echo RELOADAGENT | gpg-connect-agent

and you should be good to go!

Confirmed working, and just in case - it seems to be a GUI thing.

Snapper can't create root snapshots

Snapper can't create root snapshots

This on is fully on you, partner. Two things are at fault:

  • Snapper really doesn't like it when the entire .snapshots gets wiped under its' feet.

  • Snapper cannot snapshot a volume which has an active swap file on it

To avoid such errors, you must

  • Use snapper's really vague delete-config command, or wipe the config file from /etc/conf.d/snapper and /etc/snapper/configs/ before wiping snapshots completely

  • Use a separate subvolume for the swapfile, as Mentioned in the Arch Wiki, which I skimmed.

Do not skim read the Arch wiki, you waffle! {.is-danger}

Gentoo

Don't be fooled by the location and prominence of this list - Gentoo is fantastic, and it's always my fault.

No GUI

Uh oh! did you mess it up that bad already? Try the following:

  • Make sure all prerequisites are set as outlined here. This is relevant mostly for new installations.
  • Read the display manager's log /var/log/gdm/[log]. Unless the error is really obvious, this won't help.
  • Try running gdm manually from the root user.
  • What does /etc/conf.d/display-manager say? it should be whatever display manager you're trying to use (ex: DISPLAYMANAGER="gdm"). If updating it, run openrc afterwards.
  • Try a lighter, more portable display manager. LightDM is a good candidate.
  • If all else fails, try recompiling (or reinstalling) GDM, and if that fails - GNOME in it's entirety (and bid your afternoon goodbye...) Step #5 is usually it - whatever it does, it solves for GDM as well.

Pre-compilation check fails

Did you try to compile a massive package Without looking here first?

To solve this permanantly, you can exclude problematic packages as described here.

Cant' see/mount digital camera

After making sure all prerequisites are met for USB, MTP, and following Arch's methods to troubleshoot, all of which will be utterly uses, enable the gphoto2 USE flag as listed here

Run a quick emerge --update --newuse --deep --with-bdeps=y --keep-going @world, a swift emerge @preserved-rebuild and a lively emerge --depclean if you're feeling extra snazzy and voilà!

Icons on GNOME look like they've escaped from hell

Switch to Clang. Why? who knows? not me. But it did it.

It likely did not do it. {.is-info}

Steam does not start

Yes, I used to think this was a Wayland thing. It is not a Wayland thing. If updating does not solve the error, simply run steam --reset, which, um, steam resets and solves it.

Tested on Native overlay - not on Flatpak. We like the native overlay now. {.is-info}

libvirt can't load AppArmor profile

We like AppArmor. We like libvirt for KVM virtualization. Unfortunately, they often don't like each other.

Fortunately, you can disable their interaction on both ends:

  • AppArmor: aa-complain /usr/sbin/libvirtd

  • libvirt: set security_driver = “none” in /etc/libvirt/qemu.conf

Keep in mind this is likely a security risk, especially for Windows guests. Though AppArmor devs do refer to libvirtd as an "inherently trusted process", which is nice. {.is-warning}

Overall, unpleasant.

make doesn't copy vmlinuz to boot partition after compiling

You forgot to select the kernel with eselect kernel, you twit.

Wireguard

Wireguard does not work

I've tried to outsmart this, and I wish I could say better, but it's really simple: purge the container, reset to the defaults.

Swallow your pride. VPNs are rough.

The docker-compose on the Git server works great.

Cannot access internal containers through Wireguard

Appearantly, even though you're coming from inside the network via Wireguard, your queries still go through the firewall as though you're from outside (all of the above likely blatantly wrong). To get a container to work, allow its' internal port through the firewall:

ufw allow #[/tcp|udp] ufw reload

example: I had to run ufw allow 3333 to access this wiki! {.is-info}

Seafile

New Seafile container can't sign SSL certificate

Unfortunately, the Seafile demands its' own certificate and can't get it via the reverse proxy - simply off the main proxy container, switch the seafile to ports 80 and 443 (won't work otherwise!) and let it generate it's inital certificate. You can revert to the reverse proxy just fine after that.

Jekyll

Mixed Content warning behind reverse proxy

There are two actions needed to prevent Jekyll serving assets over http, thus creating this warning and blocking assets on mobile:

  1. In the configuration file _config.yml, comment out the baseurl variable, and put the site's exact address under url:
#baseurl: "" # the subpath of your site, e.g. /blog
url: "https://jekyll.pukeko.xyz" # the base hostname & protocol for your site, e.g. http://example.com

Make sure there are no trailing slashes! {.is-warning}

  1. When loading assets in your page, avoid using the {{ site_url }} variable, and load using the full path instead:
#![Pukeko](https://{{ site_url }}/assets/pukeko.jpeg)
# ^ WRONG
![Pukeko](https://jekyll.pukeko.xyz/assets/pukeko.jpeg)
# Correct.

Solved with assistance from this Reference {.is-info}

Nextcloud

Nextcloud PostgreSQL complains about missing /var/lib/postgresql/data/pg_stat_tmp/global.tmp

Now this one is wierd. If you search for it, the file is there, but isn't quite there:

ls: cannot access 'global.tmp': No such file or directory
-????????? ? ?        ?        ?            ? global.tmp

Even stranger, online search yields these errors are either hardware failure or failed network shares, none of which are the case here. The file cannot be chmod-ed, deleted or otherwise manipulated - even with root privileges. Thankfully, the fix is simple:

  1. Shut down the container.
  2. Maybe take a snapshot.
  3. Delete the pg_stat_tmp folder
  4. Watch as PostgreSQL complains, creates the file anyway and works.

Filebrowser

Internal filebrowser commands fail to execute

I tried disabling authentication (as this is behing Authelia), but running any filebrowser binary command returns timeout:

2021/11/10 17:55:02 timeout

This is because the database Can't be modified while Filebrowser is running. As it turns out, you can execute offline using docker-compose:

docker-compose run file-browser config set --auth.method=noauth

This will only work when the container is offline! {.is-warning}

Be sure to clean up the new run instances with docker-compose down before restarting. {.is-info}