Category Archives: linux

Resolving a Linux hang-on-boot Situation

For several distributions of Linux, including Fedora, Arch, and a couple others (all of which happen to use systemd — hmm…) I would consistently have problems booting. During the startup process, when all of the services are being started, it would always hang at the exact same point: right after the “Started udev device kernel manager” line. This prevented me from even attempting to install any of these distributions. I did notice that any distro that did not default to systemd (namely Ubuntu and Gentoo) installed with no issues.

I finally found a fix to this: blacklist the dw_dmac module in the kernel. In Arch at least, this is done at boot time by adding the following line to the kernel boot line in Grub:

modprobe.blacklist=dw_dmac

Once I hit enter, it booted up without issue, and installation went flawlessly. Rather than keep this line in my grub kernel line, I’ll blacklist it permanently the proper way, but for now, this works.

Mounting LVM Volumes in Linux with Rescue/Live Disk

So lately I’ve been playing around with a single remote-mounted nfs home directory at home. I’ve used it at work for years, and it’s great having all of my stuff in one location no matter what system I’m logged into. The setup was quite straightforward, except I’m still troubleshooting why my system hangs shortly after I login. I even made sure to include the _netdev option in my fstab so that it wouldn’t get mounted until after the network/nfs services are started, but it’s still causing me an issue. Anyway, the temporary solution is one I use rarely enough that I wanted to document it here… mounting an LVM volume manually when LVM isn’t already started. This is because I booted from the Fedora 20 Live disk in order to edit my fstab so I could login.

Here’s what I had to do in order to get my root partition to mount:

vgscan         # you may have to run 'lvm vgscan', but the former worked for me
vgchange -ay   # again you may have to run 'lvm vgchange -ay'
mount /dev/rootdg/root /mnt   # your volume group and volume name may differ
vi /mnt/etc/fstab

Be sure to get the one in /mnt, not in /etc, because that’s  your Live Install fstab and it won’t persist nor have anything useful in it.

Once I’ve made my changes, I reboot. Viola, you’re saved!

Using VI Inside of Emacs with ansi-term

As I’m still in the transition to use Emacs more often, I find myself often wanting to do a quick-and-dirty edit in vi. Rather than open another terminal (which can be disruptive if I have a tiling window manager with a particular layout configured), I like to have an ansi-term shell open in another Emacs frame. I usually use C-x 2 to split the window vertically, then C-x o to switch to the second frame, and M-x ansi-term RET to start an ansi-term shell. It will prompt for the shell to use, defaulting to the current shell of that user, in my case it will be /bin/bash or /bin/zsh depending on which system I’m using.

One great thing about ansi-term is that aside from the control/meta keystrokes, it’s a true ANSI-compliant terminal shell. You can still use C-x C-f and other key sequences (which in that case will open a new file in a new buffer) but you can also use C-c to cancel the current command, interrupt the running process, etc., except you have to hit it twice to tell ansi-term that you wanted to pass that control-c into the shell, not for Emacs itself to process. One of the only differences I’ve found, and it suits my needs just fine.

Now, for the quick-and-dirty edits — using vi or vim works perfectly fine within the Emacs ansi-term. The only issue I’ve found is that if I’m inside the file long enough, I often forget that I’m in VI and I will try to save the file with C-x C-s, and VI doesn’t really like that very much. Another thing of note — often I’m sudo’ed to root in the ansi-term window for various reasons, and vi’ing a file then will edit it as root, but using C-x C-f to open the file inside a new Emacs buffer will open it as the user ID that initiated the Emacs client (as I run Emacs in daemon mode almost exclusively), so I won’t have permissions to edit system files natively. I could use tramp/sudo, but sometimes it’s just faster to edit with VI. I’ve found this handy for multiple occasions so far.

One thing to note — using VI inside another Emacs shell (shell, term, iterm) can have strange results when attempting to save, enter/exit command mode, etc., so use at your own risk!

Using Full Screen Applications with Synergy in Windows

I’ve been a big fan of the Synergy Project for quite some time. I use it for my main desktop (dual boot Windows 7 and Linux) and another Linux system that I use for IRC, Crashplan Backup, and a few other household apps.

One of the things I struggled with for literally years is when I’m running a fullscreen program in Windows, and unless I’ve disabled Synergy, if I move my mouse too far to the right, my fullscreen program will minimize to the task bar. Sometimes this is a big deal to me (mainly multiplayer gaming). I tried Googling for how to disable Synergy for use with fullscreen programs because certain ways I stop it (stopping the service, killing the process) sometimes causes Synergy to never start again correctly, and I wanted to see if there was a best practice. What I found was even better: an option within Synergy that will allow me to use the Synergy functionality (ie switching to my Linux machine to the right) without minimizing my fullscreen program. That option is called:

“Don’t take foreground window on Windows servers”

Once I selected this option, I loaded up one of my favorite fullscreen games, Spelunky, and tried to move the cursor to the right to get to my Linux IRC window, and viola! The foreground stayed there while I was able to type into a Linux terminal. Once I moved the mouse back into the Windows screen, I could again play the game.

The only thing left to test is for first-person games where you use the mouse to look around. I suspect the turning to the right will be affected, but we’ll see about that!

Thanks to the people over at Next of Windows for the link!

 

Managing Linux Screen Resolutions with xrandr

I’m making much more of an effort lately to spend more time at home in Linux. I still have a Windows 7 drive because of gaming and some photography related applications I use, but aside from that, there’s no reason why I can’t “come home” to my Linux installation.

One issue I always seem to have is the fact that my two monitor setup includes one widescreen monitor (1920×1080) and one non-widescreen monitor (1280×1024), so one resolution never cuts it. Most of the modern Linux distributions can handle this with either the proprietary video drivers (like Nvidia), but with the various built-in drivers, it seems to be a roll of the dice as to whether or not the resolutions will work. I should also mention that I use the Qtile Window Manager because I like tiling managers, plus this one is written in Python, a language I’m trying to gain a lot of experience with. Anyway, Qtile has a very simplistic design, and that design excludes the normal “Menu” bar that has Applications, Settings, etc., which also forces me to learn more how to do things manually via the command line (another perk). This time, it’s adjusting my resolution.

When I first set up qtile, the monitors were in the wrong order — the left monitor was displayed as the right, and vice versa, so I’d have to move the mouse in the opposite direction to get the cursor to the other screen. Normally this isn’t an issue, I’d open the Gnome settings and switch them, but this time I got an error (perhaps due to my window manager and that I didn’t install Gnome, just pieces of it) so I had to find an alternate method. Enter xrandr. It was relatively quick to Google the correct command to switch my displays:

#This shows the current configuration as seen by xrandr:
xrandr --current

This showed me the following (unimportant content truncated):

DVI-I-1 connected primary 1920x1080+1280+0
DVI-I-2 connected 1280x1024+0+0

So  now I knew the tags for each of my monitors — the widescreen was DVI-I-1, and the other was DVI-I-2.

A glance at the usage (xrandr –help) showed me that there are some very intuitive parameters that can be passed, namely –right-of and –left-of. The following command switched my monitors as I desired:

xrandr --output DVI-I-1 --right-of DVI-I-2

So I added that to /etc/profile and restarted X to test (Control-Alt-Backspace) and it worked like a charm. There was one hitch though. Both monitors were using the resolution of the smaller one, and my 1920×1080 monitor was stretched and looked awful. Enter xrandr again. Making one minor edit to this command fixed me up for good!

xrandr --output DVI-I-1 --right-of DVI-I-2 --mode 1920x1080

So restarting X again showed me exactly what I was hoping for — proper resolution for each monitor. Chalk up another victory for Linux command line!

 

 

Who uses Caps Lock anymore? More Control!

When I started using emacs again some time ago, I noticed quickly that it was very uncomfortable to move my little finger down to the left control key in order to do the many emacs control sequences. I wanted something much easier to use, or else emacs likely wouldn’t last. I recalled a while back remapping my caps lock key to another control key, so I looked into it. Not only is this good in Linux, but I was able to do it in Windows 7 as well, with a registry entry.

Here is a link to my github page with the required Windows registry update. Note that this has been tested on Windows 7 only. If you try it out with other versions, let me know if it works so I can update the post!

For Linux, three lines added to ~/.bash_profile or ~/.bashrc would do the trick:

xmodmap -e 'keycode 66 = Control_L'
xmodmap -e 'clear Lock'
xmodmap -e 'add Control = Control_L’

Once that file was sourced or you relog, it takes effect and you have a much more comfortable control key on your hands!

Update 10/15/2014:

You can also achieve the same results with a single command:

setxkbmap -option ctrl:nocaps

This of course uses a different command, so you have another option if you prefer to not use xmodmap, or if it’s not available for some reason.

Laptop ACPI Issues

So recently I installed Ubuntu 14.04 LTS on a laptop. This laptop is new enough to use UEFI boot, however I was able to disable that in the BIOS. I read many people had issues getting Linux in general to work with UEFI, so I was fine with using the legacy system.

One issue that I did have was that on shutdown, Ubuntu was hanging. I’d have to manually power it off, and that was not something I was comfortable doing. First thing I did, edit /etc/default/grub and change

GRUB_CMDLINE_LINUX_DEFAULT="splash"

to

GRUB_CMDLINE_LINUX_DEFAULT="nosplash"

On the line “GRUB_CMDLINE_LINUX_DEFAULT”. This way I could see what was happening and wouldn’t get a blank screen while the system was shutting down all of it’s services. I ended up seeing the following message:

* Will now restart

So that tells me that the process responsible for sending the power cycle message to the hardware (ACPI) was not functioning, although the operating system was ready for the poweroff/reboot to occur.

The easy fix: editing the above file again, and now it looks like this:

GRUB_CMDLINE_LINUX_DEFAULT="nosplash acpi=off"

Now I can safely boot, reboot, and shutdown the system without the operation hanging. I lose some ability to control the system power, but since that mainly includes system hibernation or suspend, I’m fine with it. I never use those functions anyway, and disable them shortly after the initial operating system load.

Enjoy!

Errors with gpg –gen-key over SSH

This issue plagued me for some time… I was attempting to create a gpg key, add it to my keychain, and then gpg encrypt a netrc file to use in Emacs. It kept failing just before it would create the actual key, and was giving strange X-related errors. I should note that the “over SSH” part of this title means that I was connected via ssh on the server I was attempting to create the gpg key on.

One of the many error messages was that I did not have the “pinentry” package installed, but I verified multiple times that it was there, and even reinstalled it several times.It finally dawned on me that the reason it was looking for pinentry-gtk or pinentry-qt (both X-windows libraries) was that it thought I was locally logged into that server, and could see the desktop. This made me realize that it was trying to display the graphical interface for the passphrase, which could not be displayed because I was connecting via ssh. A quick echo $DISPLAY showed me that my ssh was attempting to forward the X connection to my local host, however the DISPLAY was not working because my local system did not have those packages installed. Once I issued unset DISPLAY my key was able to generate just fine, because it used the non-X version of the routine that asked me for my passphrase.

Another seemingly difficult problem solved by thinking things through!

VirtualBox 4.3.14 and Antivirus Programs

This evening I wanted to delve into some different distributions of Linux that I’ve never really given much time. The first one that came to mine was Gentoo. I’ve read that “If you use any Linux distro, you learn that distro, but if you use Gentoo, you learn Linux.”  It’s quite a bold statement, and quite frankly I wanted to see for myself. Another popular one I heard great things about is Arch. I wanted to give both of them a try tonight.

I downloaded the most recent basic images of both, and realized that since my latest PC reload, I never reinstalled VirtualBox — an important tool for testing out various operating systems. It seems foolish to destroy a working system to test something out that you may absolutely hate, so VirtualBox has always been my first step in trying a new one. The latest version of VirtualBox as of this post is 4.3.14. I installed it, rebooted just in case (since it adds a network device and likely loads some kernel modules), and attached my Gentoo ISO to the virtual cdrom, and clicked ‘Start’. This was the lovely message I received: (Note, this is from my Arch attempt, but the message was the same)

VirtualBox Error

Having never seen this before for any thing, I quickly hit Google, only to find a few others have had this in the past, and nobody was quite sure what the fix was. Some were searching and deleting Windows registry keys (which I had none that matched), and various other things. Wanting to quickly see if it was the ISO or my VirtualBox installation, I tried Arch, and got the same message.

I did a bit more searching, and found that people were having moderate success in removing their “Avast” anti-virus, so I thought I’d give that a try. Rather than remove it, my AVG installation has an option to “Temporarily Disable AVG Protection”. I checked the “10 minutes” option, and viola! The ISO booted just fine. Once it was running, I’m sure the 10 minutes expired, and the guest is still up and running, but I suspect any time I want to boot this (until the bug in VirtualBox is resolved) I’ll need to temporarily turn off the anti-virus.

Duo Security on WordPress and Linux

Some time ago I created a free Duo Security account to help protect my VPS. It was relatively simple to configure pam in Linux to use the Duo two factor authentication, so now anytime anyone successfully authenticates with a valid username and password, I get a notification on my phone (both Android and iOS versions available) asking me to confirm or reject the logon. While this seems like a hassle, after looking at the ssh denies (the thousands that I get per day) I felt much more relaxed about the security of my VPS.

Shortly after configuring it on Linux, I also realized there is a WordPress plugin, so now anytime anyone logs into my WordPress account successfully, I get one of the notifications. Since my phone is always nearby, it hasn’t proven to be cumbersome in any way yet. In fact, knowing that even if my WordPress account is hacked and the offenders manage to successfully capture my username and password (don’t use the default username!) they still will not likely to be able to get in. No system is foolproof, but this certainly is a grand step past just password authentication.

If you’re not familiar with two factor authentication, Wikipedia has a writeup (granted not a fantastic one) that should explain the basics.

When the famous heardbleed and OpenSSL vulnerabilities were made public, Duo released updates almost immediately. Great customer service for a great product.