LinuxPowerUser.com

Hardware/Disk Management

Ubuntu Diskless Workstation and X-Terminal Howto – Part 3 X-Terminal Setup

by on Feb.27, 2011, under Desktop Productivity, Hardware/Disk Management, Networking

At this point in the series we should have a working diskless workstation. Basically we have a full desktop running from an NFS share. This article will explore how to use the server to deliver a desktop, instead of our old laptop. In my case my server is much more powerful in terms of CPU and RAM than an old laptop, so the best linux experience will come from running applications on the server with the output showing on the laptop, which is the definition of an X-Terminal.

There are two steps to doing this – preparing the server and preparing the client.

There is also some tuning options that we can do with the terminal to make sure we get the best performance from the diskless that we can.

So, lets dive into the server preparation. Ubuntu 9.10 and up have a newer GDM that doesn’t have the gdmsetup configuration program available any more. So, we need to edit a file to turn on something called XDMCP. Our server is running Ubuntu 10.10, and officially XDMCP is not supported on this version, however it can be made to work. XDMCP is a method to allow an X server (in our case the diskless) to pull up a logon window from the server.

Basically a single file needs to be edited to allow xdmcp support. That file is /etc/gdm/custom.conf. A section called xdmcp is added to this file to enable the feature:

[xdmcp]
Enable=true
DisplaysPerHost=5

Once that section is added you can restart gdm with the following command:

sudo /etc/init.d/gdm restart

You can verify that the server is listening on UDP 177 with the following command:

netstat -uan

and look for the following entry in the command output:

udp 0 0 0.0.0.0:177 0.0.0.0:*

One thing to note, this may not work properly on Ubuntu 10.10 if you have IPv6 enabled. You can disable IPv6 by adding ipv6.disable=1 to the kernel command line. This can be done by editing /etc/default/grub and modifying the line beginning with GRUB_CMDLINE_LINUX_DEFAULT=", adding the parameter to look something like this:

GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1 quiet splash"

Then run the following command on the server:

sudo update-grub2

Then reboot the server to disable IPv6. Unfortunately this will remove IPv6 support from the system, so if your relying on IPv6 – beware.

Ok – now lets move on the to the diskless. Lets make sure its booted up and showing the logon screen for Ubuntu. When the screen is up, drop to a command line by hitting Ctrl-Alt-F1. Logon to the system from the command line (hopefully you created a userid on your diskless when you built it).

Now lets bring down the gdm service so we can start X manually:

sudo /etc/init.d/gdm stop

Once gdm is stopped, we can try to use XDMCP to pull up the logon window from the server:

X -query "server IP address or hostname"

This should bring up a logon window from the server. If it does, then we can move on to the next step – if it doesn’t verify the server is configured properly as mentioned above. You can check the kernel command line on the server by running:

cat /proc/cmdline

You can try to login to the server if the window comes up. To continue, you will probably want to drop to the console again by hitting ctrl-alt-f2 and killing X with killall X. This should kill the X server.

In my normal setup I set Ubuntu to boot into console mode without GDM. This allows me to log on, and run a script that starts the X server and pulls the logon window from the server.

To set the diskless to boot to a text console, we need to modify the boot file used to PXE boot the diskless. In a previous article we showed you how to set up a PXE boot file for the diskless. Let’s pull that file up again and make the change we need. Basically the simple addition of a the kernel parameter “text” is needed. For example:

APPEND root=/dev/nfs rw initrd=initrd.img-2.6.35-24-generic.nfs nfsroot=192.168.0.14:/srv/netboot/diskless1c-u ip=x.x.x.x:y.y.y.y:g.g.g.g:255.255.255.0:::none text acpi=force

The parameter is the second to the last one (before acpi=force). Adding this to your PXE boot file (or to a grub command line) will make ubuntu default to non-graphical boot. The next thing we need is a script to start X and use xdmcp to pull up the logon window from the server. Here is an example:

X -dpi 100 -ac -query 192.168.0.14

There are a couple of extra parameters in this script than what we used before. The first one forces the DPI to be 100, which will keep the desktop font size looking normal, and the -ac, which disables access control. Disabling access control still allows local X client programs such as a video player to run on the same desktop that is being pulled from the server. Running multimedia or OpenGL based software over the X protocol across the network is a less than optimal experience, so those should be run locally. More on that later. Lets save the command above in a script on the diskless called startterm. Make sure you make it executable and save it somewhere in your path.

The process will be to boot the diskless, logon as your user id, and run the startterm script, and you will be able to logon to your server.

Improving the Experience

We should have a diskless workstation set up as an X-Terminal. You should be able to use anything on the server you want – minus multimedia/sound apps. They will work but the video in mplayer, for example, will be less than adequate and there won’t be any sound unless you are near the server – because sound will still come from the server’s sound system!

Network sound is actually pretty easy to setup, but it requires some more tweaking on the diskless workstation – Enter Pulse audio system mode. Pulseaudio is the default sound server used on Ubuntu. Its actually pretty powerful, once you understand how to use it. Normally Pulseaudio is configured in per user mode, and is started when a user logs into gnome. Since we aren’t starting gnome on the diskless workstation (its running on the server) we need to reconfigure Pulseaudio to work in system mode, so its always running. Pulseaudio system mode is actually frowned upon in most scenarios, but this is one use case where it makes sense.

First we need to edit some configuration files to enable Pulseaudio system mode. They are located in the /etc/pulse directory. The first one is daemon.conf – edit it and look for the section that looks like this (its near the beginning):

; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; use-pid-file = yes
; system-instance = no
; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 MiB

And modify it to look like this:

daemonize = yes
; fail = yes
allow-module-loading = no
allow-exit = no
; use-pid-file = yes
system-instance = yes
enable-shm = no
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 MiB

The last file is /etc/pulse/system.pa – edit the file and add this to the bottom of the file:

### Enable TCP access to local sound devices
load-module module-native-protocol-tcp auth-anonymous=1
load-module module-zeroconf-publish

After these changes, you should reboot the diskless workstation to enable Pulseaudio in system mode, or you can run the following command to restart it:

sudo /etc/init.d/pulseaudio restart

If you restart the diskless, log on, and use the startterm script to log back into the server, you should here the ubuntu logon sound coming from your diskless speakers. If you don’t here are some things to check:

1. Log on locally with sudo /etc/init.d/gdm start instead of running startterm and make sure your audio system works.
2. Install padevchooser on the server, with sudo apt-get install padevchooser and run it from the diskless while logged into the server. It will place an icon in the menu bar. Right clicking on it should allow you select the sink that reflects your diskless – it will look like something pulse@

In our configuration we have enabled zeroconf so if the diskless is on the same subnet, it should just work out of the box, so to speak.

One more thing – you may need to add your diskless user that you logon to the system with to the pulse and pulse-access groups. This is important when running local applications that use Pulseaudio (see next section for details). Our user is term1 and this is how to add term1 to the groups needed:

usermod -a -G pulse,pulse-access term1

Local Applications

As I mentioned above, local applications can be handy for things that don’t run well over the X protocol across the network. Video is one of those applications. Luckily, its possible to create icons on the servers gui interface (maybe as part of the gnome ui) that actually start and run applications on the diskless workstation itself. The process is pretty simple. Essentially its an ssh session from the server to the diskless that starts an application with the display redirected to the diskless. Remember the -ac parameter in the startterm script? This is why its needed. -ac disables access control with allows this type of functionality to work properly.

Here is an example of a script that starts mythtv on the diskless:

#/bin/bash
/usr/bin/ssh term1@diskless1 /home/term1/bin/mythlocal

This script resides on the server – it starts and ssh to the diskless and then calls another script on the diskless call mythlocal. Here is what mythlocal looks like:

#!/bin/bash
DISPLAY=localhost:0.0 mythfrontend -l /home/term1/mythfrontend.log -v important,general

Basically all this does is set the DISPLAY environment variable to the local X console on the diskless, and then start mythfrontend with options to log myth events to a log file. After a few seconds myth will start on the diskless and use the diskless video hardware to display Mythtv.

Since we are using Pulseaudio on the diskless it’s important to enable Pulseaudio output on Mythtv as well.

There is a caveat to making this work – the diskless must be configured to use key based ssh authentication, instead of password based. If you don’t do this, you won’t see the password prompt generated by the ssh session, and therefore Myth will never get started on the diskless.

Setting up ssh key based authenication is beyond the scope of this article – click here for a good place to start with this. I will attempt to get a future article together on this at a later date.

Tuning Performance

NFS isn’t nearly as efficient as local disk, so the less we write to the nfs based root file system, the better. One thing we can do is sent system log traffic to another form of storage. In our case, we will use tmpfs, which is temporary storage in the diskless computer’s memory. This means that system log files will not survive a reboot (unless you customize the system to dump them to the nfs root fs during reboot).

Essentially we are just going to redirect the /var/log /tmp and /var/tmp directories to tmpfs. This is done by adding the following to the /etc/fstab on the diskless:

tmpfs /var/log tmpfs defaults 0 0
tmpfs /tmp tmpfs defaults 0 0
tmpfs /var/tmp tmpfs defaults 0 0

After rebooting the diskless, all the system logger traffic will go to tmpfs and it should allow the diskless to be a little more responsive.

Well, I think that should about cover it. Comments and other suggestions are welcome as always.

Next up – Ubuntu vs Gentoo vs Arch Linux – I started out with RedHat 4 back in 1996, and moved to Gentoo in 2004, then to Ubuntu in 2008 – I have recently been playing around with Gentoo (again) and Arch Linux, and I may have found my next “favorite” linux distro – Arch Linux.

I also have tested debootstrap, which is a way of building a diskless filesystem on the server without installing ubuntu on the diskless and copying it across. I will see if I can get a quick article out on that process as well. Stay tuned!

Leave a Comment :, , , , , , , more...

Ubuntu Diskless Workstation and X-Terminal Howto – Part 2 – Preparing the diskless image

by on Dec.09, 2010, under Desktop Productivity, Hardware/Disk Management, Networking

Well, after a short break, we are back to our diskless X-Terminal Howto. Today we will cover building the actual diskless image that will be used to boot the X-Terminal. Using ubuntu, the easiest way to do this is to simply install ubuntu on the machine that will be used for the diskless terminal. You can also use a virtual machine to build the image, however this will probably have some interesting issues regarding udev and device detection.

So, basically we be installing ubuntu on the machine itself, and use that install to make an nfs bootable image. So, go ahead and download an ubuntu install cd and have at it. A base install is usually sufficient with working X-Server, network devices etc. You don’t need to install a bunch of applications since those will be served by the server the X-Terminal will attach to. You should make sure you have all the latest updates applied to your install. I also recommend installing the nfs-kernel-server package as well with the command:

apt-get install nfs-kernel-server

Once you have ubuntu installed on your target machine, there are a couple of things we need to do to prepare for making the image NFS bootable.

The first thing we are going to do is modify the initial ram filesystem image to be better suited for network booting. To do this, open a terminal and change to the following directory :

cd /etc/initramfs-tools

We will edit the initramfs.conf file in this directory:

sudo pico initramfs.conf

There are 3 lines in this file that we will want to change. They are shown below:

MODULES=most
BOOT=local
DEVICE=

Change these lines to read:

MODULES=netboot
BOOT=nfs
DEVICE=eth0

Diskless workstations typically require standard wired ethernet connections to work properly. There are some alternatives for wireless, but those are for another article.

After making the changes to this file we will need to regenerate the initial ram disk image for the current kernel. This image will be loaded instead of the standard ubuntu initial ramdisk to allow network booting. Here is the command for creating a new image:

sudo mkinitramfs -o /boot/initrd.img-2.6.35-22-generic.nfs 2.6.35-22-generic

Note the .nfs on the end of the filename (initrd.img-2.6.35-22-generic.nfs) make sure this filename is based on the current kernel version, that can be determined with the command uname -a. The last part of the command is the kernel version to make the initial ramdisk image for.

Here is a sample from a box running ubuntu 10.10:

default@ubuntu-1010:~$ uname -a
Linux ubuntu-1010 2.6.35-22-generic #35-Ubuntu SMP Sat Oct 16 20:36:48 UTC 2010 i686 GNU/Linux
default@ubuntu-1010:~$ sudo mkinitramfs -o /boot/initrd.img-2.6.35-22-generic.nfs 2.6.35-22-generic

The next couple of modifications will have to wait until we have copied the image to the server. So, lets do that next. The best way to copy the image to the server is to mount the servers shared directory that we created in the last article.

The directory was /srv/export/netboot/diskless1. So, lets mount that directory on your workstation. First, lets create a mount point:

sudo mkdir -p /mnt/server

Then we can mount the directory:

sudo mount -t nfs :/srv/netboot/diskless1 /mnt/server

After mounting the directory change to the root of the workstation’s root filesystem and copy the filesystem to the server:

cd /
sudo cp -Rax * /mnt/server

The cp command switches mean copy recursively – ie include all subdirectories (-R) and preserve permissions (a) and limit the copy to one filesystem (x).

After the root file system image is copied from the workstation to the server, we will have to configure the pxelinux command/boot file for the diskless image, as well as move the initrd and kernel image files to the server’s startup_files directory we created in the last article.

First, we will configure the pxelinux command/boot file for the diskless image. This file is a small text file that tells PXE the root file system path, and kernel parameters used for booting the diskless workstation. This file also contains IP autoconfiguration parameters that tell the linux kernel how to configure its network interfaces. Generally, this is handled through dhcp. In ubuntu 10.04 and 10.10 it seemd that in order to boot the diskless reliably, PXE will boot and get the dhcp reservation we created in the first article. Afterwards, the kernel will use hard coded IP address parameters in the kernel command line that match the dhcp reservation the was setup for the workstation. This may not make sense now, but it will soon.

This command/boot file must be saved in a particular location and with a particular name in order for PXE to find it. Essentially, the file needs to be saved in the following directory (if you have been following my server setup examples):

/srv/netboot/startup_files/pxelinux.cfg

The name of the file is the hexadecimal equivalent of the workstations IP address. So, if you used 192.168.0.127 as the IP address reservation on the dhcp server, then the file name will be called:

C0A8007F

This is equivalent to 192(C0).168(A8).0(00).127(7F). You can use the Ubuntu calculator to determine the hex equivalent of your diskless workstations ip.

For our example, the workstation IP will be 192.168.0.127, the IP of the NFS server will be 192.168.0.14, and the path to the diskless root file system will be: /srv/netboot/diskless1.

So, lets look at a sample boot file for the diskless:


DEFAULT /vmlinuz-2.6.35-22-generic
APPEND root=/dev/nfs rw initrd=initrd.img-2.6.35-22-generic.nfs nfsroot=192.168.0.14:/srv/netboot/diskless1 ip=192.168.0.127:192.168.0.14:192.168.0.1:255.255.255.0:::none acpi=force

The first line specifies the kernel image to use. This is tftp’d from the server’s startup_files directory by the diskless workstation at boot. The second line specifies the kernel command line. The root= parameter specifies that the root filesystem will be NFS mounted. The rw means the root filesystem will be read/write. The initrd= parameter specifies the initial ramdisk image we created earlier in this article. The nfsroot parameter specifies the nfs servers path to the root filesystem. The last two parameters, ip= specifies the IP address to use on the LAN interface when the kernel starts. This in the past used to be ip=dhcp. For some reason, in my environment this seems to have stopped working with the latest ubuntu 10.04 kernel and 10.10 kernels. The ip= parameter specifies the IP address of the workstation, the ip of the nfs server, the default gateway, and the network mask, respectively. The :::none are for other unused parameters. Lastly, the acpi=force is for systems where acpi is detected properly. Many older older machines need this parameter to function properly.

Make sure your file includes the right parameter for the ip=, kernel image name, and initrd name. For reference, the kernel image is located in /boot on the workstations image, and the initial ram disk image is what we created earlier in this article.

I will update the article if I can figure out what caused ip=dhcp to stop working properly.

Anyway, we have two more changes to make on the disk image to get a successful boot. The first one is to tell the diskless workstation not to run the normal network configuration. Since our network interface will already be up as part of the PXE process, if the Ubuntu NetworkManager attempts to configure the network stack, we will loose connection to the root filesystem on NFS, causing the kernel init process to fail. So, basically we will tell NetworkManager not to touch the LAN interface by modifying the /etc/network/interfaces file.

If we are using eth0 as our network connection on the diskless terminal, then use the following interfaces file:

auto lo
iface lo inet loopback


iface eth0 inet manual

The last thing we will have to modify is the /etc/fstab file. This file is responsible for telling the Linux kernel which devices to use for the needed file systems on the system. In our case we will simply modify the entry for the root file system.

Normally the entry for the root file system looks something like this:


# / was on /dev/sda1 during installation
UUID=50e370fd-eaf8-486a-adf0-ddb5fe1fb9be /               ext4    errors=remount-ro 0       1

We will change this entry to look like this:


/dev/nfs        /               nfs     defaults    	1       1

This basically tells the kernel that the root file system is nfs mounted.

NOTE: If you intend to leave a hard drive in the diskless workstation, the install of Ubuntu will have set up a swap partition. If you have a machine with low memory, its recommend that you leave the drive in and let Ubuntu detect the swap partition as it boots from the network. If you have 1GB of RAM or more, you will probably be safe removing the hard disk altogether.

The next step is to attempt to boot the diskless workstation from the network. Essentially this usually requires telling the PC’s BIOS to boot from a network device as the first device to attempt.

Usually this is in the BIOS setup. It will vary by PC. Usually this is referred to as Network boot or setting the NIC as the first startup device in your PC’s boot order.

So if you are ready, set your PC to boot from the network, make sure its connected and reboot. If all goes well you will see a screen that looks like this:

If something doesn’t work right, check over your configuration or send me a comment and I try to help. Otherwise your PC should come up into an Ubuntu Desktop logon screen as if it was running from an internal disk drive.

Next article is using the workstation as an X-Terminal for a server (rather than a standalone desktop) and some tuning for performance.

Until next time…

5 Comments :, , , , , , , more...

Ubuntu Diskless Workstation and X-Terminal Howto – Part 1 – Preparing the Server

by on Sep.25, 2010, under Desktop Productivity, Hardware/Disk Management, Networking

Why a diskless workstation? In today’s day and age, this is a good question. My take on it is that I have a multiuser operating system (Linux) running on a large machine (Dual Xeon 5160 with 12 GB RAM) that could be used from several locations in the house by deploying X-Terminals. Rather than spending money on X-Terminals, why not use an old laptop or desktop machine to access the servers gui, applications and resources? That is my reasoning, and I also add some local application support for things not suitable for the X protocol over the network, such as Video, so while the machine is diskless, it isn’t just a dumb display device.

Preparing the Server

Lets get started with preparing the server side of the diskless environment.  For our purposes we will be using a traditional NFS based environment for running the diskless workstation.  This process should work on Ubuntu Lucid or Karmic Server or Desktop Installations.

Several things need to be installed on the server:

  • tftp server
  • dhcp server
  • nfs server
  • pxelinux.0 and startup files

Install the tftp sever, dhcp server and nfs server with the following command:

sudo apt-get install atftpd && sudo apt-get install dhcp3-server && sudo apt-get install nfs-kernel-server

You will also need to download the pxelinux.0 file.  You can get that file here:

http://www.linuxpoweruser.com/files/

For our example, we will need to create a directory to house our diskless file systems, and pxelinux startup files.  We will use /srv/netboot.  Create this directory on your server with the following command:

sudo mkdir /srv/netboot

In this directory, lets create the following subdirectories:

sudo mkdir /srv/netboot/diskless1

“diskless1” is where the root filesystem of our diskless machine will live.

sudo mkdir /srv/netboot/startup_files

“startup_files” is where kernel images, pxe and initrd images will reside for booting diskless workstations – this is similar to the /boot directory on a linux system. The workstation will access these files via tftp.

Lets share the needed directories via NFS.  To do this, we need to edit the exports file on the server and add the following line:


/srv/netboot/diskless1    *(rw,sync,no_root_squash,no_subtree_check)

Then, tell the nfs server to refresh its export list with exportfs command:

sudo exportfs -avr

Next we will configure the tftp server, atftpd. The configuration file for atftpd is /etc/default/atftpd. We will customize ours to look like this:


#USE_INETD=true
#OPTIONS="--tftpd-timeout 300 --retry-timeout 5 --mcast-port 1758 --mcast-addr 239.239.239.0-255 --mcast-ttl 1 --maxthread 100 --verbose=5 /var/lib/tftpboot"
USE_INETD=false
OPTIONS="--daemon --port 69 --tftpd-timeout 300 --retry-timeout 5     --mcast-port 1758 --mcast-addr 239.239.239.0-255 --mcast-ttl 1 --maxthread 100 --verbose=5  /srv/netboot/startup_files"

The first two lines of the file are the default entries – we are going to comment them out and add the second two lines as shown above. After editing the file, restart the tftpd service with the command:

/etc/init.d/atftp restart

Next, we need to configure the DHCP server. Some custom options are required for the DHCP server to tell the diskless workstation how to retrieve its boot files. In our example, we will use a 192.168.0.0/24 network, so the DHCP server configuration will look something like this (this also assumes that this is the only DHCP server for the 192.168.0.0/24 network having more than one is bad news unless configured properly) assuming your DNS servers are 192.168.0.14 and 192.168.0.13 and your default router (route to the internet) is 192.168.0.1:


# The ddns-updates-style parameter controls whether or not the server will
# attempt to do a DNS update when a lease is confirmed. We default to the
# behavior of the version 2 packages ('none', since DHCP v2 didn't
# have support for DDNS.)
ddns-update-style none;

# option definitions common to all supported networks...
option domain-name "rtwsecurenet.com";
option domain-name-servers 192.168.0.14,192.168.0.13;
option ntp-servers 192.168.0.14;

default-lease-time 172800;
max-lease-time 259200;

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;

# This is a very basic subnet declaration.
subnet 192.168.0.0 netmask 255.255.255.0 {
  range 192.168.0.127 192.168.0.254;
  option routers 192.168.0.1;
}

host diskless1  {
      hardware ethernet     00:04:76:3F:A6:36;
      fixed-address         192.168.0.127;
      next-server           192.168.0.14;
      option root-path      "/srv/netboot/diskless1";
      filename              "/pxelinux.0";
}

In the example above I created a reservation for the diskless workstation. DHCP reservations are based on mac addresses. The hardware ethernet parameter above should be editted to reflect the diskless workstation’s ethernet card mac address. The fixed-address specifies the IP address that will be assigned to the diskless workstation. The last 3 parameters, called DHCP options, give booting information to the diskless workstation. These should be updated to reflect the appropriate server IP (next-server) and path (option root-path). Substitute your server’s IP address and path for your installation. The DHCP server that ships with Ubuntu linux is the only one that I am aware of that supports per reservation DHCP options such as these. Be sure to also change the DNS server settings the in the dhcp.conf file to the servers for your site/network.

The last part of preparing the server is the configuration of pxelinux and the diskless boot files.

Configuring PXE

The first thing we need to do is take the pxelinux.0 file you downloaded above and copy it to the /srv/netboot/startup_files directory we created above.  Then, in the /srv/netboot/startup_files directory, make the following directory (as root or using sudo):

mkdir pxelinux.cfg

The pxelinux.cfg directory will contain the pxelinux boot configuration file for each diskless workstation.  We will configure these files after we build our diskless workstation image.

This should about wrap it up for the server configuration piece of the diskless workstation setup.  The next part will cover the building of a diskless workstation image from a standard ubuntu-desktop installation.

Stay tuned!

7 Comments :, , , , , , , , more...

Dealing with multiple USB sound devices

by on Jun.15, 2010, under General, Hardware/Disk Management, Multimedia

Ever been plagued by your linux system detecting your webcam as the first sound device instead of your USB headset?  This is a common problem with Linux, but can be easily remedied with editing your systems module configuration.  On Ubuntu, the important file is /etc/modprobe.d/alsa-base.conf.  This file controls the module settings and parameters for the alsa sound system.  First, we need to understand what to put in this file.

With both of your USB devices connected to the system, run the following command:

lsusb

Here is a sample output:

Bus 001 Device 008: ID 046d:09a2 Logitech, Inc. QuickCam Communicate Deluxe/S7500
Bus 001 Device 005: ID 03f0:2f24 Hewlett-Packard
Bus 001 Device 007: ID 058f:6362 Alcor Micro Corp. Hi-Speed 21-in-1 Flash Card Reader/Writer (Internal/External)
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 005: ID 051d:0002 American Power Conversion Uninterruptible Power Supply
Bus 002 Device 004: ID 10f5:0200 Turtle Beach Audio Advantage Roadie
Bus 002 Device 003: ID f617:0905
Bus 002 Device 002: ID 046d:c521 Logitech, Inc. MX620 Laser Cordless Mouse
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

This output shows all the USB devices connected to your system.  In our example, the two devices we are looking for are:

Bus 001 Device 008: ID 046d:09a2 Logitech, Inc. QuickCam Communicate Deluxe/S7500

Bus 002 Device 004: ID 10f5:0200 Turtle Beach Audio Advantage Roadie

Frequently, on this system, the webcam steals the default input device because of its internal mic.  I would like the default input/output to be assigned to the turtle beach roadie USB headset.  The key here is something that all alsa modules have support for which is an index parameter.  All also modules allow indexes to be assigned to a particular device.  This works pretty well when your cards use different alsa modules.  Simply specifiying module options setting the index # for your particular devices module resolves the issue.  So what happens with USB audio devices, since they use the same snd-usb-audio module?  It seems that linux simply assigns indexes in the order the devices are discovered.

The lsusb output above shows two important pieces of information for each of the sound devices in question.  The USB VID (Vendor ID) and PID (Product ID) can be used to control index assignment.  In our case these values are:

046d:09a2 for the Logitech, and 10f5:0200 for the Turtle Beach headset.  The set of hexadecimal numbers is the Vendor ID and Product ID for the device, in the format VID:PID.

The VID:PID combination can be used in conjuction with the Index value to control the way linux sees the devices.  The format for the module option is:

options snd-usb-audio index=<x>,<y> vid=0x<vid for index x>,0x<vid for index y> pid=0x<pid for index x>,0x<pid for index y>

So, with this in mind, all we have to add to the /etc/modprobe.d/alsa-default.conf file is this:

options snd-usb-audio index=0,1 vid=0x10f5,0x046d pid=0x0200,0x09a2

After rebooting the system, we should never see our Webcam grab the default input again (making us have to go to the Pulse Audio settings and reconfigure the sound system).

Leave a Comment :, , , more...

Boot Sector Management

by on Jan.27, 2010, under Hardware/Disk Management

As promised, tonight we explore boot sector management on X86 style hardware.  Anyone who works with PC hardware long enough, and especially those using linux as primary or secondary OS in a dual boot configuration will find this information valuable.

The system boot sector on x86 style hardware is crucial to being able to boot a linux system on this common platform.  Occaisonally the boot sector becomes corrupted or needs to be backed up.  In the days of MS DOS systems, a command was used to “restore” the boot sector.  The command was

FDISK /MBR

Essentially this would re-write the boot sector on the primary hard disk.

The dd command can be used to perform similar functions, however as is usual with Linux, more boot sector related tasks can be accomplished.

First of all lets review the structure of a boot sector or master boot record on a PC hard disk:

Format of the boot sector:

Size (bytes) Description
446 Executable code section
4 Optional Disk signature
2 Usually nulls
64 Partition table
2 MBR signature

The first 446 bytes of the boot sector contain executable code that is loaded by the BIOS and then executed, and is where OS boot loaders and boot managers (such as grub) store their initial code.  Its also an area of the disk that can become corrupted, or replaced during operating system installs.

The other part of the boot sector that is significant is the partition table.  This is where the disk partition information is stored.  This should not be modified by anything other than a disk partitioning utility such as fdisk.  It can be backed up for data security reasons though.  The total bytes in the master boot record comes to 512.  With dd, simply reading or writing the first 446 or 512 bytes of the disk device will read or write the master boot record.

Scenario 1:  Backup the boot sector (or MBR)

If the first harddisk in the system is /dev/sda, to backup the boot sector the following command can be used:

# dd if=/dev/sda of=bsbackup.bin bs=512 count=1

Essentially this command will read the first 512 bytes of /dev/sda and write it to the file bsbackup.bin.

Scenario 2: Restore the boot sector from a file:

# dd if=bsbackup.bin of=/dev/sda bs=512 count=1

This will restore the boot sector to /dev/sda that was backed up in Scenario 1.

Scenario 3:  Zero out the boot sector (leaving the partition table intact)

Sometimes a virus or other issue can leave a corrupted executable code section in the MBR.  I have personally seen a boot sector that would not store grub information (and thus boot linux after its installed) properly until the first 446 bytes were zeroed out and grub re-installed.  The following command will do just that:

# dd  if=/dev/zero of=/dev/sda bs=446 count=1

Scenario 4:  Zero out the entire MBR (this will erase the partition table as well – effectively destroying the ability to easily access data on the drive)

A variation of the last dd command will wipe out the master boot record entirely.  You will have to repartition and reformat your hard disk after this:

# dd if=/dev/zero of=/dev/sda bs=512 count=1

In summary, the use of dd for boot sector management is a handy tool to have in your linux arsenal.

Next up are some networking topics, such as SSH tunneling, IPSEC VPNs.  Keep watching the site, or subscribe to our RSS Feed.

Leave a Comment :, , more...

Disk and Partition Imaging using dd

by on Jan.26, 2010, under Hardware/Disk Management, Server Administration

Linux provides an abundance of advanced command line tools to manage and modify just about anything on your system.  Today we will explore the use of dd, the primary tool on linux for creating and restoring disk images, among other things.

The dd (diskdump) on Linux can be used to backup an entire disk or partition to an image file. Several caveats apply to this method:

  1. The disk in question can not be in use by an operating system
  2. A destination medium or network resource must be present that is large enough to hold the image.

To backup a disk using dd, the following procedure can be used.

  1. Boot the computer with the disk in question from a Linux Live CD, such as Ubuntu or Knoppix
  2. Mount a destination disk (such as a usb disk drive or nfs mount)
  3. Run dd command to backup disk
  4. Note the size of the disk partition if partitioning a new device is necessary when restoring the image

Here is an example session, to back up a single partition (sda1) containing a Windows XP installation to a USB hard disk mounted at /mnt/sdb1:

As a root user, do the following:

Mount USB disk drive

# mount -t ext3 /dev/sdb1 /mnt/sdb1

Run dd command (piping output through gzip to save space):

# dd if=/dev/sda1 conv=sync,noerror bs=64k | gzip -c > /mnt/sdb1/windowsxp-c.img.gz

Definition of the dd command parameters:

“if=/dev/sda1” is the input file for the dd command, in this case, its linux device sda1
“conv=sync,noerror instructs dd that if it can’t read a block due to an error then it should at least write something to its output of the correct length.

Even if your Hard disk exhibits no errors, dd will read every single block, including any which the OS avoids because it has marked them as bad.

“bs=64k” is the block size of 64 kilobytes. Using a large block size speeds up the copy process. The output of this is then passed to gzip for compression and storage in a file on the destination device.

Noting Partition configuration:

Using the command fdisk -l /dev/<device> where <device> is the device node of the disk being backed up, make note of the number of blocks used to create the partition:

# fdisk -l /dev/sda


Disk /dev/sda: 959.9 GB, 959966085120 bytes
255 heads, 63 sectors/track, 116709 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x2e2d2e2d


Device Boot Start  End   Blocks     Id System
/dev/sda1*      1  15298 122881153+ 7  HPFS/NTFS
/dev/sda2   15299  51771 292969372+ 83 Linux
/dev/sda3   51772  52767   8000370  82 Linux swap / Solaris
/dev/sda4   52768 116709 513614115  83 Linux

The destination disk should have a partition defined identical to the source partition, total number of blocks is the important parameter here.

The partition geometry information can be backed up the the USB hard disk with the following command:

# fdisk -l /dev/sda > /mnt/sdb1/sda_fdisk.txt

Restoring a dd image to a disk/partition

The steps are similar to the backup process:

  1. Boot computer with destination disk from a Linux Live CD
  2. Partition the destination disk, if needed
  3. Mount the source media (usb disk or nfs mount)
  4. Use gunzip and dd to restore image to disk or partition

Here is an example session, to restore the image taken with the above steps:

As a root user, do the following:

Mount image source (USB hard disk at /dev/sdb1)

# mount -t ext3 /dev/sdb1 /mnt/sdb1

Partition destination disk:

# fdisk /dev/<device node in question>; in our case, sda.

<create partition if needed>

Restore image (destination partition is /dev/sda1)

# gunzip -c /mnt/sdb1/windowsxp-c.img.gz | dd of=/dev/sda1 conv=sync,noerror bs=64k

Note: On a fast machine, ie C2Q 6600, and 3ware RAID disk array, a 120GB image takes 25 minutes to create.

In order to have a bootable system, some other configuration may be needed such as restoring a boot block. Check out the next post for details on boot sector management with dd.

A excellent guide on using fdisk for disk partitioning can be found here.

Leave a Comment :, , , , , more...

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!

Blogroll

A few highly recommended websites...