Tags
So following on from Part 1 of this series, over a number of evenings, I had a stable base installation of GNU/Arch Linux… It required diligently reading and following the Beginners Guide on the Arch Linux wiki.
On my modest test laptop (HP mini with Intel Atom processor and 1GB of RAM) I had a bash interface via which I could login (as root).
The purpose of the post is to document the next steps I followed, using the General Recommendations article on the wiki (other sources are mentioned also, applicable to each step):
1. Created a User Account
After achieving a stable base installation using the root account, this was the first thing I saw too next…
Using root for prolonged periods is a big no-no. It’s an administrative account and it’s possible to trash your system quite easily through issuing (mis)appropriate commands.
I followed step 6 in this article, to setup the new account, as summarised below:
- Created a new user like this example from the article: useradd -m -g users -G wheel,storage,power -s /bin/bash johndoe
- Then created a password for the user like this: passwd johndoe
- Installed the sudo (“Super-User-Do”) package – this program allows users to execute commands with temporary admin type privileges. I used Arch’s pacman (“package manager”) utility to automatically download and install this package from the Arch package repository, which I thought was really neat (so need to hunt around on the internet: download instead from a central place and install, using one command. I read somewhere that Windows 10 will have a similar feature!). pacman -S sudo
- To allow my new user account to run sudo, I edited my sudoers file using the nano text editor: nano visudo
- Then uncommented this line (just like the article says): %wheel ALL=(ALL) ALL
- Editing the file in this way ensures that all members of the wheel group (to which the new user belongs) are able to execute sudo
I then logged off as root and logged in instead using my newly created user account (phew).
2. Installed a Desktop Environment
Using this excellent article again, I followed step 8 to install and setup a working GUI desktop environment… Before doing this, I was using purely bash as an interface.
Things are a bit different in Linux, compared to Windows. The desktop environment is a separate component/module entirely from the OS and I think of it as a “graphical” wrapper that interacts with the shell. And of course I immediately think “wrapper” equates with a performance hit. So wanting something “lightweight” (mimimal memory and CPU footprint) I decided to try XFCE.
Here’s a summary of the steps I took next (following along with the article mentioned above):
- Installed sound: sudo pacman -S alsa-utils (note that since I’m using my new user account which doesn’t belong to the admin group, I have to use the sudo program to execute this command now).
- Installed graphics driver: I followed this article here and installed the generic video driver using command: pacman -S xf86-video-vesa
- Installed the X windows system: sudo pacman -S xorg-server xorg-xinit xorg-server-utils (to install base packages) then sudo pacman -S xorg-twm xorg-xclock xterm. I now had a basic desktop environment that I could start by typing startx.
- Installed some fonts: sudo pacman -S ttf-dejavu
- I then ran the following to install everything required for the XFCE desktop environment to run: sudo pacman -S xfce4 xfce4-goodies gamin ttf-liberation xorg-server dbus slim
- Note that the previous command installs SLiM (for “Simple Login Manager”) – this will provide a simple graphical login screen.
- When the installation completed, I enabled the SLiM service in systemd: systemctl enable slim.service.
- I rebooted my laptop and was presented with a nice graphical front end for entering my username and password :-).
- I could start the XFCE desktop environment by executing: exec startxfce4. A nice GUI desktop environment loaded!
- I created a .xinitrc file manually in my home directory and added this single line: exec startxfce4. This resulted in XFCE loading automatically after login, saving having to start the desktop manually each time.
- For some reason, my script “skeleton” directory (“/etc/skel/.xinitrc”) was empty – it didn’t contain any files. Why’s that?!!
Everything was well but the desktop was incredibly laggy. I came to the conclusion that this had to be due to my graphics driver, since the generic driver doesn’t have 2D or 3D acceleration. I ran this command to find out the video chipset on my laptop: lspci | grep VGA (Intel) and followed the instructions on the Arch wiki to install the appropriate propriety drivers.
After doing this, it was with great relieve to find that the desktop was much more responsive with no lag.
3. Installed Wireless Drivers
I still had problems with my wireless connectivity due to missing drivers. The drivers I needed were available in the AUR (Arch User Repository).
The actual error was: ERROR: Firmware file “b43/ucode15.fw” not found
Which, in plain English means something like: “missing drivers for the device b43, where this is the unicode version 1.5”.
I would need to download a PKGBUILD script and then use makepkg to create binaries that could be installed using pacman. This was different from previous installations I had carried out so far: instead of the binaries being available with the base installation, meaning I could just run pacman straight away, this time I would need to create the binaries myself first using the makepkg utility (trusting that the PKGBUILD script was correct) and then run pacman to install the binaries.
If I understand the documentation correctly, users vote if binaries should be included in the base installation: enough votes means that the binaries are added (promoted from the AUR), which makes installation convenient (and safer). It’s seems strange that such a binary is not already part of the base installation! Why not?
I followed the instructions here on the Arch wiki; the first step involved downloading and installing the necessary package so I could actually build packages downloaded from the AUR: sudo pacman -S –needed base-devel
Next I downloaded the PKGBUILD tarball here.
Extracting the file, I used makepkg to create the binaries required and then installed them using pacman – no drama. It would be quite frustrating though if the PKGBUILD contained errors and failed… I guess the best bet would be to contact the author of the script and ask them for help.
Sometime soon I guess I will have to create PKGBUILDs for my own projects I have in mind!!
After installing the driver, I rebooted and, at last, there was no sign of the error for the first time, when starting up.
I then followed these steps on the Arch wiki to carry out some configuration and was then able to connect to my home wireless network. Later on, I installed a GUI network manager called wicd following these instructions; this now runs in my system notification tray.
4. Applications Installation
I went on to install a few packages e.g. Keepass, Chrome, Dropbox (from the AUR – looks like a recent move by Dropbox into supporting Linux clients).
I used Evernote quite a bit of note taking but it doesn’t look like a client exists for Linux…
5. Closing Thoughts
It’s been a fun and interesting exercise to install Arch. Time consuming. Not too frustrating – the wiki contains clear and concise instructions.
So far I’m very pleased with the system and I’m going to switch my everyday laptop to Arch over the next few days… Goodbye Windows.
Some of my concerns are:
- How am I going to (manually) keep Arch up to date? I’m thinking of creating a shell script to do this that I run every week say, to download and update my system. Do other people do this or something else?? I would still rather do all this myself and have full control: I find Windows intrusive in this regard (auto and manual update setting).
- Connecting to my work VPN – this could be interesting :-).
- No compatible Microsoft Azure SDK? Not sure how this is all going to work yet (probably the hard way as usual :-)).