183 lines
9.2 KiB
Markdown
183 lines
9.2 KiB
Markdown
---
|
|
title: Solved Issues
|
|
description: A knowledgebase of all vicious errors I came across, and how I slew them.
|
|
published: true
|
|
date: 2022-04-30T20:10:42.177Z
|
|
tags: wireguard
|
|
editor: markdown
|
|
dateCreated: 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](https://wiki.gentoo.org/wiki/Docker#OpenRC) also shows how to set it up to use BtrFS (coincidentally - lucky you!).
|
|
|
|
[Docker also has an extensive page on BtrFS](https://docs.docker.com/storage/storagedriver/btrfs-driver/), 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](https://d.sb/2016/11/gpg-inappropriate-ioctl-for-device-errors).
|
|
|
|
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](https://wiki.archlinux.org/title/btrfs#Swap_file), 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](https://wiki.gentoo.org/wiki/LightDM). 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](https://wiki.gentoo.org/wiki/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?](/Compiling_on_RAM)
|
|
> To solve this permanantly, you can exclude problematic packages [as described here](https://wiki.gentoo.org/wiki/Portage_TMPDIR_on_tmpfs#Per-package_choices_at_compile_time).
|
|
|
|
## Cant' see/mount digital camera
|
|
After making sure all prerequisites are met for [USB](https://wiki.gentoo.org/wiki/USB/Guide), [MTP](https://wiki.gentoo.org/wiki/MTP), and following [Arch's methods to troubleshoot](https://wiki.archlinux.org/title/Media_Transfer_Protocol), all of which will be utterly uses, enable the `gphoto2` USE flag [as listed here](https://www.gentoo.org/support/use-flags/)
|
|
|
|
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`:
|
|
```yml
|
|
#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}
|
|
2. When loading assets in your page, avoid using the `{{ site_url }}` variable, and load using the full path instead:
|
|
```yml
|
|
#
|
|
# ^ WRONG
|
|
|
|
# Correct.
|
|
```
|
|
> Solved with assistance from this [Reference](https://github.com/jekyll/jekyll/issues/5709)
|
|
{.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:
|
|
```sh
|
|
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](https://github.com/filebrowser/filebrowser/issues/627) 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} |