Downgrading Packages in Arch Linux: The Worst Case Scenario

Background Story (You may Skip it)

Downgrading packages is a thing i don’t often encounter while using Arch. If something breaks, i wait for it to get fixed and the update again. But this time, the case was different. Late night, after a kernel (or libnl, i don’t remember) upgrade, my hostapd stopped working, complaining about shared libraries. Shockingly, i discovered that my hostapd was still at 0.7 while the latest stable version was at 2.0!(Reason provided at end) So i did an pacman -Sc to remove older hostapd versions from cache, which didn’t change anything, then made some correct changes and upgraded hostapd to 2.0. New problems in hostapd popped up, about nl80211 being unable to set my wlan to master mode. Now ahead of me was option of spending the rest of night desperately debugging the problem or study for the exam coming morning. Hostapd not working is a more serious issue for me.


I don’t know why, but i was pretty sure, it was some kernel related issue, so a kernel downgrade to 3.7.6 might be a good idea as hostapd was fine the day before. Arch Wiki has a decent article on How to Downgrade Packages. The whole idea is to get the old version tar.xz package and install it with pacman using the -U flag. Pretty much the same as installing the AUR package. But how do you get the older packages? The wiki describes 4 ways:

  • Use the Old version present in /var/cache/pacman/pkg : Shit! I did a pacman -Sc (removes the no installed packages) few minutes ago.
  • Use the Out of Sync Mirrors: There were a couple of out of synced out mirrors, but i couldn’t connect to any  (time out)
  • Use the Arch Rollback Machine (ARM): “contains archived snapshots of all the repos going back to 1 November 2009”. Nah, Too old.
  • Recompile the Package: Yup, this is the worst-case scenario which i deal in this post.

Dealing with the Worst Case Scenario

The Process works similar to the process involved in building packages from AUR, except getting the PKGBUILD and other files. Just reading the wiki took me some time to understand, so i am writing about it.

  • Search Your Package in Package Database, In my case, it was the linux  package.
  • In the upper right Package Section of the page, click on View Changes. You will now see all the commits made to that package sorted according to their age. Select the one which you want to get. Linux 3.7.6 in my case.
  • The page shows the diff of the commit with the previous commit. This is what you want. There are two ways to get these files. Click on tree and download all those files. To save you some manual work, another way is to use svn (Thanks to buhman at #archlinux). In the commit page, search for the line which begins with git-svn-id, The line has something like file:///srv/svn-packages@177020. That’s the revision number after the @, it might be anything. Open up the Terminal and shoot these commands
svn checkout --depth=empty svn://
cd packages
svn update -r 177020 linux    # Change it according to your requirements
cd linux/trunk/       # Change it according to your requirements

# Now its all the same as building AUR Packages
# If you downloaded the files manually, put them inside a directory
# Perform these actions inside that directory, or inside the trunk if you did the svn way.

makepkg -g >> PKGBUILD  # Do this to validate files if you manually downloaded the files
makepkg -s
sudo pacman -U *.pkg.tar.gz
# Done!
  • For community and multilib packages, replace svn:// with svn://

Nonsense Part Again

So, How was i running the older version of hostapd when there was a newer one in the repo? After little observation, i found the mistake. Earlier, i used the community-testing repo once, then i chose to disable it in the pacman.conf. Here i made a mistake, i commented everything i had to except [community-testing] line itself :|. Thus, the community-testing package list was always old and the little error about no mirrorlist midst lots of wget output always escaped my eyes. To make the matter worse, the [community-testing] comes before [community], thus a pacman -S hostapd always gave me the older version.

Did downgrading the kernel solve my problems? Nope, problem seems something with the 2.x versions of hostapd. So i decided to downgrade it to atleast 1.1 (better than 0.7 atleast) but, i did a damn pacman -Sc, right? Time to repeat these steps for hostapd. Finally everything back to track!


1 thought on “Downgrading Packages in Arch Linux: The Worst Case Scenario

  1. transistorleak

    I failed to compile the kernel I needed (after 2 hours of building…f**ck). The rollback machine is the best way to go, it has archives from the previous releases of a couple of years ago, is perfect. Another mistake to your scoreboard. 😀

    Great guide though, really helpful.


How did you feel about this post? Push in your reply!

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s