~chuck/blog

While attempting to build HAL on Beyond Linux From Scratch (Currently the SVN version, scheduled to be the 6.4 release), I came across this error:

probe-storage.c: In function ‘main’:
probe-storage.c:462: error: dereferencing pointer to incomplete type
probe-storage.c:462: error: ‘VOLUME_ID_FILESYSTEM’ undeclared (first use in this function)
probe-storage.c:462: error: (Each undeclared identifier is reported only once
probe-storage.c:462: error: for each function it appears in.)
probe-storage.c:463: error: dereferencing pointer to incomplete type
probe-storage.c:463: error: ‘VOLUME_ID_RAID’ undeclared (first use in this function)
probe-storage.c:464: error: dereferencing pointer to incomplete type
probe-storage.c:464: error: ‘VOLUME_ID_OTHER’ undeclared (first use in this function)
probe-storage.c:465: error: dereferencing pointer to incomplete type
probe-storage.c:465: error: ‘VOLUME_ID_CRYPTO’ undeclared (first use in this function)

After some looking around, I had almost given up hope when I decided to take a look at /usr/include/libvolume_id.h where the particular VOLUME_ID structs are created. I also Googled for that file name, and came across koders.com’s enumeration of header files. The file listed on their site was 116 lines, and the file installed on my LFS box was only 54, and didn’t include the structs for the items listed in the above error.

After making a backup of the original libvolume_id.h file, I copied the file from koders.com (which, incidentally, is from CentOS) and catted it into place on my server.  I ran the compile for HAL again, and now enjoy the sweet and slightly spicy flavor of success.

Hoorah.

/cs

In Intrepid, the nvidia-settings application throws a segmentation fault when trying to write changes to the X config file in /etc/X11/xorg.conf.

A workaround I found on the net was to rename or remove the xorg.conf file.  I’m not certain why this is happening, but there’s an existing bug report on it.

/cs

UPDATE: A fix was released for the bug.

I have a few low-level development projects I want to undertake, and am working on building up my skills in systems programming. So, what better OS to use for a base than Linux, right? However, the Linux kernel is substantially large, and right now, I need to focus on trying to learn fundamental OS programming skills. I think it would be better to start with a smaller base system. Since Linux was written in and based on Minix, I figure I’ll give that a go. Here’s a short walk-through on installing the system in VirtualBox on a Debian Lenny host. Enjoy!

I assume that you already have a VirtualBox installation on your system and you know how to use it. I chose to use the 2.0.4 release of Minix, because the OS base grew substantially for version 3. You can download Minix 2.0.4 from here.

To start, create the VirtualBox guest. I called it, creatively, “Minix 2.0.4″. You can call yours what you like. I created a new virtual disk of 512M, which is much more than is necessary to install Minix, but will give me plenty of room to dick around.

Before booting, configure your Minix VM to boot from a floppy image. Navigate to the directory created when you extracted the Minix tarball, then to the i386 folder therein. You’ll see that there is nothing there. Tell VirtualBox to look for all files, rather than .IMG files. You’ll see the ROOT.MNX and USR.MNX files in your directory. For boot, we need to select the ROOT.MNX file.

Boot the machine. Press =, as it says, to start Minix. You’ll be prompted for a location of a device to use for mounting /usr. Unmount the floppy, as the root floppy is now loaded into RAM, by clicking Devices->Unmount Floppy on the VirtualBox window. Select Devices->Mount Floppy->Floppy Image… and navigate to the USR.MNX file we saw before. In Minix, finish the line with fd0 so that the device listed is /dev/fd0. Hit return, and you should be prompted with a login message. Above this, Minix explains that to install, you need to issue the setup command. Ignore this. We’re going to use the included documentation, and do things manually. What a concept!

In the extracted folder from the Minix tarball, you’ll find a file called usage.txt. This file contains both “automatic” and “manual” installation instructions for Minix. Open the file in your favorite editor. I use vi.

Scroll down to section 6. MANUAL INSTALLATION. These are the instructions we will use to install Minix. Sort of.

First things first, type root at the login prompt to log in as the root user.

Now, issue the part command to start the disk partitioner. For help in part, type ?. I scrolled using the arrow keys to the Kb column, and typed in the entire disk size, since we are not going to partition a VM. How silly would that be? Type the > key on the newly created partition to create the “subpartition” scheme. This is much like partitions inside a FreeBSD slice, except Minix refers to them as slices inside a partition It’s all semantics. I created partitions as follows:

Size in K Partition Description
1440 My Root partition, to be mounted as /.
10240 Partition to mount at /usr.
2880 Swap.

This creates just under 15M of partition space for use on the Minix system, and leaves just under 500M available on the slice I initially created. There is no need to reboot at this time, as the disk driver reloads the partition tables on the next access if the disk is not in use. Since we haven’t mounted anything, we’re good to go. Remember that the numbering for the disk starts at zero, i.e., our first partition is /dev/c0d0p0, and our first slice is /dev/c0d0p0s0.

Set the new slice as bootable by issuing the following command:

# installboot -m /dev/c0d0p0 /usr/mdec/masterboot

Create your swap space, and turn it on:

# mkswap /dev/c0d0p0s1
# mount -s /dev/c0d0p0s1

Now, we will create a filesystem for the /usr partition on /dev/c0d0p0s2:

# mkfs /dev/c0d0p0s1
# readall -b /dev/c0d0p0s1 | sh
# mount /dev/c0d0p0s1 /mnt
# cpdir -v /usr /mnt

This will copy all of the data from the floppy-mounted /usr partition to the /mnt directory, where the disk-mounted /usr partition resides. You can now mount the new /usr directory instead of using the floppy:

# umount /dev/c0d0p0s1
# umount /dev/fd0
# mount /dev/c0d0p0s1 /usr

This is where things get a little hairy. In the usage.txt file, we are instructed to switch back to the ROOT.MNX image to make the root partition and fill it with data. But, if you switch back to the ROOT.MNX image in VirtualBox, and mount it as follows, you can look in the /mnt directory with ls and see that there are some problems:

# mount /dev/fd0 /fd0

So, if the ROOT.MNX image won’t work now, what do we do? Reboot! Type halt at the prompt, and the system will move to the fd0> prompt. Go ahead and power off the virtual machine, or type exit and reset the box through VirtualBox. Then start it back up. Make sure you are booting from the ROOT.MNX image.

When prompted for a device to mount as /usr, simply provide the device we filled earlier, /dev/c0d0p0s1. Again, log in byt typing “root” at the login prompt. From here, we can move on from the instructions in usage.txt:

# mkfs -i 512 /dev/c0d0p0s0
# mount /dev/fd0 /fd0
# mount /dev/c0d0p0s0 /mnt
# cpdir -v /fd0 /mnt
# umount /dev/fd0

You can issue ls /fd0 after mounting it, and see that the file names are correct, unlike they were previously.

The /mnt/etc/issue file (or /etc/issue, when the device is mounted as root) creates the “use setup” line when the system boots, so it can be removed, or replaced with one of your choosing. The /mnt/etc/fstab file (or /etc/fstab, when the device is mounted as root) needs to be modified to reflect the new partitions. I used sed and cat to make my edits:

# sed ’s/t=unknown/t=\/dev\/c0d0p0s0/;s/r=unknown/r=\/dev\/c0d0p0s1/’ \ /mnt/etc/fstab > /mnt/etc/fstab.new
# cp /mnt/etc/fstab.new /mnt/etc/fstab
# cat >> /mnt/etc/fstab << EOF
> swap = /dev/c0d0p0s2
> EOF

Now unmount the new root partition and make it bootable:

# umount /dev/c0d0p1s0
# installboot -d /dev/c0d0p1s0 /usr/mdec/bootblock boot

Now we’re all set! Simply issue halt again, as before, and reboot the machine. Don’t forget that you need to unset the boot floppy device, or change the boot order in VirtualBox to have it boot from the hard disk.

Use your new system wisely!

/cs

I have a laptop that I use as my primary computer, and a desktop machine that I attach it to at work (both run linux).  I use synergy to connect the two so that I don’t have to remember which mouse is attached.

By default, synergy is quite insecure.  On the contrary, running synergy inside an encrypted ssh tunnel is quite secure.

I have two machines:

1. My laptop: synclient
2. My desktop: synserver

So, I use the keyboard/mouse from the desktop to control everything.  I assume that you are already aware of synergy and that you already have a working config.  Oh, ant that you are running Linux.  Oh, and that both of your Linux machine name the other one in their /etc/hosts files.  Oh, and that you have your synergy config in /etc/synergy.conf.  Now we don’t have to have everything all cluttered with flags.

There is no guaranty here that any of this will work on or improve the security of Windows.  You’ve been warned.

I log into both machines, and start up the synergy server on my desktop (I have a synergy.conf in /etc, so there is no need to pass it a config file argument with -c):

chuck@synserver:~$ synergys

I then log into my laptop, and do the following:

chuck@synclient:~$ ssh -f -N -L 24800:synserver:24800 synserver
chuck@synclient:~$ synergyc localhost

Now, it’s a pain to have to do that every time.  So, I put an alias in my ~/.bashrc:

alias synclient=’ssh -f -N -L 24800:synserver:24800 synserver && synergyc localhost’

Now, I can log into my laptop, once I’ve started synergys on the desktop, and run this:

chuck@synclient:~$ synclient

Now, the SSH tunnel has been configured, and the synergyclient started, all in one command.  No mess, no fuss. No password leaked on the net.

/cs

This tutorial will set up a basic virtual user config for vsftpd on a RHEL5-based system.  I recommend that you make backups of existing config files before implementing this solution, in case you need to revert.  This allows virtual “guest” users to log in with individual usernames and passwords and have access to a base directory.

I suggest building the initial files in a directory of their own first, and the steps below outline copying the files into place.

Six simple steps:

Step 1: Create the virtual user database.

Create a text file with each username/password pair on two lines, i.e:

# cat /etc/logins.txt
username
password
username2
password2

Then, use BerkleyDB to has the file, and change its permissions:

# db_load -T -t hash -f logins.txt /etc/vsftpd_login.db
# chmod 600 /etc/vsftpd_login.db

Step 2: Create a PAM file which uses your new database.

# cat > vsftpd.pam
auth required /lib/security/pam_userdb.so db=/etc/vsftpd_login
account required /lib/security/pam_userdb.so db=/etc/vsftpd_login

# cp vsftpd.pam /etc/pam.d/vsftpd

Step 3: Set up the location of the files for the virtual users by creating a “wrapper user”.

# useradd -d /home/ftpsite virtual

Step 4: Create your vsftpd.conf config file.

# cat > vsftpd.virtusr.conf
anonymous_enable=NO
local_enable=YES
write_enable=NO    # change to YES if you want uploads available
anon_upload_enable=NO
anon_mkdir_write_enable=NO
anon_other_write_enable=NO
chroot_local_user=YES
guest_enable=YES
guest_username=virtual
listen=YES
listen_port=10021    # optional
pasv_min_port=30000    # optional
pasv_max_port=30999    # optional

# cp /etc/vsftpd.conf /etc/vsftpd.conf.orig
# cp vsftpd.virtusr.conf /etc/vsftpd.conf

Step 5: Restart vsftpd.

# /etc/init.d/vsftpd restart

Step 6: Test.  I think you can figure this one out on your own.

Hold on to the logins.txt file, and simply update it and rebuild the DB when you need to add a user.  This allows several users access to the same directory and files.  Only give access to people you trust.

/cs

I have found happiness, and it is in the form of xrandr!

Please note:  This will NOT work with the fglrx ATI driver.

Using the xrandr command with the ati X driver enabled, I can enable and disable an external monitor at will on my laptop.  Currently, I am running Ubuntu Hardy 8.04.  My xrandr version is 1.2:

$ xrandr –version
Server reports RandR version 1.2

I have an old CRT sitting on my desk on the other side of my laptop from the two LCDs that are attached to my desktop computer, and have plugged the old CRT into other boxes as console monitors and the like, but mostly, it just sits there taking up space.

So, I plugged it into my laptop, after it was booted and I was logged in, and ran xrandr:

$ xrandr
Screen 0: minimum 320 x 200, current 2560 x 1024, maximum 2560 x 2048
VGA-0 connected 1280×1024+0+0 (normal left inverted right x axis y axis) 310mm x 230mm
1024×768       85.0 +   84.9     75.1
1280×1024      59.9*
800×600        84.9     85.1     75.0
640×480        84.6     75.0     60.0
720×400        70.1
LVDS connected 1280×800+1280+0 (normal left inverted right x axis y axis) 0mm x 0mm
1280×800       60.0*+   60.0
1280×768       60.0
1024×768       60.0
800×600        60.3
640×480        59.9

This tells me what monitors I have plugged in (VGA-0 and LVDS), and what resolutions they support.  Using xrandr –help or man xrandr, you can devise a command to enable or disable either monitor at will.

For instance, if I want to enable the CRT in its current position, I simply run the following command:

$ xrandr –output LVDS –mode 1280×800 –pos 1280×0 –output VGA-0  –mode 1280×1024 –pos 0×0

This sets the CRT (VGA-0) up as the left-hand monitor, starting at position 0×0, and enables the LCD (LVDS) on my laptop as a continuation of the screen from position 1280×0, and sets the resolution modes for each.  Basically, it gives me a wide desktop spanning the two monitors.

When I need to unplug the CRT because it’s hurting my eyes, or if I need to take my laptop off of my desk and use it elsewhere, then I simply issue the following command to turn it off:

$ xrandr –output VGA-0 –off

Further, I can manipulate the command to place the CRT to the right of the LCD, use an LCD instead of a CRT, place a monitor above my laptop, and a number of other things.  It can also be used in virtual machines to manipulate the desktop so that when full-screen mode is enabled, the desktop resizes itself, although configuration for this is outside the scope of this document.

Off and runnin’!

/cs

So, I needed a flash and a java plugin for Icecat, once I got it installed.

On Ubuntu, installing the Flash player is easy:

$ sudo apt-get install flashplugin-nonfree

What’s not so easy is getting Icecat to use it.

I installed Icecat in /usr/local/src, and symlinked “icecat” to the actual directory. So, my Icecat plugins are in /usr/local/src/icecat/plugins. Here’s how I linked the flash plugin in:

$ cd /usr/local/src/icecat/plugins
$ ln -s /usr/lib/flashplugin-nonfree/libflashplayer.so libflashplayer.so

I did this while Icecat was running, and immediately had flash capability. I confirmed by typing “about:plugins” into the URL box.

For the Java plugin, I downloaded j2se 1.4 (which is EoL’d, by the way!!) from here:

http://java.sun.com/j2se/1.4.2/index.jsp

In much the same fashion, I cd’d to /usr/local/src, and moved the binary there. I ran this:

$ sudo sh j2re-1_4_2_18-linux-i586.bin

to extract the files. Then I ran the following commands:

$ sudo ln -s j2re1.4.2_18 java
$ cd /usr/local/src/icecat/plugins/
$ sudo ln -s /usr/local/src/java/plugin/i386/ns610-gcc32/libjavaplugin_oji.so libjavaplugin_oji.so

Keep in mind that this is for my previous icecat install.  For firefox, the plugin will go in /usr/lib/firefox-3.0/plugins, and for Iceweasel on Debian, it will go in /usr/lib/iceweasel/plugins.

This was also done while Icecat was running, without issue. Now, I can surf Hulu and YouTube and play java applet games at work! Shh, don’t tell!

/cs

This title is actually a bit misleading, but still quite true.

As it turns out, the bug appears to lie not in the fglrx driver, as previously thought, or in the Gnome Power Manager, also as previously thought, but in Compiz/Fusion. I can ascertain this because I recently installed the most current version of Compiz/Fusion from git sources using directions here.

This was four days ago. I continued to use the sleeparound.sh script I had written, until one day I mis-clicked the launcher, and shut the lid. I thought to myself “Oh, Crap!”, as I had a few things open. So, I let it sleep, and opened it back up, and voila! It asked for my password!

I couldn’t believe it, so, I shut the lid, let it sleep, and opened it, and again was greeted with the password prompt. I was so excited that I did this about five more times, and said “Look, honey, it works!” She smiled and nodded, but was not overly thrilled.

PLEASE NOTE: Before I upgraded compiz, I installed the proprietary ATI driver with directions from cchtml and customized my /etc/default/acpi-support file as I did previously.

All in all, I basically over-rode the Ubuntu-installed packages, but it seems to have resolved the issues I was having. Prior to upgrading compiz, I was still experiencing the suspend issue with the proprietary ATI driver.

Hopefully, it won’t be long before the versions that I have are in the Ubuntu repos!

/cs

OK, so I have a special requirement for using Firefox 2. However, I run Hardy, and it has a default install of (i can’t believe it) the BETA version of Firefox 3.0b5. Golly.

So, I tried installing the firefox2 package from the Ubuntu repos, and had issues with some of the addons I use. I tried the “binary” tarball from the Firefox website. No go – it still wants to revert to FF3. As any seasoned Ubuntu user knows, don’t eff with Ubuntu. Going around making things work can sometimes cause problems with things, well, working.

After some research, I found IceCat.

IceCat is “the GNU version of the Firefox browser.” Basically, the GNU guys took Mozilla’s code, and compiled it without using the “proprietary” parts, meaning the Logo and the name, among other things.

So, I downloaded the IceCat tarball. I unpacked it, expecting it to whigh out on me, as the Firefox tarball did, and low and behold! Right there next to my FF3 window was IceCat 2.0.0.13, running at the same time!

I figured it had to be too good to be true, and went about installing my needed Firefox extensions. AND THEY WORKED! HooRAH!

So, needless to say, I’m sold on IceCat as a GREAT replacement/addendum to Firefox. Get it. Use it. Love it.

/cs

So, I read an article that is both sensical and scary:

Flaming Mountainside: Breeding Internet Superbugs

I get a LOT of junk mail in my USPS mailbox in front of my house, and I pretty much ignore it, as long as it doesn’t look terribly important. It goes right into the trash.

I have to agree with vixie in the above article; the issue is not being solved, just pushed away.

In the Linux Admin world, currently, in order to have a mail server that will send to Yahoo! and AOL, among others, you already have to jump through plenty of hoops:

• Email DNS – Forward and reverse DNS entries for the IP and A record.
• SPF – Sender Policy Framework
• DomainKeys - By far, the worst, in my opinion.

These are just a few things to try, and still, the spam keeps flowing, because the spammer has a need to get his message through.  I suppose I could try Spamassassin or Postini.  Some companies even offer to manage the spam problem for you (and they do a pretty darn good job of it, too!).

As the old saying goes, “Necessity is the mother of invention.” Continuing to “fix” the spam issue will cause the number of spammers fluent in loopholes to exceed the number of hackers available to fix the problem.

All in all, how do we fix the spam issue? The same way we fix the junk mail issue: The delete key.

/cs

I re-installed Windows XP on my laptop for the sole purpose of playing American McGee’s Alice. And I blew away grub.

So, to reinstall it, I booted the Hardy LiveCD, and mounted some things:

$ sudo mkdir /mnt/ubu
$ sudo mount /dev/hda5 /mnt/ubu/
$ sudo mount -t proc none /mnt/ubu/proc
$ sudo mount -o bind /dev /mnt/ubu/dev

I was able to determine the appropriate partition to mount by running “fdisk -l” before-hand.

Once mounted, I chrooted into the existing installation:

$ sudo chroot /mnt/ubu/ /bin/bash

Once in, I ran the following, and received the listed error:

# grub-install /dev/hda
/dev/hda does not have any corresponding BIOS drive.

Crap. What to do now? So, after a little Googling, which I am quite fond of, I found the answer:

# grub-install –recheck /dev/hda
Probing devices to guess BIOS drives. This may take a long time.
Searching for GRUB installation directory … found: /boot/grub
Installation finished. No error reported.
This is the contents of the device map /boot/grub/device.map.
Check if this is correct or not. If any of the lines is incorrect,
fix it and re-run the script `grub-install’.

(fd0) /dev/fd0
(hd0) /dev/hda

Success! I can now boot myself back into a realm of happiness known as the Hardy Heron!

/cs

Yo.

I have a desktop machine and a laptop that I run together with synergy.  The desktop is a Dell with a dual-head configuration, and the laptop is, well, a laptop.

I have been running the laptop to one side, and have ended up with cricks in my neck on several occassions.  I did not like this, as cricks hurt!

So, I figured out a way around it.

I configured my synergy.conf to specify that the boxes were both right AND left of each other in the links section:

section: links
tuck:
left = eli
right = eli
eli:
right = tuck
left = tuck
end

I then arranged things so that I have a monitor from the dual head on each side.  I had to put the right monitor on the left, and the left monitor on the right in order to get everything working the way I wanted.  Now, I run the synergys daemon on the laptop, and use it to control the desktop.  The configuration works in such a way that the left monitor for the desktop machine is to the right, and the right monitor is to the left of the laptop.  This creates the effect that I wanted: Right to left, my mouse runs through a monitor, the laptop, and then another monitor and vice versa.  It may sound a little confusing, and it actually is.  It took about 30 seconds of seeing it in action to get used to the idea.

One of the neat side effects is that it loops around.  So, if I go to the right-hand monitor (which is actually the left monitor of the desktop), it continues onto the left-hand monitor (which was originally the right monitor on the desktop).

This allows me to easily see all three monitors in a more consistent and less neck-strenuous fashion.

/cs

Oh, my.  What a weird couple weeks it’s been for my laptop…

I started with Alpha5, in which suspend worked.  Alpha 6 also supported suspend.  Both with the open-source ati driver upon install.  Beautiful!  Thank you Ubuntu for having an awesome distro!

Supposedly, the xorg-driver-fglrx package in the Ubuntu repos for the Hardy development version addressed the suspend/resume issues that have been the bane of Linux geeks with newer ATI cards eveywhere.  I, for one, did not notice that the issue had been resolved.

I DID notice, however, that out-of-the-box, so to speak, suspend worked with the open-source ati driver.  I could suspend, resume, hibernate, etc.  But, I’m whiney, and wanted my ever-so-cool desktop effects (mostly for the transparent terminals).

Upon installing this xorg-driver-fglrx package, my suspend/resume functionality broke.  Ouch.  That’s a beta-killer if ever.

I have tried every sort of configuration imaginable, and googled every combination of keywords for fglrx, suspend, hibernate, sleep, resume, ati, proprietary, and on and on.  I found several people (with different cards and different configurations) that were successful in manipulating the /etc/default/acpi-support file in such a way that suspend just worked.  Hoorah for them!  I was still stuck.

I have a Gateway MT3705 with an integrated ATI Radeon XPRESS 200M graphics card:

$ lspci -vv
01:05.0 VGA compatible controller: ATI Technologies Inc RC410 [Radeon Xpress 200M] (prog-if 00 [VGA controller])
Subsystem: Gateway 2000 Unknown device 0318
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 255 (2000ns min), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 19
Region 0: Memory at d0000000 (32-bit, prefetchable) [size=256M]
Region 1: I/O ports at 9000 [size=256]
Region 2: Memory at c0000000 (32-bit, non-prefetchable) [size=64K]
[virtual] Expansion ROM at c0020000 [disabled] [size=128K]
Capabilities: <access denied>

Pulling info from dpkg, I can see the version and supported cards:

$ sudo dpkg -p xorg-driver-fglrx | grep ‘Version\|Xpress’
Version: 1:7.1.0-8-3+2.6.24.11-12.31
* Radeon Xpress: 1200 series, 1100 series, 200 series

All in all, it is “supposed” to work.  I have NO idea why it does not.  I am not that far along.  In fact, I don’t think the issue is with the driver, after my most recent discovery.

I have successfully been able to suspend and resume my computer for several hours now!  Hoorah!

Here is what I have done:

I changed a few things around in the /etc/default/acpi-support file, as per the instructions as cchtml pertaining to Gutsy and Feisty, because they have not yet gotten the Hardy page together (since it’s still alpha, i understand!).  Here is my current /etc/default/acpi-support file:

$ sed ‘/^#/d;/^$/d’ /etc/default/acpi-support
ACPI_SLEEP=true
ACPI_HIBERNATE=true
ACPI_SLEEP_MODE=mem
MODULES=”"
MODULES_WHITELIST=”fglrx”
SAVE_VBE_STATE=false
VBESTATE=/var/lib/acpi-support/vbestate
POST_VIDEO=
USE_DPMS=false
DOUBLE_CONSOLE_SWITCH=false
HIBERNATE_MODE=shutdown
LOCK_SCREEN=true
STOP_SERVICES=”"
RESTART_IRDA=false
ENABLE_LAPTOP_MODE=false
SPINDOWN_TIME=12

This is not stock.  However, I have made enough changes to it that I am not sure what the stock implementation is anymore!  It works now, so I’m cool with it.

Now, if I try to suspend via gnome-power-manager, or the Logout button, it will sleep and blink at me slowly and drearily, but will abruptly tell me to piss off when I try to wake it.  Ever poked a sleeping bear?  Same thing.

However, if I open my terminal and run this command (in bold), I can sleep and resume, as you can see by the output of the script (not in bold):

$ sudo /etc/acpi/sleep.sh force
ifdown: interface eth0 not configured
ifdown: interface wlan0 not configured
* Shutting down ALSA…                                                 [ OK ]
* Saving the system clock
* Setting the system clock
Ignoring unknown interface eth0=eth0.
Ignoring unknown interface wlan0=wlan0.
* Setting up ALSA…                                                    [ OK ]
FATAL: Module acpi_sbs not found.
FATAL: Module acpi_sbs not found.

So, when it suspends, I get a grey-and-white-blinky-screen-of-death, and then *poof!* it’s out and peaceful.  When returned to a wakeful state, I am greeted with my desktop and session information that I left behind.

Once concern I have is that the screen is not locked when the computer awakens, so theoretically, anyone could awaken my laptop and overtake me completely.  Since it is nearly always within arm’s reach, I am not terribly worried.  I worked around this issue as such:

$ sudo /etc/acpi/sleep.sh force && gnome-screensaver-command –lock

For me, this is too much to remember, so I have set up a little alias in my ~/.bashrc file called simply “sleep” that performs this command for me when I type, well, “sleep”:

$ grep “alias sle” ~/.bashrc
alias sleep=’sudo /etc/acpi/sleep.sh force && gnome-screensaver-command –lock’

I am a terminal junky, and am perfectly fine with this.  But, some people are not, so here’s a GUI-type version of the above.  These can be run by pressing Alt-F2, and copying in the commands.  You will likely be prompted for a password:

$ gksu gedit /usr/local/bin/sleeparound.sh

Type into file:
#!/bin/bash
gksu /etc/acpi/sleep.sh force && gnome-screensaver-command –lock

$ gksu chmod +x /usr/local/bin/sleeparound.sh

Now that the tough terminal part is done, simply add a custom launcher to the panel (right-click the panel, click “Add to Panel…”, click “Custom Application Launcher”) that calls this command.  It will prompt you for a password, then sleep, and lock your screen when it wakes up.

Cool.

Now, make a note that during my research, I found that some people had networking problems after resume, particularly pertaining to wireless.  I did not, so will not delve into that, but two key things that I saw (which could be added to the sleeparound.sh script) wereunloading and reloading the driver modules for the particular net interface, and restarting the Gnome Network Manager.

I gotta say, I love Linux.

/cs

UPDATE 080319: A smoother version of the command to use for sleep involves using the -S flag for sudo, which causes it to read from standard input.  For example, in .bashrc, the alias “sleep” would be comprised of this:

alias sleep=’gnome-screensaver-command –lock && sleep 3 && cat ~/.passfile | sudo -S /etc/acpi/sleep.sh force’

So, in your home directory, issue the command ‘cat > ~/.passfile && chmod 400 ~/.passfile’ and type in your password.  Setting the permissions to 400 disallow other users from reading the file (other than root).  You can also replace the command in the shell script we created above with this, as well.

This version will lock the screen, then sleep, whereas before, it would sleep, then lock the screen on wake.  Sorry – I wrote the last one at like 2 in the morning.  /cs

I love Ubuntu. It’s Linux that you can plug in and use quickly, without a whole lot of setup time. I even convinced my Uncle Phil and my Grandmother-in-law to use it, and they are die-hard Windows fans.

Well, wow. My first impression once I got Hardy installed was that the new modern art deco background is a far reach from their traditional “wiggly lines” art.

I think I like it.

continue reading…