Solved: Regular WiFi Disconnections

After upgrading to Ubuntu 21.10 I noticed that my WiFi was disconnecting semi-regularly and trying to reconnect multiple times without success until after roughly 1 minute it was connected again. I’ve never had this kind of issues even after switching to iwd several years back.

Trying to find out what was happening I looked into my WiFi daemons logs with journalctl -eu iwd. Around the time a disconnect happened there were roughly 30 lines each 1-2 seconds apart all saying:

Received Deauthentication event, reason: 4, from_ap: false

There was no other information warning or error. The timings between these blocks are not always consistent. Mostly it’s 2 hours or 2 hours 15 minutes.

NetworkManager’s logs only had this to say (also repeated multiple times):

device (wlan0): new IWD device state is disconnected
device (wlan0): state change: activated -> failed (reason 'supplicant-disconnect', sys-iface-state: 'managed')
manager: NetworkManager state is now DISCONNECTED
device (wlan0): Activation: failed for connection '<SSID>'
device (wlan0): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed')
dhcp4 (wlan0): canceled DHCP transaction
dhcp4 (wlan0): state changed bound -> terminated
dhcp6 (wlan0): canceled DHCP transaction
dhcp6 (wlan0): state changed bound -> terminated
device (wlan0): new IWD device state is connecting
device (wlan0): Activation: starting connection '<SSID>' (<UUID>)
device (wlan0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
manager: NetworkManager state is now CONNECTING
device (wlan0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
device (wlan0): new IWD device state is connected
device (wlan0): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
dhcp4 (wlan0): activation: beginning transaction (timeout in 45 seconds)
dhcp4 (wlan0): state changed unknown -> bound, address=<IP ADDRESS>
device (wlan0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed')
device (wlan0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'managed')
device (wlan0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed')
manager: NetworkManager state is now CONNECTED_LOCAL
manager: NetworkManager state is now CONNECTED_SITE
policy: set '<SSID>' (wlan0) as default for IPv4 routing and DNS
device (wlan0): Activation: successful, device activated.
manager: NetworkManager state is now CONNECTED_GLOBAL

I tried to search the internet for the error message from iwd, but nothing useful came up. Just forum posts with random suggestions like “turn off IPv6” and old kernel bug reports about the Intel wireless drivers exhibiting similar disconnections. 😞

I tried to look up what a modern setup + configuration should look like and tried to combine the guides from Ubuntu and Arch … no change.

The Gentoo Wiki and the iwd Wiki also suggest (wifi.iwd.autoconnect=yes) for NetworkManager. After applying this setting the issue seems to have gone away. 😀

Update 2021-10-31

The last “fix” only lasted for about 9 hours. 😕

I’m now suspecting something with power management 🤔 … I’m still investigating.

Update 2021-11-26

I have a configuration that seems to work for a few weeks now. My final system state was adding


to NetworkManager’s configuration, masking wpa_supplicant.service, commenting out the contents of /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf, installing all recommended packages for TLP (i.e. also tlp-rdw) and finally masking Gnome 40’s new power-profiles-daemon.service which seems to interfere with TLP.

I’m not sure if this is the minimal set of changes necessary, but it works for me. 😀 It first started showing the dis-/reconnection notification, but e.g. SSH connections didn’t seem to drop and after a while even the notifications stopped. Logs are also clean. I’m happy. 😀

X: the dumbest OS you’ve ever seen

For future reference: Daniel Stone dispels myths about “great” X is and why it’s actually former X maintainers that designed and implemented Wayland.

Aktivieren Sie JavaScript um das Video zu sehen.

Usefulness of Swap Explained

Chris Down explains how swap’s main role is being the missing backing store for anonymous (i.e. allocated by malloc) pages. While all other kinds of data (e.g. paged-in files) can be reclaimed easily and later reloaded, because their “source of truth” is elsewhere. There’s no such source for anonymous pages hence these pages can “never” be reclaimed unless there’s swap space available (even if those pages aren’t “hot”).

Linux has historically had poor swap (and by extension OOM) handling with few and imprecise means for configuration. Chris describes the behavior of a machine with and without swap in different scenarios of memory contention. He thinks that poor swap performance is caused by having a poor measure of “memory pressure.” He explains how work on cgroups v2 might give the kernel (and thus admins) better measures for memory pressure and knobs for dealing with it.

How to to set up Gitlab on Debian

Update: This howto is outdated. GitLab has changed a lot since it was written and a lot of it is not applicable anymore (e.g. since GitLab 5.0 it doesn’t depend on Gitolite any more and only needs one system user to be setup). So you are probably better off using the official installation guide. 🙂

If you want to install Gitlab on Debian you can easily follow their installation steps for Ubuntu. But be careful there are a few gotchas nobody is talking about.

The following steps will assume you are root.


First make sure you have all the latest updates installed.

aptitude update
aptitude full-upgrade

Then we have to install a few packages.

aptitude install git-core wget curl gcc checkinstall libxml2-dev libxslt-dev sqlite3 libsqlite3-dev libcurl4-openssl-dev libc6-dev libssl-dev libmysql++-dev make build-essential zlib1g-dev libicu-dev redis-server sudo

Install Ruby

If you have not installed ruby you might want to consider using RVM.

Install it with

bash -s stable < <(curl -s

It will be installed into /usr/local/rvm.

Ask it for the requirements for installing MRI and install them.

rvm requirements
aptitude install build-essentials ...

Install ruby and make it the default.

rvm install 1.9.3
rvm --default use 1.9.3

You should install a minimum set of gems. Add “passenger” if you are running Apache as your web server or “thin” if you are using Nginx.

gem install bundler

Install Gitolite

First of all we want to create a dedicated user for Gitolite and Gitlab. This will also be the user the Rails processes will be running in (this is important later).

adduser \
  --system \
 --shell /bin/sh \
 --gecos 'Git Version Control' \
 --group \
 --disabled-password \
 --home /home/git \

Configure git for the new user.

sudo -u git -H git config --global "git@your-server.tld"
sudo -u git -H git config --global "Gitlab Admin"

Generate the ssh key for the git user. It will be saved in /home/git/.ssh/id_rsa. We will run Gitlab as the git user so it will use this key to authenticate against Gitolite.

sudo -u git -H ssh-keygen -t rsa -b 2048

Copy the public part of the key for later use when we setup Gitolite.

sudo -u git -H cp /home/git/.ssh/ /home/git/

After that we install Gitolite. In contrast to the Gitlab documentation I installed it from the Debian repositories.

aptitude install gitolite

It will not be fully installed as it will tell you something like:

No adminkey given – not initializing gitolite in /var/lib/gitolite.

So we do this by using dpkg-reconfigure and using our previously prepared account.
When prompted, answer as follows:

  • Gitolite user: git
  • repositories directory: /home/git
  • admin key: /home/git/
dpkg-reconfigure gitolite

Now you should have Gitolite set up in the /home/git directory. But we will still have to tweak it a little.

Edit /home/git/.gitolite.rc and find the line that reads “REPO_UMASK = 0077;” and change it to “REPO_UMASK = 0007;” (i.e. three zeros).

You now need to change the directory privileges on the /repositories directory so Gitlab can use them

sudo chmod -R g+rwX /home/git/repositories/
sudo chown -R git:git /home/git/repositories/

Gitolite should be ready now.

You can test it by cloning the admin repository:

sudo -u git -H git clone git@localhost:gitolite-admin /tmp/gitolite-admin
rm -rf /tmp/gitolite-admin

Install Gitlab

Install a few prerequisites.

aptitude install python-dev python-pip redis-server libicu-dev
sudo pip install pygments

Clone Gitlab

git clone git:// gitlab
cd gitlab

We create a gemset for Gitlab to not pollute the global gemset. To automate this we will use a .rmvrc inside the Gitlab directory. RVM will make sure it will be loaded automatically whenever you enter the directory.

echo "rvm use 1.9.3@gitlab --create" > .rvmrc

cd into directory to make rvm use the .rvmrc and accept with “y”.

cd .. && cd gitlab

Check your current gemset with

rvm current

It should show something like “ruby-1.9.3-p0@gitlab”.

Now you might need to update Gitlab’s Gemfile (e.g. add the mysql2 gem for MySQL databases).

Now install the gems necessary for running Gitlab.

bundle install --deployment

You may need to run “bundle install –no-deployment” to pick up changes to the Gemfile and rerun the previous command.

Edit config/gitlab.yml to configure Gitlab. If you have followed this howto you should only need to update the “email” section and the “host” option in the “git_host” section.

You might want to edit config/application.rb and update the time zone and locale configurations.

Edit config/database.yml and set up your database configuration.

Now set up and initialize your database.

bundle exec rake db:setup RAILS_ENV=production
bundle exec rake db:seed_fu RAILS_ENV=production

Install with Passenger + Apache


Install with Thin + Nginx