for svc in mdcheck_start.timer mdcheck_continue.timer; do systemctl stop ${svc}; systemctl disable ${svc}; done

This works on Ubuntu 20.04. Probably also on other systemd managed systems.

Trying to configure a Mikrotik Routerboard, I found that when booting SwOS, DHCP does not work. That is, the Routerboard, in my case a Cloud Router Switch CRS 317-1G-16S+, would send out DHCP requests but not get an IP address.

Turns out this is because the DHCP client of SwOS 2.7 is picky, and the dnsmasq DHCP server sent an offer that was not accepted by SwOS.

Using udhcpd as a dhcp server instead, the switch accepted the IP address just fine. I could then update the firmware; from 2.8 on, the SwOS DHCP client is more tolerant of DHCP offers. One of the changes in the SwOS 2.8 release notes says ‘make DHCP client work with RFC non compliant DHCP servers’. At any rate, 2.9 was happy with dnsmasq DHCP offers.

Unable to negotiate with target-host port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

or

Unable to negotiate with target-host port 22: no matching cipher found. Their offer: blowfish-cbc

Since version 7, OpenSSH has disabled these by default because of known weaknesses, see www.openssh.com/txt/release-7.0. To talk to these obsolete SSH services, speak the following Ancient Options under a full moon:

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -oCiphers=+blowfish-cbc my-user@target-host

.. and the doors to Moria may open.

Edit feb-2019: Recent Ubuntu versions have dropped support for legacy ciphers. You might see this error:

command-line line 0: Bad SSH2 cipher spec '+blowfish-cbc'.

In that case it may be best to install package “openssh-client-ssh1″ and use the “ssh1″ binary instead.

I was trying to build a recent u-boot (for olinuxino-lime2), with the Ubuntu 16.04 supplied arm-linux-gnueabihf-as as supplied in package binutils-arm-linux-gnueabihf 2.26-8ubuntu2.1 that was installed as a dependency with apt-get install gcc-arm-linux-gnueabihf 4:5.3.1-1ubuntu1. I then got the following error:

  CC      arch/arm/cpu/armv7/sunxi/psci.o
{standard input}: Assembler messages:
{standard input}:302: Error: push/pop do not support {reglist}^ -- `pop {r0,r1,r2,r3,r4,r9,ip,pc}^'
scripts/Makefile.build:280: recipe for target 'arch/arm/cpu/armv7/sunxi/psci.o' failed
make[2]: *** [arch/arm/cpu/armv7/sunxi/psci.o] Error 1
scripts/Makefile.build:425: recipe for target 'arch/arm/cpu/armv7/sunxi' failed
make[1]: *** [arch/arm/cpu/armv7/sunxi] Error 2
Makefile:1210: recipe for target 'arch/arm/cpu/armv7' failed
make: *** [arch/arm/cpu/armv7] Error 2

This appears out to be due to a bug in gcc, possibly https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70830. I had better luck with Linaro’s https://releases.linaro.org/components/toolchain/binaries/5.3-2016.02/arm-linux-gnueabihf/gcc-linaro-5.3-2016.02-x86_64_arm-linux-gnueabihf.tar.xz as mentioned by Robert Nelson.

Useful trick here is to add a custom header for each of the sections, like so:

server {
add_header X-My-Debug-Header-01 srv;
listen 80 default_server;

location ~ test\.php$ {
add_header X-My-Debug-Header-02 loc-test-php;
try_files $uri =404;
fastcgi_pass unix:/var/run/php5-fpm.sock;
include fastcgi_params;
}

location /pictures {
add_header X-My-Debug-Header-03 loc-pictures;
alias /usr/share/nginx/html;
index index.php index.html index.htm;
}

}

Now, for each section match, there will be a convenient header which can be viewed with e.g. wget --server-response (wget -S) or curl --head (curl -I).

Caveats: the Firefox LiveHTTPHeaders plugin doesn’t seem to show non standard headers. Also, when nginx serves a 40x or 50x, the custom header tends not to get served.

PHP Warning: POST Content-Length of 15148998 bytes exceeds the limit of 8388608 bytes in Unknown on line 0, referer: https://your_site.com/your_uri/wp-admin/themes.php?page=custom-background

So what is needed is a higher upload limit. In /etc/php5/apache2/php.ini (or corresponding file in your distro, if you use Apache), change post_max_size and upload_max_filesize to something appropriate.

An additional issue I had is where my blog is not on the root of its vhost/domain. So check in what filesystem directory the uploaded files end up, and whether the uploads link points at the right place on your filesystem. The wordpress config files should have the upload directory specified in e.g., on Ubuntu/Debian, /etc/wordpress/config-your_site.com.php.

I thought my TRIMs were being blocked by the virtualization/LVM stack, but it turns out the bare device won’t be TRIMmed either.

# fstrim /mnt/sde/
fstrim: /mnt/sde/: FITRIM ioctl failed: Operation not supported

According to this Algolia blog article there has been an kernel bug affecting these drives (mine is a Samsung 850 PRO 1TB), so I guess it has been blacklisted for the time being.