Weekend with ArchLinuxARM 2: Arch Madness

Jason Charney
11 min readJun 23, 2019

--

Update (7/30/19): DNSSEC had been the culprit for why connecting to the Internet was so frustrating. This has been amended to this article.

Who knew that it would take at least a couple of months for me to write the followup to “Weekend with Arch Linux”.

There is sort of a joke that’s been around for a while about how installing Arch Linux is a sign of having no life. About how you “claim to install Arch Linux, but never did or just gave up on it.”

And then you realize the people who make those statements clearly didn’t try, or that the guidance to do something like this ended at the first part where it ended on how to format a microSD card.

I am here to say, that I HAVE INSTALLED ARCH LINUX ARM!

And what better device that to show this achievement on than my old hacktop, which is a Raspberry Pi connected to a Motorola Atrix Lapdock.

I own you guys some pictures and a long discussion about that device, but let’s pickup from where we left off.

First a couple of caveats…

There are a couple of things that I just haven’t quite smoothed out yet, namely making sure Wi-Fi remembers to look for my network. A separate article on this issue will need to be written about that later, this is so that you don’t have to put yourself through the same hell that I had to go through where I though “Oh I can just tinker with wpa-supplicant like on Raspbian.” ArchLinuxARM (or ALARM) has netctl, which takes care of most of that for you, but there are a couple of things that need to be done to get it to work right.

My initial though was “I need to hook this up with an Ethernet cable at the modem at home” or “Maybe if I screw with the setting on Windows, I can get these two devices working together?” The reality is that we can do this using WI-FI. In fact, there should be no reason you should be messing with a wired setting or messing with another computer’s internet settings just to make this happen. So toss out that Cat-5 cable you’ve been holding on to.

There’s also the fact that just about everything Raspberry Pi lately has been putting an emphasis on a Bonjour/Zeroconf set up. Avahi does this. Of which, that will be one of the packages we will install here.

“The girl was gone, and ‘Sombra’ was *re*-born”

Last time, I spoke about my Raspberry Pi 3B Rev 1.2 “Sombra” no longer functioning. The files were saved. The device she was on just won’t work.

This article will focus on “Sombra” Mk 2. Where as the old Sombra was Raspbian, new Sombra is ALARM. Mk 2 is a 32 GB drive, because I wanted something to test with. With the help of another Raspberry Pi “Topaz”, I was able to set up a new MicroSD card and complete the instructions from the previous article.

The first time I tried it, it didn’t work out so well. I had my 7" display trying out ALARM, and I also didn’t understand what was going on with the Wi-Fi the first time around, which mean after the second time I rebooted the system, the Wi-Fi didn’t want to run anymore. The issue appears to be DNS in nature as I’ve recently found myself either having to stop and start systemd-resovled or having to run wifi-menu after every restart. In rare instances, dhcpcd had to get involved. So as I said earler, I need to write an article on how to fix ALARM’s Wi-Fi issues. (Update: 7/30/19: It was a DNS issue. We’ll fix it later in this article.)

It is my hope that when “Sombra” Mk 3. is built, I can use the previous article and this article (and possibly a couple of others) to quickly build a Raspberry Pi system, or other ARM-based system without delay.

Everything is Root

No, Root!

Every step in this tutorial will require you to be logged in as root. ALARM doesn’t have sudo set up. I will address that in this article along with a few other things.

First some things you need to know:

  • root's default password is root.
  • alarm's default password is alarm.
  • You should change both passwords, this should be done using passwd. I’ll explain how to do that stuff later once the hostname is changed.
  • You should change your device’s hostname. The default is alarm.
  • You should also change alarm's username and group name.
  • NEVER change root's username or group name. Doing so will be really bad…like “breaking stuff” bad.

Just about all of this stuff except the first and the last items should be done before setting up Wi-Fi simply because it doesn’t require us to go online first. Again, we can’t set up sudo just yet. That will be the first thing that needs to be installed after we’ve set up Wi-Fi and updated our local packages.

Also, because we don’t have vim, emacs, or whatever text editor you prefer to use available, we will need to use nano to edit text files.

To save time on instructions, I will only post what file nano needs to update and the part of text that you must update. When yo are done making those changes use ^O (that is CTRL+O) to save the file, press ENTER to use the same file name (unless told otherwise) and use ^X (that is CTRL+X) to exit from nano.

First we want to use nano to open /boot/cmdline.txt.

# nano /boot/cmdline.txt

At the end of the line (which if your keyboard has a END command to jump to the end of the line), add audit=0. You may want to put a space before it. This will mute those audit messages that keep showing up. You can still read them by running the dmesg command, but most of these are just rudimentary messages that you’ll really not care about.

Next there is this batch of commands. If there are prompts with a specific command follow, answer their questions.

# echo "sombra" > /etc/hostname
# passwd
# passwd alarm
# usermod -l pi alarm
# usermod -d /home/pi -m pi
# groupmod -n pi alarm

Here’s what we just did.

  • We changed the hostname in the file /etc/hostname to sombra.
  • We changed root's password. Everytime you use passwd to change a password, you will be asked to type in a new password and then to confirm that by typing that password again.
  • We changed alarm's password. root can change the passwords of other users by typing the passwd command followed by the user’s name. The user MUST NOT be logged in to complete this action. If you logged in as alarm and then used su to become root, you may notice that when you type the who command that root and alarm are logged in. If you did it this way, log out with exit and log back in as root. Only root should appear in the who command output. You can also see who is logged in using the users command. It’s not uncommon if a user appears twice in a who, users, or w command, especially if they log in through a shell then start up the X Windows server.
  • We changed alarm's username to pi. Old habits die hard, I guess. On the plus side, this will help make doing whatever other Pi things on other distributions more uniform. You can change the username to something else, but if you do so, you MUST do these next two steps.
  • We changed alarm's home directory from /home/alarm to /home/pi. If you would like, create an soft link (alias) using ln -s /home/pi /home/alarm. I chose not to do that.
  • We changed alarm's group name from alarm to pi. Changing the name of this group will not change the group ID number, which is what we do not want to do. To see a list of groups that pi (nee alarm) is part of, type groups pi. If you don’t do this command, pi's groups will look like wheel alarm. By modifying the group name, groups pi should return wheel pi. To see root's groups, just type groups. This should just return root.

If you want to learn more about the various groups or user and group command, visit this page in the Arch Wiki.

We should confirm these changes with a reboot.

# reboot

Wi-Fi the First Time

As I previously stated, we aren’t directly using wpa_supplicant directly. ALARM uses netctl which is more profile-based. This means that if you want to connect to a new network, you need to create a new file everytime.

ALARM makes this easier by using a program called wifi-menu which creates profiles in a textual interface. Let’s get started on this step.

wifi-menu -o

You will then see a list of networks, select the one you want to connect to and press Enter.

You will then see a prompt that will auto generate the new profile starting with the Wi-Fi interface name (which is wlan0 but may be something different) a hyphen, and the network name. If you want to edit it, now is the time. Press Enter when ready.

You will then be asked to enter the passkey for the network. If your network requires one, type it in and press Enter. If there is none, leave the field blank and press Enter.

Your new profile will be stored in /etc/netctl. If you type systemctl --type=service, you may notice that there is a netctl service that is using that file.

netctl should automatically use the profile that is available. In fact, if you are using a laptop, you should definitely set up netctl to automatically use the wlan0 interface immediately upon the next reboot.

# systemctl enable netctl-auto@wlan0.service

This is so much better than having to worry about typos or manually having to change profiles. If by chance that does happen and you undo a mistake but the failed service still appears in systemctl, try using systemctl reset-failure to fix it. (You can check th elist of errors in the journal using journalctl -xe.)

Wi-Fi should be set up at this point. If there is something I forgot, let me know so I can append that here.

Fixing the DNS problem that won’t let you use the Internet at all.

It turns out I was right about it being a DNS issue, however, don’t go poking around in any of the network stuff. We just need to shut off DNSSEC.

I hear everybody say “DNS is important for security. You should use it.” That sounds good and very sage advice…unfortunately the ISPs (especially that one that has property in foreclosure but for some reason was allowed to buy a multibillion dollar media congolmorate because they bank at the Bank of Bizzaro World where you can tank your finances and the bank will still give your credit) don’t want you to use your own DNS, they want you to use their crappy DNS.

You’ll learn why in Part 3 when you install the bind-tools whether or not your ISP allows you to do to use a third-party DNS.

For now, we need to turn off DNSSEC.

About a week ago, I stumbled upon this solution which was posted on the Arch Linux Wiki.

The issue is that DNS won’t work in the default configuration. To fix this you need to do the following items:

  1. As adminstrator, open /etc/systemd/resolved.conf. (sudo nano /etc/systemd/resolved.conf)
  2. On the line following [RESOLVED] add a line that says DNSSEC=false. You should preserve any commended lines in the file espeically if a new solution comes along.
  3. Save the file and quit the editor. (In nano it shold be ^O then Enter then ^X.)

These changes should take effect upon the next restart.

Pacman Fever

Just before we install sudo, we need to make sure the software that is currently installed is up to date. To do this, we need to use Arch Linux’s package manager pacman, no relation to a certain dot-eating muncher.

Somebody at Arch Linux was cool enough to create a “Rosetta” page on the Arch Linux Wiki to help people not familiar with pacman's command. Basically, if you know how to use apt from Ubuntu or dnf from Fedora, using pacman should be easy.

# pacman-key --init
# pacman-key --populate archlinuxarm
# pacman -Syu
:: Proceed with installation? [Y/n] y

So what did we just do?

  • The two pacman-key command set up pacman's list of trusted keys. The first one initialized the required accces while the secon one reloaded the default keys provided by ALARM. These keys should be located in /usr/share/pacman/keyrings.
  • The pacman command ordered an update of sources and upgrade of packages. By pressing Y for “yes”, the packages are installed.

There’s a lot of stuff that we will need to install and configure. We’ll get to that stuff when we get there.

Sudo Make Me Do Admin Stuff

The most important package that you will need to install is sudo. Why the ALARM guys didn’t include such an important package is baffling. We will first need to use pacman to install the package, but then we need to do a couple of other things.

# pacman -Ss sudo
# pacman -Si sudo
# pacman -S sudo
# sudo -ll
# sudo -lU
# EDITOR=nano visudo

The above list is not quite complete, but here’s whats going on.

  • pacman -Ss sudo allows us to look for packages. In this case it is the sudo package.
  • pacman -Si sudo allows for us to learn more about a specific package. This command will show us what is in the sudo package as well as any dependencies, conflicts, as well as any groups it belongs to. In some packages, it will provide a website for us to find more information.
  • pacman -S sudo, with no letters following the capital S orders an install of the sudo package as well as any dependencies. During this process, you may see suggestions for installing other packages. You can install those if you want, but I’ll actually provide a list later.
  • sudo -ll shows us what root is allowed to do, which should be everything.
  • sudo -lU pi shows us what pi (nee alarm) may do. Which is nothing until we run this next command.
  • EDITOR=nano visudo opens a copy of /etc/sudoers called /etc/sudoers.tmp. As the begining of visudo implies, this is supposed to be opened with vi, but because we don’t have vi, we must tell this to open /etc/sudoers.tmp using nano. Prepeding this command with EDITOR=nano tells visudo to open /etc/sudoers.tmp in nano.

Using nano we must now edit /etc/sudoers.tmp and SAVE IT AS /etc/sudoers (WITHOUT .tmp!). Remember that when you type in the ^O command! If nano asks if you want to overwrite it, press Enter to say yes. To uncomment, you just remove the leading octothorpe (#) and space at the beginning of the line. Now look for these two items:

  • # %wheel ALL=(ALL) ALL
  • # %wheel ALL=(ALL) NOPASSWD: ALL

One you’ve uncommented those lines, save it as the file name I mentioned and exit from nano.

What this does is it allows pi, as well as any one else who is a member of the wheel group to execute administrative commands with sudo. The second command should allow wheel members to do so without a password.

These changes will take place at the next restart.

Update (7/30/19): I think I may have missed something because for some reason I still need to invoke sudo if I want to use ping. If anyone knows how to fix that, I would be much obliged.

Here seems like a good stopping point.

When you are ready, proceed to part 3.

--

--