After a recent upgrade to Debian Stretch, my OpenVPN server stopped working. Checking the relevant log file,
/var/log/openvpn.log, I found the following not very helpful error message.
Fri Nov 23 16:46:37 2018 OpenVPN 2.4.0 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 18 2017 Fri Nov 23 16:46:37 2018 library versions: OpenSSL 1.0.2l 25 May 2017, LZO 2.08 Fri Nov 23 16:46:37 2018 daemon() failed or unsupported: Resource temporarily unavailable (errno=11) Fri Nov 23 16:46:37 2018 Exiting due to fatal error
Fortunately, someone already reported this error to debian and found out that the error is caused by the
LimintNPROC directive in systemd is used to limit the number of forks a service is allowed to make. Removing this limit, might not be the best idea. So, I would suggest that instead of commenting it out, to find out the minimal value that allows OpenVPN to start and work. After some testing, I found that the minimal value that worked for me is
After editing the
/lib/systemd/system/openvpn@.service, you need to reload the systemd service files and restart the OpenVPN server process.
$ sudo systemctl daemon-reload $ sudo systemctl status openvpn@server
There are three things that need to be updated in Debian Stretch in order to get the Radeon RX 550 running properly (or at all): kernel, mesa and proprietary binary firmware (bummer, I know).
First thing, make sure you have
stretch-backports in your apt-sources with all the relevant components.
$ deb http://ftp.debian.org/debian stretch-backports main contrib non-free
Now, the kernel that currently comes with stretch (4.9.0-8) is missing some important configurations:
CONFIG_DRM_AMDGPU_CIK. So you will need to install the latest one from the backports which does have the correct configuration.
$ sudo apt install -t stretch-backports linux-image-amd64
Next thing is getting the proper firmware
$ sudo apt install -t stretch-backports firmware-linux-nonfree
This will also update the
firmware-amd-graphics which provides the binary blobs that are needed by the amdgpu driver to work properly. The old version does not support the new Polaris 12 architecture used by the RX 550, while the version from the backports (
20180825) does support Polaris 12.
Now comes the part of upgrading mesa. There are a bunch binary packages that are derived from the mesa source package and we need to upgrade each one of them to version 18 (or later, but 18 is what is provided by the backports). The following two commands will upgrade any mesa related package already installed and then re-mark them as automatically installed (just to keep things tidy as they were).
sudo apt install -t stretch-backports $(grep-status -S mesa -a -FStatus "install ok installed" -s Package -n | sort -u) sudo apt-mark auto $(grep-status -S mesa -a -FStatus "install ok installed" -s Package -n | sort -u)
(credit for the last two lines). Now you can restart your computer and the RX 550 should work. You can test it using
$ DRI_PRIME=1 glxinfo | grep OpenGL
OpenGL vendor string: X.Org
OpenGL renderer string: Radeon 500 Series (POLARIS12, DRM 3.26.0, 4.18.0-0.bpo.1-amd64, LLVM 6.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.1.6
DRI_PRIME=1 is necessary, else
glxinfo would use the integrated card.
This is not necessary, but if
lspcidoes not properly display the RX 550, you will need to update the PCI IDs that are used to translate IDs to actual human-readable names.
$ sudo update-pciids
Final word, if you are using TLP for power management, it may not play nice with the RX 550. With TLP enabled I get pretty horrible performance out of it (regardless of being on AC or battery).
Debian only provides the ESR (Extended Support Release) line of Firefox. As a result, currently, the latest version of Firefox available for Debian Stretch is Firefox 52, which is pretty old. Lately, Firefox 57, also known as Quantum, was released as Beta. It provides many improvements over older Firefox releases, including both security and performance.
Begin by downloading the latest beta (for Firefox 57) and extract it to your home directory:
$ wget -O firefox-beta.tar.bz2 "https://download.mozilla.org/?product=firefox-beta-latest&os=linux64&lang=en-US" $ tar -C ~/.local/ -xvf firefox-beta.tar.bz2
This installs Firefox to your current user. Because Firefox is installed in a user-specific location (and without root-priveleges), Firefox will also auto-update when new versions are released.
If you prefer using the stable version of firefox, simply replace the first step by
$ wget -O firefox-stable.tar.bz2 "https://download.mozilla.org/?product=firefox-latest&os=linux64&lang=en-US"
Next, we take care of desktop integration. Put the following in
[Desktop Entry] Type=Application Name=Firefox Beta Exec=/home/guyru/.local/firefox/firefox %u X-MultipleArgs=false Icon=firefox-esr Categories=Network;WebBrowser; Terminal=false MimeType=text/html;text/xml;application/xhtml+xml;application/xml;application/vnd.mozilla.xul+xml;application/rss+xml;application/rdf+xml;image/gif;image/jpeg;image/png;x-scheme-handler/http;x-scheme-handler/https;
This tutorial walks you through patching an existing Debian package. It is useful if you want to create a
.deb of a package after fixing some bug or modifying the source in any other way. We will
hugin as our example.
We start by fetching the source package
$ apt-get source hugin $ cd hugin-2017.0.0+dfsg
We will need a tool named
quilt to make the process easier.
# apt install quilt
quilt we want to make it aware of the
debian/patches directory which holds the patches. Adding the following lines to
~/.quiltrc will make quilt search up the directory tree the
d=. ; while [ ! -d $d/debian -a `readlink -e $d` != / ]; do d=$d/..; done if [ -d $d/debian ] && [ -z $QUILT_PATCHES ]; then # if in Debian packaging tree with unset $QUILT_PATCHES QUILT_PATCHES="debian/patches" QUILT_PATCH_OPTS="--reject-format=unified" QUILT_DIFF_ARGS="-p ab --no-timestamps --no-index --color=auto" QUILT_REFRESH_ARGS="-p ab --no-timestamps --no-index" QUILT_COLORS="diff_hdr=1;32:diff_add=1;34:diff_rem=1;31:diff_hunk=1;33:diff_ctx=35:diff_cctx=33" if ! [ -d $d/debian/patches ]; then mkdir $d/debian/patches; fi fi
Now starts the actual patching process. The patches are applies in series, and our new patch should be the last one. We start by applying any existing patches, and then creating a new patch
$ quilt push -a $ quilt new 44_setlocale.patch
I chose the
44_ prefix because
hugin already has a patch named
43_fallbackhelp.patch and the convention is naming patches so the names reflect the order they are applied. Next we specify to
quilt which files we modify and then we edit them.
$ quilt add src/hugin1/hugin/huginApp.cpp $ vim src/hugin1/hugin/huginApp.cpp
Alternatively, instead of editing the files manually,
quilt import can be used to import an existing patch.
Each patch comes with its own metadata to let other people know who wrote it and what it does. Use
$ quilt header --dep3 -e
to edit this metadata. For example:
Description: Call setlocale() This fixes a bug in wxExecute, see https://trac.wxwidgets.org/ticket/16206 The patch has been submitted to upstream, https://groups.google.com/d/msg/hugin-ptx/FCi7ykPDZ5E/3w8E5U1SCQAJ Author: Guy Rutenberg <firstname.lastname@example.org> Last-Update: 2017-10-04 --- This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ See [DEP-3](http://dep.debian.net/deps/dep3/) for more details about the different fields.
After we finish editing we finalize the patch, and unapply all the patches
$ quilt refresh $ quilt pop -a
Now, you can continue to build the
deb from source as usual. We use
debchange to create a new version, and
debuild to build the package. After the package is build it can be installed using
$ DEBEMAIL="Guy Rutenberg <email@example.com>" debchange --nmu $ debuild -us -uc -i -I -j7
If you are building a package from source on Debian or Ubuntu, usually the first step is to install the build-dependencies of the package. This is usually done with one of two commands:
$ sudo apt-get build-dep PKGNAME
$ sudo aptitude build-dep PKGNAME
The problem is that there is no easy way to undo or revert the installation of the build dependencies. All the installed packages are marked as manually installed, so later one cannot simply expect to “autoremove” those packages. Webupd8 suggests clever one-liner that tries to parse the build dependencies out of
apt-cache and mark them as automatically installed. However, as mentioned in the comments, it may be too liberal in marking packages as automatically installed, and hence remove too many packages.
The real solution is
mk-build-deps. First you have to install it:
$ sudo apt install devscripts
Now, instead of using
aptitude directly to install the build-dependencies, use
$ mk-build-deps PKGNAME --install --root-cmd sudo --remove
mk-build-deps will create a new package, called
PKGNAME-build-deps, which depends on all the build-dependencies of
PKGNAME and then install it, therefore pulling all the build-dependencies and installing them as well. As those packages are now installed as dependencies they are marked as automatically installed. Once, you no longer need the build-dependencies, you can remove the package
apt will autoremove all the build-dependencies which are no longer necessary.
I’ve backported LyX 2.2.0-2 from Debian Testing to Jessie. The binaries for
amd64 can be found in https://www.guyrutenberg.com/debian/jessie.
You can add my repository by appending the following line to
deb https://www.guyrutenberg.com/debian/jessie ./
From time to time I build and backport
deb packages. Most of them are for my personal use, but sharing them would be nice. Another advantage for setting up a personal repository over directly installing
deb files is that you can install dependencies from that repository automatically. Especially useful if one source package builds multiple binary packages which depend on one another.
There is a list of programs ways how to setup such personal repository in the Debian wiki. However, I found most ways to be too cumbersome for my limited requirements. The way I’m describing below is probably the simplest and easiest way to get up and running.
First thing is installing
dpkg-dev which provides
sudo apt install dpkg-dev
Next put the
deb files you created in some local repository such as
cd into it.
# dpkg-scanpackages -m . | gzip -c > Packages.gz
will scan all the
*.deb files in the directory and create an appropriate
Packages.gz file. You need to repeat this step whenever you add new packages to
Finally to enable the new local repository, add the following line to
deb [trusted=yes] file:///usr/local/debian ./
[trusted=yes] options instruct
apt to treat the packages as authenticated. Alternatively, if you want to share it with others, make sure that your webserver serves the directory and point to it
deb https://www.guyrutenberg.com/debian/jessie ./
(You will need the
apt-transport-https in order to use https repositories).
Don’t forget to
apt update before trying to install packages from the new repository.
Some application rely on Internet Explorer to provide HTML rendering capabilities. Wine implements the same functionality based on a custom version of Mozilla’s Gecko rendering engine (the same engine used in Firefox). In Debian Jessie you have a package called
libwine-gecko-2.24 (the version is part of the name) which provides this rendering engine for Wine. However, different versions of Wine require different versions of wine-gecko. The package provided in Debian Jessie, matches the Wine version provided by
wine-development from the main Jessie repository (1.7.29). Unfortunately wine-development from the jessie-backports if of version 1.9.8 and requires wine-gecko of version 2.44 which is not provided by any Debian repository. This will lead to errors like
Could not load wine-gecko. HTML rendering will be disabled.
and blank spaces where HTML content would be rendered in many applications.
The solution would be to manually install the required version of wine-gecko. We start by downloading the MSI binaries provided by Wine
$ wget https://dl.winehq.org/wine/wine-gecko/2.44/wine_gecko-2.44-x86.msi $ wget https://dl.winehq.org/wine/wine-gecko/2.44/wine_gecko-2.44-x86_64.msi
Now install the required one, based on whether you are using 32bit or 64bit wine environment:
wine-development msiexec /i wine_gecko-2.44-x86.msi
(be sure the setup the correct
$WINEPREFIX if needed).