The complete instructions are here.

# openvt -c 9 top

This can be done quite easily using udev and there are a variety of great examples on the udev wiki. Here is one I modified slightly which could act as a simple way to do backups to an external USB device without having to manually mount the device each time.

Create the file “/etc/udev/rules.d/11-backup-auto-mount.rules"

--start--

KERNEL!="sd[a-z][0-9]", GOTO="backup_auto_mount_end"
# Import FS infos

IMPORT{program}="/sbin/blkid -o udev -p %N"
# Global mount options

ACTION=="add", ENV{mount_options}="relatime"

# Filesystem-specific mount options

ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs", ENV{mount_options}="$env{mount_options},utf8,gid=100,umask=002"
# Mount the device

ACTION=="add", RUN+="/bin/mount -o $env{mount_options} /dev/%k /backup"
# Clean up after removal

ACTION=="remove", ENV{dir_name}!="", RUN+="/bin/umount -l /backup"
# Exit

LABEL="backup_auto_mount_end"
--end--

The original disks had labels like:
boot
srv
tmp

On the new disks I thought good names would be:
/boot
/srv
/tmp

(I think Redhat actually names things this way by default?)

Anyhow, to make a long story short, mount by label ignores the leading slash. When the system rebooted, as predicted the drives came up in a different order so a “mount LABEL=srv” will actually mount the first disk named either “/srv” or “srv”.

Moral of the story; it’s probably a good idea not to use any strange characters when naming disks.

# zypper install nut

Next you need to edit /etc/ups/ups.conf and make an entry for your UPS driver and serial port.

[myups]
driver = bcmxcp
port = /dev/ttyUSB0
desc = “Local UPS”

Next I started the UPS driver manually in debug mode so I could see what was going on. The nice thing about this driver is it will auto-discover the UPS serial port speed.

# /usr/lib/ups/driver/bcmxcp -a myups -D

In a separate terminal window, start upsd.

# upsd

Now you should be able to query the UPS:

# upsc myups@localhost

Because I was just collecting statistics, I wasn’t interested in using upsd to automatically shutdown servers or anything fancy but that is possible.

Instead, it’s buried in the Gnome Configuration Editor which makes it really hard to find so here are the steps to fix this:

1) Computer -> More Applications

2) System -> Gnome Configuration Editor

The setting that needs to be changed is:

3) /apps/panel/applets/window_list_screen0/prefs/display_all_workspaces

You can navigate down the tree or use the “Find” function.

That’s it! Have a lot of fun!

Update: see the first comment for an equally obscure but perhaps easier method.

For reasons that I have not yet resolved, the wirless networking became unstable and as a result, the updates had to be aborted.

Unfortunately, a new kernel was part of the updates and when the laptop rebooted it was in a bad state. X windows wouldn’t start and critically, there were no network drivers for the new kernel. To make matters worse, OpenSUSE does not keep the old kernels in /boot (why is that?) so there was nothing to fall back on.

With nothing left to do, it was time to try rescue mode and in a few short steps I had the system fully working again. Here is what I did:

Step 1: boot to rescue mode (duh).

Step 2: mount your hard disk partitions under /mnt in the same layout they would be normally. For example:

# mount /dev/sda2 /mnt

# mount /dev/sda1 /mnt/boot

… etc.

Step 3: Next we need to make sure we have acess to all the important system resources.

# mount --bind /proc /mnt/proc
# mount --bind /sys /mnt/sys
# mount --bind /dev /mnt/dev

Step 4: We’re ready to chroot into our new environment.

# chroot /mnt

Step 5: We are now running on our system just as if we had booted to it and we can perform repairs. In my case all I needed to do was complete the updates:

# zypper up

I rebooted and everything was back to normal.

It didn’t take me long to get it working but google returns a lot of posts with not so good information so here is the documentation on my experience.

There are surprisingly few useful results returned by Google. Both the “Advanced Bash-Scripting Guide” and GNU Bash manual mention testing to see if the prompt variable is set:

if [ -z $PS1 ]

but that will not work. For one thing, it’s perfectly reasonable for someone to have their prompt set to null, but aside from that, the prompt variables are not set when invoking a script so the test always returns the same result.

A coworker pointed out that that strangely, “man bash” has other ideas. In the Conditional Expressions section, it explains “-t fd True if file descriptor fd is open and refers to a terminal.” That sounds exactly like what we want:

if [[ -t 0 ]] ; then
  echo interactive
else
  echo non-interactive
fi

but there is still a problem. If you invoke the script remotely via an ssh call (e.g. ssh root@<remotehost> bashscript.sh”),  stdin will not be connected to a terminal. To make the command more reliable we need one more test:

if [[ -t 0 || -S /dev/stdin ]] ; then
  echo interactive
else
  echo non-interactive
fi

Be aware that detecting a socket is also no proof of “interactivity”, but at least we are getting closer.