Change default runlevel (target) on Fedora

I’m running on Fedora 20, and the graphical boot (Plymouth-something-something) sometimes waits a long time and then times out, which when it happens makes the computer take several minutes to boot. This doesn’t happen if I boot to “runlevel 3” (now called multi-user.target) and then run startx from there.

You can change the default target to “runlevel 3” like this:
systemctl set-default multi-user.target

The Magic SysRq key

Have you ever wondered of what use the SysRq key is?

While working on my dual monitor setup, I tried several paths that led to an unresponsive X session (black screen).  Ctrl+Alt+[1-6] didn’t work; Ctrl+Alt+Backspace didn’t work; so I did a hard reboot (and after unplugging a monitor so that I could get back into X, I set my default runlevel to 3 in /etc/inittab till I could figure out what was going on!)

While researching, I stumbled upon a post in a forum for Ubuntu users where someone suggested holding down Alt+SysRq and typing S, U, B (sync all mounted filesystems, remount filesystems readonly, reboot).  Next time I had X in an unresponsive state, I tried it.  What do you know, it worked!

Turns out it’s the Magic SysRq Key feature of the Linux kernel.

I don’t think my wife would appreciate the beauty of this magic key combination (she remains unconvinced about the amazing utility of Ctrl+Shift+Alt+PgDn for shutting down the computer from an X session without prompts :) , but for a keyboard shortcut connoisseur like me it was a fun find.

Dual monitors in Mandriva

There’s a lot of context to keep in my head when I do my C++ work. I wanted to be able to be productive when I work from home, and decided on a two-monitor setup toward that end.

I bought an NVidia GeForce 9500 GT dual DVI output board by EVGA (512MB DDR2, PCI Express 2.0, SLI Support, (Dual Link) Dual DVI), an Acer X233H LCD monitor capable of 1920×1080 resolution, and an eMachines E202Hwmd LCD monitor capable of 1600×900 resolution.

First Try

After installing the new card, I hooked up both monitors to the DVI outputs and fired up Mandriva 2009.1.  It booted, but when X started the first screen went black (I think the other one never powered on).

The Ril Dil

Unplugging the video cable for the second monitor enabled me to reboot and get back into X.  I tried some things to use the open source “nv” driver and I think it would work, but after working with it for a while I decided to try the (proprietary) nvidia driver.  To do this, I ran Mandriva Control Panel, went into “Set up the graphical server”, and chose “GeForce 6100 and later”.  When MCC alerted that a proprietary driver was available, I selected it.  In the options, I chose to “Enable duplicate display on the second display”.

Now, as root, I ran the nvidia-settings program and set up the displays:

Here is the xorg.conf file that nvidia-settings generated for me:


# nvidia-settings: X configuration file generated by nvidia-settings
# nvidia-settings:  version 1.0  (mandrake@n2.mandriva.com)  Sun Oct 18 07:57:16 EDT 2009

# File generated by XFdrake (rev )
# **********************************************************************
# Refer to the xorg.conf man page for details about the format of
# this file.
# **********************************************************************

Section "ServerLayout"

Identifier     "layout1"
 Screen      0  "Screen0" 0 0
 InputDevice    "Keyboard0" "CoreKeyboard"
 InputDevice    "Mouse0" "CorePointer"
EndSection

Section "Module"
 Load           "dbe" # Double-Buffering Extension
 Load           "v4l" # Video for Linux
 Load           "extmod"
 Load           "glx" # 3D layer
 Disable        "dri"
EndSection

Section "ServerFlags"
 # allows the server to start up even if the mouse does not work
 #DontZoom # disable <Ctrl><Alt><KP_+>/<KP_-> (resolution switching)
 Option         "DontZap" "False" # disable <Ctrl><Alt><BS> (server abort)
 Option         "allowmouseopenfail"
 Option         "Xinerama" "0"
EndSection

Section "InputDevice"
 # generated from data in "/etc/sysconfig/keyboard"
 Identifier     "Keyboard0"
 Driver         "kbd"
 Option         "XkbLayout" "us"
 Option         "XkbModel" "pc105"
EndSection

Section "InputDevice"
 # generated from default
 Identifier     "Mouse0"
 Driver         "mouse"
 Option         "Protocol" "auto"
 Option         "Device" "/dev/psaux"
 Option         "Emulate3Buttons" "no"
 Option         "ZAxisMapping" "4 5"
EndSection

Section "Monitor"

 # Monitor preferred modeline (60.0 Hz vsync, 67.5 kHz hsync, ratio 16/9, 95 dpi)
 Identifier     "monitor1"
 VendorName     "Plug'n Play"
 ModelName      "Acer X233H"
 HorizSync       30.0 - 94.0
 VertRefresh     49.0 - 75.0
 ModeLine       "1920x1080" 148.5 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
 ModeLine       "768x576" 50.00 768 832 846 1000 576 590 595 630
 ModeLine       "768x576" 63.07 768 800 960 1024 576 578 590 616
 ModeLine       "1920x1080_120" 368.76 1920 2072 2288 2656 1080 1081 1084 1157 -hsync +vsync
 ModeLine       "1920x1080_100" 302.02 1920 2072 2280 2640 1080 1081 1084 1144 -hsync +vsync
 ModeLine       "1920x1080_85" 252.93 1920 2064 2272 2624 1080 1081 1084 1134 -hsync +vsync
 ModeLine       "1920x1080_75" 220.64 1920 2056 2264 2608 1080 1081 1084 1128 -hsync +vsync
 ModeLine       "1920x1080_60" 172.80 1920 2040 2248 2576 1080 1081 1084 1118 -hsync +vsync
 ModeLine       "1920x1080_50" 141.45 1920 2032 2232 2544 1080 1081 1084 1112 -hsync +vsync
 ModeLine       "1600x900_120" 255.69 1600 1728 1904 2208 900 901 904 965 -hsync +vsync
 ModeLine       "1600x900_100" 208.90 1600 1720 1896 2192 900 901 904 953 -hsync +vsync
 ModeLine       "1600x900_85" 174.79 1600 1712 1888 2176 900 901 904 945 -hsync +vsync
 ModeLine       "1600x900_75" 152.28 1600 1704 1880 2160 900 901 904 940 -hsync +vsync
 ModeLine       "1600x900_60" 119.00 1600 1696 1864 2128 900 901 904 932 -hsync +vsync
 ModeLine       "1600x900_50" 97.04 1600 1680 1848 2096 900 901 904 926 -hsync +vsync
 ModeLine       "1368x768_120" 185.67 1368 1472 1624 1880 768 769 772 823 -hsync +vsync
 ModeLine       "1368x768_100" 151.73 1368 1464 1616 1864 768 769 772 814 -hsync +vsync
 ModeLine       "1368x768_85" 125.67 1368 1456 1600 1832 768 769 772 807 -hsync +vsync
 ModeLine       "1368x768_75" 110.19 1368 1456 1600 1832 768 769 772 802 -hsync +vsync
 ModeLine       "1368x768_60" 85.86 1368 1440 1584 1800 768 769 772 795 -hsync +vsync
 ModeLine       "1368x768_50" 69.92 1368 1424 1568 1768 768 769 772 791 -hsync +vsync
 ModeLine       "1360x765_120" 182.63 1360 1456 1608 1856 765 766 769 820 -hsync +vsync
 ModeLine       "1360x765_100" 149.22 1360 1456 1600 1840 765 766 769 811 -hsync +vsync
 ModeLine       "1360x765_85" 124.65 1360 1448 1592 1824 765 766 769 804 -hsync +vsync
 ModeLine       "1360x765_75" 108.34 1360 1440 1584 1808 765 766 769 799 -hsync +vsync
 ModeLine       "1360x765_60" 84.40 1360 1424 1568 1776 765 766 769 792 -hsync +vsync
 ModeLine       "1360x765_50" 69.34 1360 1416 1560 1760 765 766 769 788 -hsync +vsync
 ModeLine       "1280x720_120" 161.56 1280 1376 1512 1744 720 721 724 772 -hsync +vsync
 ModeLine       "1280x720_100" 131.85 1280 1368 1504 1728 720 721 724 763 -hsync +vsync
 ModeLine       "1280x720_85" 110.01 1280 1360 1496 1712 720 721 724 756 -hsync +vsync
 ModeLine       "1280x720_75" 95.65 1280 1352 1488 1696 720 721 724 752 -hsync +vsync
 ModeLine       "1280x720_60" 74.48 1280 1336 1472 1664 720 721 724 746 -hsync +vsync
 ModeLine       "1280x720_50" 60.47 1280 1328 1456 1632 720 721 724 741 -hsync +vsync
EndSection

Section "Monitor"
 Identifier     "Monitor0"
 VendorName     "Unknown"
 ModelName      "Acer X233H"
 HorizSync       30.0 - 94.0
 VertRefresh     49.0 - 75.0
EndSection

Section "Device"
 Identifier     "device1"
 Driver         "nvidia"
 VendorName     "nVidia Corporation"
 BoardName      "NVIDIA GeForce 6100 and later"
 Option         "DPMS"
 Option         "TwinViewOrientation" "Clone"
 Option         "TwinView"
 Option         "AddARGBGLXVisuals"
EndSection

Section "Device"
 Identifier     "Device0"
 Driver         "nvidia"
 VendorName     "NVIDIA Corporation"
 BoardName      "GeForce 9500 GT"
EndSection

Section "Screen"
 Identifier     "screen1"
 Device         "device1"
 Monitor        "monitor1"
 DefaultDepth    24
 SubSection     "Display"
 Depth       8
 Modes      "1920x1080" "1600x900" "1366x768" "1360x765" "1280x720"
 EndSubSection
 SubSection     "Display"
 Depth       15
 Modes      "1920x1080" "1600x900" "1366x768" "1360x765" "1280x720"
 EndSubSection
 SubSection     "Display"
 Depth       16
 Modes      "1920x1080" "1600x900" "1366x768" "1360x765" "1280x720"
 EndSubSection
 SubSection     "Display"
 Depth       24
 Modes      "1920x1080" "1600x900" "1366x768" "1360x765" "1280x720"
 EndSubSection
EndSection

Section "Screen"
 Identifier     "Screen0"
 Device         "Device0"
 Monitor        "Monitor0"
 DefaultDepth    24
 Option         "TwinView" "1"
 Option         "TwinViewXineramaInfoOrder" "DFP-1"
 Option         "metamodes" "DFP-0: 1920x1080 +1600+0, DFP-1: nvidia-auto-select +0+0; DFP-0: NULL, DFP-1: 1600x900 +0+0; DFP-0: NULL, DFP-1: 1280x720 +0+0"
 SubSection     "Display"
 Depth       24
 EndSubSection
EndSection

Before X initializes, only one monitor is active (the one plugged in to DVI-0, I think).  I plugged the Acer monitor into DVI-0 so if for some reason I’m not booting X I get the larger monitor; but in nvidia-settings I picked the eMachines monitor as my primary monitor so that the KDE taskbar is over on that monitor, leaving the Acer monitor fully free for an rdesktop session.

Remote X11

I have a main Linux box running Mandriva 2009.1, and I wanted to set up Linux on a second computer in such a way that I could be sitting at the second computer running programs off of the main computer — kind of like remote desktop, only this would be program by program instead of the whole desktop.

I had seen that magic work before (you just ssh to the other computer and run the command, and it shows up in your local display — I think there’s some kind of forwarding going on); but this time I wanted to add a second kind of magic: I wanted the secure shell session to happen without having to drop to a shell and type a password interactively.

I had seen both kinds of magic working before, just not simultaneously.

Magic A

The magic of running a ssh session without having to interactively type a password is explained on the ssh man page.  It involves the following steps:

  1. On the second computer, I ran ssh-keygen (with no master password, for now anyway).  This created (among other things) a ~/.ssh/id_rsa.pub file
  2. I copied the contents of the id_rsa.pub file to my home folder on the main computer in a new file called ~/.ssh/authorized_keys .
  3. I set the file permissions on the authorized_keys file so that only my user had any permissions (otherwise ssh ignored the file and prompted interactively for a password anyway!)

Now I could ssh from the second computer to the main computer without typing a password.  The stage was set for Magic B:

Magic B

Now on the second computer I made shortcuts for Firefox and Thunderbird on the main computer.  The commands in the shortcuts were:

ssh -f maincomputer mozilla-firefox

ssh -f maincomputer mozilla-thunderbird

Now when I click on those shortcuts, the programs run on the main computer but are displayed on the second computer, only slightly slower than on the main computer (maybe I’ll upgrade to a Gigabit internal network sometime).  Nice!

Linux window-specific behavior

When launching an rdesktop session from my Linux box, I wanted it launch fullscreen.  I’ll tell how I did it at first and then give a simpler solution.  [Note: I wrote most of this in April and May when I was running Mandriva 2009.0, but I didn’t write down exactly how I’d gotten to things, and now that I’m running 2009.1 the path to get to things is slightly different.  I’ve updated the post to speak in terms of the 2009.1/KDE 4.2 ways of getting to these settings.]

How I Did It At First: No Border

Whenever I ran rdesktop I would then need to go to the window’s system menu to some Advanced submenu and choose the No Border setting.

An Improvement: Saving Window-Specific Settings

At some point I finally got tired of doing this every time I ran rdesktop and wished for a way to make my change stick so I didn’t have to do it every time.  Well, in KDE (I’m not sure about other window managers) there are “Window-specific settings” you can save.  So again on the window’s system menu, I chose Configure Window Behavior -> Window Specific and clicked Modify.  That took me to this configuration dialog:

preferences-no-border

I set No Border to Remember.  Now when I launched rdesktop I could go to the system menu and choose Advanced -> No Border and the next time it remembered this setting and automatically launched borderless.  Nice!

Except… sometimes I wished to de-borderlessify the window, and I couldn’t figure out how (though I did find I could hold down Alt and use the mouse to drag the borderless rdesktop session to a corner of the screen!).  It seems that borders are sometimes difficult to re-erect once you’ve taken them down…

A Simpler Solution: Toggle Fullscreen Mode

There may be some hotkey that lets me get the system menu back after choosing No Border*, but I found a solution that fits my needs better: simply toggling rdesktop fullscreen mode using Ctrl+Alt+Enter.  That way I can usually run in fullscreen mode but quickly have a normal window again when needed.

*(Actually, Alt+F3 normally brings up the system menu even if you have No Border, but rdesktop is different because it intercepts such key sequences.  That’s why I had to go the circuitous route.)

Clearing window-specific behavior

Great, but by now I had set No Border on the rdesktop window as a permanent setting.  I needed to figure out how to clear that setting.  It turns out that the place was:

Configure Your Desktop -> Window Behavior -> Window-Specific -> Modify -> Preferences and deleting the item “Window settings for rdesktop”.

Then I could run rdesktop like normal and simply press Ctrl+Alt+Enter to toggle fullscreen mode.

Scanner install bomb

I intended to call this post Installing a scanner on Linux, but I hit a dead end.  The details of my attempt are first, followed by some ponderings.  I wrote the bulk of this article back in February of this year.


I just purchased a used HP scanjet 2400 color scanner and brought it home to hook it up to my Mandriva 2009.0 Linux box.

The Installation Attempt

Let’s see how it goes (I have the driver CD from HP, but I’m going to just hack around first and see if that’s quicker):

  1. I went to “Configure your Computer” and on the Scanners page it said to configure scanners the SANE (drivers?) needed to be installed.  I consented, and a quick 1.5MB download ensued.
  2. I ran XSane in case no setup was needed, but got this message: xsane-no-devices-available-message
  3. I tried again (just in case), but got the same message. :)
  4. I also notice that the scanner does not show up in the “Devices recently plugged in” window in the corner of my screen…
  5. I pressed Help on the XSane No Devices Available message box, and got this message: xsane-reasons-no-device
  6. Back at the Mandriva Configure Your Computer -> Scanners area, I decided to try Add a scanner manually… but the HP 2400c was marked UNSUPPORTED (and said so when I selected it and tried to go on).
  7. A web search turned up a post on the Ubuntu forums pointing to a driver and instructions at elcot.in.
  8. But, hmm, that download says there’s HP software in it, and I’m not sure if it would be legal.  (Can elcot.in transfer their license to unlimited numbers of others?)

Bigger Questions

I think next time I’d check the SANE project list of supported scanners before I purchased a scanner.

But……this experience has me asking questions.  In some senses, running Linux is about supporting the ability to have choices.  But then in other ways, running Linux limits my choices.   What does it mean?  Hmm.

Invisible tooltips

I recently installed Linux (Mandriva 2009.1) on a new PC and moved our home directories over to it so we’d keep our settings, email, etc.  When I did this, everything mainly worked fine, except that the tooltips (if that’s what they’re called) when I hover over an item on the task bar showed up with black text on black background, something like this (simulated ’cause I didn’t take a screenshot at the time):

invisible-tooltips

My wife’s desktop looked fine, so I figured it was some setting of mine rather than a bug in Mandriva or KDE 4.

It turned out all I needed to do was right-click the desktop and pick Appearance Settings:

desktop-context-menu

and then choose Aya (or Oxygen):

select-desktop-theme

Now the tooltip text is visible:

visible-tooltips

Rabbit trails (for those interested in how the solution was found)

I had fiddled with Configure Your Desktop -> Colors, but nothing seemed to have an effect on the taskbar’s colors.  I had recently read about something called “plasma” in KDE 4, which the taskbar is maybe part of.  I thought maybe the plasma stuff has its own color scheme, separate from generic tooltips.  Browsing through the search results from googling mandriva plasma colour settings, I found this article, which took me to a settings area I’d never been to before: Configure Your Desktop -> Advanced -> Desktop Theme Details.  I couldn’t at first figure out what to do in here, but when I changed a setting and clicked Apply, I got this dialog:

desktop-theme-details-clue

“Open the desktop Appearance Settings”… hmm… that got me exploring around (I went first to Configure Your Desktop but couldn’t find the setting, so I right-clicked on an empty area of the desktop and got the context menu, chose Appearance Settings, and picked a theme (the theme was blank when I first went there).  Fixed!

Upgrade bomb

I shoulda hadda backup.

The weekend before last I attempted an online upgrade from Mandriva 2009.0 to 2009.1.  The upgrade from 2008.I-forget-what to 2009.0 had gone with barely a hiccup, though I had performed it without backing up my data first.  This time I wanted to be less cavalier, so I backed up the /home partition beforehand.  I still didn’t back up the programs though.

The upgrade takes many hours even if nothing goes wrong (it’s pulling over a gigabyte, I think).  Things seemed to be going along fine for several hours, until the progress bar was over half, when I got a scary looking error:

upgrade-nvidia-pkg-missing

I chose to continue, but eventually the install gave up.  I restarted it, but after getting the above error again, I started seeing packages downloading that I thought I had seen before, and began to fear that the install was going in circles. I ended up stopping the upgrade.

The next time I rebooted, when I logged in I got an error about kdeinit4 in an odd little unmovable white dialog in the upper left corner of the screen:

Could not start kdeinit4.  Check your installation.

When I pressed the “okay” button,  I got logged back out.  Yipes!  My wife uses this computer too.  Down system!

I wished I had backed up the programs too.

I don’t know how to get back to Mandriva 2009.0.

A Workaround

I did find that I can log in using KDE 3.5, which is still installed.  The desktop is plain looking, but we can do our work until I figure out how to either upgrade or downgrade.

Reason for the Upgrade Issue

Why is there an unsatisfied dependency?  It looks like the Nvidia 71xx proprietary driver has not been upgraded for the version of X that ships with 2009.1.

Hmm.  I wish that I could have known that there was a stopper problem before I got halfway upgraded.

I wonder what I should do now?

Where custom keyboard shortcuts went in KDE4

When I went to Mandriva 2009.0, I also upgraded to KDE 4.  There was only one feature I missed from KDE 3: how you could assign keyboard shortcuts to run arbitrary commands.  I liked that and had my email, browser, and terminal set to easy shortcuts.

I hadn’t been able to find this functionality in KDE 4, even with doing a bit of searching around on the web.  But it’s there!

It’s There!

Here’s how to get to it:

If you’re using the new-style Application Launcher that lets you search, press the “K” launcher button and type khotkeys into the search box.  A program called Input Actions appears (I can’t seem to find it in the menus — I’m not sure how the search finds it).  This is what I think used to be called KHotKeys in KDE 3, and it’s the same good ol’ quirky interface that lets you hook up key combinations to actions.  (The “Windows” key can form part of the key combination, which I find convenient.)

Other Places to Configure Shortcuts

There are two other areas that look similar but didn’t seem to be what I wanted: Configure Your Desktop -> Keyboard and Mouse -> Keyboard Shortcuts allows configuration if the item already appears in the list;  and if you go to the Application Launcher and search for shortcut, there is a Keyboard Shortcuts item that appears that has some system-level shortcuts you can set (good information to know), but it wasn’t what I was looking for either because it didn’t seem to have my programs in the list or have a way to add them.  (Actually I think I could add them into the Keyboard Shortcuts one by first adding them to the menu system using the KDE Menu Editor…but I was used to doing it the old way.  Guess I’ll learn the new way if I eventually need to.)

Update: Boy, do I feel dumb.  I didn’t even try out the shortcuts to make sure they were operational before making this post, and they don’t seem to be operational for me.  I can set up a shortcut either the Input Actions way or through Configure Your Desktop -> Keyboard and Mouse -> Keyboard Shortcuts, but the shortcuts don’t seem to work, even after rebooting.  I don’t know how to do it. : (