Moving to Manjaro from Windows

December 7, 2025

So far the transition has been pretty painless. A couple of things to note though that I’ve bumped into so far. My main drive is not the home drive for the operating system. Everything that I care about is on two ntfs formatted drives. When I transitioned, I made sure there was nothing important on the main drive a simple blew away the home drive and installed Manjaro.

First Problem NTFS:

Manjaro (and really all non-windows OS) doesn’t really like ntfs. There is no open source equivalent of chkdsk. If the system crashes (new installs can be unstable, this one has been) and the ntfs drive is “in use” (a file is open, a directory is open whatever) the probability of it having a “dirty bit” set is very high. And then linux respects the dirty bit and won’t really play with the drives. There is a utility (ntfsfix) that can reset the dirty bit, but that’s all it does. If there really are problems on the drive (this is both possible and frequent) the only solution is chkdsk.

To manage this you can install “windows” to a USB drive, boot into that, run chkdsk and all will be well. The version I’m using is Hiren’s boot CD. Works exactly as advertised… I don’t have to “do” anything except run chkdsk and get out. It is NOT swift but it works. There are other USB windows setups out there. Let me know if you find a swift one.

Next problem rtw8822bu driver:

This is pretty specific to my hardware. This desktop never had a wifi card or wifi chipset on the motherboard. The easy solution is a USB key that does WiFi. I upgraded a while back (4 years ago) to a TP-Link T3U Plus USB wifi key and it worked like a hot damn for windows. On Manjaro it’s a bit of an unstable mess. System wide crashes, random “bad connection” and outright failures of the wifi connection. It’s been making me a bit crazy if I’m honest. I started by looking at dmesg. There were some ugly things in there including

rtw_8822bu 1-11:1.0: write register 0xc4 failed with -71 
rtw_8822bu 1-11:1.0: rtw_usb_reg_sec: reg 0x4e0, usb write 1 fail, status: -71 
rtw_8822bu 2-5:1.0: failed to get tx report from firmware
wlp0s20f0u5: deauthenticated from e4:f4:c6:06:b8:33 (Reason: 16=GROUP_KEY_HANDSHAKE_TIMEOUT)
rtw_8822bu 2-5:1.0: error beacon valid
rtw_8822bu 2-5:1.0: failed to download rsvd page
rtw_8822bu 2-5:1.0: failed to download firmware
rtw_8822bu 2-5:1.0: leave idle state failed
rtw_8822bu 2-5:1.0: failed to leave ips state

Not exactly sure what was going on there but the last block of errors and fails meant that the wifi was gone altogether. The first two were consistent on every load of the system.

It turns out that the “in-tree” (that would be native to the current kernel) driver for the realtek chipset in the usb key is not happy with this device. It doesn’t play nice with this and you can find many posts in the Manjaro and Arch Linux forums talking about it. The link is to the “solution” which is fine if you know what you’re doing but I don’t. I had to go looking for how to do this correctly and completely. For me this is what worked.

The main thread to this is you install a driver from github and then blacklist the existing unstable driver. The driver is made available by the very generous individual RinCat. I did a dkms install (which means the integration with the kernel is nicer and it’s supposed to update with the kernel if it’s needed).

Steps to get there:

Make sure your system is completely up to date

sudo pacman -Syyu

Install the Kernel Headers for your kernel

sudo pacman -S $(pacman -Qsq "^linux" | grep "^linux[0-9]*[-rt]*$" | awk '{print $1"-headers"}' ORS=' ')

Install dkms (if it’s not already installed), this is the management system for kernel modules that aren’t already in the installed kernel)

sudo pacman -S dkms

Next clone the driver from github

sudo git clone "https://github.com/RinCat/RTL88x2BU-Linux-Driver.git" /usr/src/rtl88x2bu-git

edit the dkms.conf to point to the correct version in the source and make a symlink so the dkms install will work correctly and find the source code

sudo sed -i 's/PACKAGE_VERSION="@PKGVER@"/PACKAGE_VERSION="git"/g' /usr/src/rtl88x2bu-git/dkms.conf
sudo dkms add -m rtl88x2bu -v git

Finally build and install the kernel module (driver) for the USB key

sudo dkms autoinstall

Now before we reboot we have to blacklist the existing in tree driver. To prove that this driver is currently the one being loaded use

lsmod | grep rtw88

In my case it brought up the following

rtw88_8822bu 12288 0
rtw88_usb 36864 1 rtw88_8822bu
rtw88_8822b 229376 1 rtw88_8822bu
rtw88_core 327680 2 rtw88_usb,rtw88_8822b
mac80211 1634304 2 rtw88_core,rtw88_usb
cfg80211 1384448 2 rtw88_core,mac80211

in theory the following should just work

echo "blacklist rtw88_8822bu" > /etc/modprobe.d/rtw8822bu.conf

however that fails with permission denied as does putting sudo in front of it. Instead this is what worked for me.

sudo nano /etc/modprobe.d/rtw8822bu.conf

add “blacklist rtw88_8822bu” (don’t include the quotes) into the file and save and exit.

NOW reboot.

Once you’ve rebooted you’ll have to re-enter the password for the wifi connection and all should be well. If that’s not working for you a couple of things can be done.

  1. check to see that the driver has loaded correctly
lsmos | grep 88x2bu

in my case it returned

88x2bu               5136384  0
cfg80211             1384448  1 88x2bu

which is apparently just what I need as my network connection is now stable.

  1. Fiddle with USB mode settings for the wifi key.

Temporary USB Mode Setting
You can try forcing USB 3.0 mode:

modprobe 88x2bu rtw_switch_usb_mode=1

If you experience issues (driver restart loop), revert to USB 2.0 mode:

modprobe -r 88x2bu
modprobe 88x2bu rtw_switch_usb_mode=2

Permanent USB Mode Setting
To set the USB mode permanently, create a configuration file:

echo "options 88x2bu rtw_switch_usb_mode=1" > /etc/modprobe.d/99-RTL88x2BU.conf

Replace rtw_switch_usb_mode=1 with rtw_switch_usb_mode=2 if you want to force USB 2.0 mode permanently.

This came out of this article primarily, following the dkms instructions.

As always your mileage may vary.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.