Alternating tri-boot is what I call my preferred configuration for a work environment where down time or restore time due to a failed OS upgrade is costly schedule-wise.  Alternating tri-boot hosts three operating systems on a workstation: the as-delivered Windows XP partition, and two Linux distributions which both mount the same /home partition.

Description:

During normal use, two Linux distributions (e.g. openSUSE 11.0 and 10.2) and the original Microsoft OS are always bootable.  An extended partition containing four logical partitions is created. In the following diagram, the extended partition is aqua and the current Linux boot partition is the rightmost ext3 partition (labeled “root” and containing openSUSE 11.0):

Figure 1. Alternating Tri-boot Disk Partitions

When openSUSE 11.0 is booted, it mounts the common /home and /swap partitions and also mounts the 10.2 partition under /oldOS.  Moreover, the openSUSE 10.2 partition remains bootable since it was untouched during the installation of 11.0.  If booted as root, it would mount the same /home and swap partitions.  Thus all user data is available through normal login under either Linux OS.

Figure 2. Installation Progression for Successive Linux Versions

Figure 2 shows how the contents of the partitions change as the newest Linux OS progresses from openSUSE 10.2 to 11.0 and finally 11.2.  The arrows show the new installations alternating between partitions sda6 and sda7, highlighting the point that current release is not disturbed when the next one is installed.  The availability of each release (10.2, 11.0 and 11.2) always spans two full release cycles.

Thus there are always three bootable OSes and new Linux installations alternate between the two Linux OS partitions — “alternating tri-boot”.

Benefits:

• Never a “point of no return” during upgrades.  At any time during the installation of a new Linux distribution, you can stop and reboot into the most recent working configuration.
• Mounting the previous distribution’s root partition under /oldOS solves  “lost configuration file” anxiety.  Ever been working on your new OS distribution for a few weeks, then fire up a seldom used application only to find out you forgot to copy/save its configuration file?  With the alternating OS partitions, that missing file is available somewhere under /oldOS.  It can be copied or diffed without having to restore from a tar file or other backup.
• New hardware can be installed and debugged using the Windows utilities provided by the vendor.  Problems can be localized to either the hardware or the Linux driver.  No more calling the 800 number only to hear, “Load Windows and call me back.”
• Present the machine as a Windows PC for on-site support and warranty issues.  For service calls, set the default OS back to Windows XP in the NT loader and let the technician have at it.
• Alternating tri-boot retains the NT bootloader.  This is an integral part of avoiding point-of-no-return situations, since the original bootloader and the disk’s MBR are never overwritten or disabled during Linux installations.

Caveats:

• In the midst of a new OS installation there is of course only one functional Linux partition.  During this window of vulnerability, you can’t fall back to booting the /oldOS partition if the current OS is damaged.  So don’t meddle with the configuration of the current OS while installing the new one.
• Don’t let the /home partition be reformatted! Linux installer programs (e.g. YaST for openSUSE) usually scan the disks and partition tables and suggest an installation scenario.  Often they propose reformatting all of the Linux partitions.  This will wipe out the /home directories and all of your user data.  Only one partition (root) should be reformatted.

Coming soon – step-by-step instructions…

• Configuration area (config.inc.php file) ends up in /srv/www/htdocs/phpMyAdmin along with the rest of the installation.
• Decided to use “cookie based authentication”; don’t think I need to remember the password.
• The advanced features were turned on in config.sample.inc.php, but the YaST installer doesn’t load the schema required for this into the mySQL database (maybe it’s not possible unless done during mySQL installation). This resulted in endless error messages of “Table ‘phpmyadmin.pma_bookmark’ doesn’t exist”.
• Learned that I needed to run create_tables.sql, which was not included in the openSUSE package. I downloaded it from the phpMyAdmin site, created user “pma”, defined corresponding controluser and controlpass entries in the config file. create_tables finally ran successfully and the bookmarks error messages went away.
• Stopped annoying half-hour auto-logout with: $cfg['LoginCookieValidity'] = 3600 * 8;

With ZENworks finally replaced with zypper on my system, package maintenance is fun once again, so I decided to try installing the proprietary ATI drivers. From among all of the different ways described on the web, I’ve selected “The Easy Way” from the openSUSE ATI documentation, which uses rpm packages supplied & maintained by ATI (AMD).

Pre-installation Status:

1. glxgears - Mesa GLX Indirect renderer, runs about 90 FPS.
2. Konqueror sysinfo: - Model: Radeon XPRESS 200 5954 (PCIE), Driver: radeon (No 3D Support).
3. /usr/lib{,64}/libGL.so.1.2 - made “before” copies, since some installation instructions call for hiding them after installation. I want to be able to undo any hand edits to return to the standard linux driver if necessary.
4. /etc/X11/xorg.conf - made a copy of the current file.

ATI Driver Installation Steps:

Based on the openSUSE ATI documentation, The Easy Way, openSUSE 10.3 10.2 10.1:

1. zypper service-add http://www2.ati.com/suse/10.2 ATI – adds a YUM catalog containing the ATI proprietary drivers in rpm package format, enabling installation via YaST. I browsed here first, received a “no file found” message, and thought that the ati.com address had been retired by AMD. Fortunately, the instructions noted that the “above URLs are not browseable with a web browser, only by a YUM / REPO-MD capable packager manager”.
2. Step 2 of the openSUSE instructions list a zypper command to install 2 ATI packages, but I wanted to see what was available and check dependencies before installing so I decided to use the YaST installer to carry out this step.
3. Started YaST/Software Management, filtered for the new ATI catalog, and saw four packages: x11-video-fglrxG01 and 3 different versions of ati-fglrxG01-kmp (for bigsmp, debug, and default kernels). Choose the fglrx package that matches your kernel as shown by the uname command (default in my case). The dependency check was ok, so I clicked Accept. The X11 video driver package is 19MB, the kernel driver only 500KB.
4. After the package installation was complete, I started YaST Software Management again to inspect the file lists of the new packages. The kernel module was installed into /lib/modules/2.6.18.8-0.8-default whereas my kernel is 2.6.18.8-0.9. The video driver package installs drivers into X11R6/lib{,64} and did not overwrite the original drivers.
5. sax -r – per the instructions. I’ve never run this command before (except when installing the OS) and it worried me. The screen locks up, then it appears to kill the X server, but it reappears. Now I’ve got the SaX2 GUI and the Monitor tab’s Activate 3D acceleration option is active. After verifying that 1600×1200 resolution was set, I clicked OK without changing anything. Note: found the output from this command in /var/log/SaX.log.
6. A box with a “Test” option appeared, I tested and the display was ok. Then Save, and an announcement that the changes will take effect when the graphics system is restarted. This should allow me to check xorg.conf. But no, the display started behaving badly, so I logged out and back in per the instructions.
7. After completion, the accelerated 3D worked, but I’m now getting constant kernel errors:
   [fglrx:firegl_free_mutex] *ERROR* mutex id 0x.. not found in mutex list
   kernel: warning: many lost ticks.
   kernel: time source seems to be instable or some driver is hogging interupts
   
8. Display didn’t look correct (see below) so I added a Modeline back in from the old xorg.conf file. This proved fatal to the X server. I managed to fix it by rebooting from an old SUSE 10.0 partition, otherwise it would have been time to rescue boot from DVD and attempt repairs. A vivid reminder of why I avoid X11 configuration whenever possible.
9. The CRT Monitor parameters in xorg.conf switched from Modelines to Calculated and the display was being driven differently. There is now vertical compression at the top and bottom of the screen (as if the vertical scan rate was not constant).  Can not completely compensate with the monitor’s adjustments.
10. glxgears - ATI Radeon Xpress Series renderer, now runs 1300 FPS.
11. None of the OpenGL screensavers work; I think they are the source of most of the kernel mutex errors.

Conclusions:

• YaST’s SaX2 is still an adventure and not up to the quality level of most other parts of YaST. There is little documentation (the openSUSE.org page is still a stub), and it runs without feedback, leaving me to wonder what choices are being made and where things are written. I would need to learn a lot of gory details about X11 configuration before I’d feel comfortable with SaX2 and the ATI drivers (or ATI/openSUSE would need to fix the frequent kernel errors).
• Next release, I’ll install the 3D drivers first thing after installing the OS, then review the results and kernel errors. If I don’t like what I see, I can reload the OS, which is the only way I’ll feel confident that I’ve cleaned everything out.
• Once I start using an OS release for production work, I’ll leave the graphics drivers unchanged for the duration. Updating midstream like I’ve done here is too risky (since I don’t need 3D for my projects).

I configured /etc/smartd.conf after reading the smartd.conf and smartctl man pages, the smartd log entries in the messages file, and comments within the file itself. Current setup:

  /dev/sda -d sat \
  -a -o off -S on \
  -s (O/../.././07|S/../.[27]/./08|L/.[02468]/15/./08) \
  -m root@localhost -M test

Notes on the configuration parameters:

1. -d sat - lots of testing to determine this should be sat (SCSI to ATA Translation) and not ata. The various man pages are vague, with one saying “follow the hints appearing in the log file.” Well, the hint in my log file said “use -d ata or -d sat” (sigh). Both seemed to work, so I began with sat since the libata library is present. Subsequent tests of ata produced command failure messages in the log, thus sat is correct.
2. -a - turn on the default recommended set of monitoring functions.
3. -S on - “S” is variously described as “turning on SMART” or “turning on Attribute Autosave”. I believe this is a modal parameter within the disk drive itself, and starting smartd turns this on by default. The manual recommends adding to the configuration to ensure it doesn’t get shut off. It echoes “enabled SMART Attribute Autosave” to messages, reassuring me that SMART is running.
4. -o off – “o” controls “SMART Automatic Offline Testing” (data collection really, not testing). The man page says this command is obsolete and that the collection intervals are chosen by the disk manufacturer. The “O” offline test (discussed next) causes the same data to be collected.
5. -s REGEXP – schedule various off-line tests My schedule: O (offline immediate), every day, 7am; S (Short), every 5 days, 8am; L (Long) – 15th of alternate months. I haven’t discovered what the differences are between the short and long tests (for my disk the short test takes 2 minutes vs. 98 minutes for the long test).
6. -m, -M - email address for important messages. “-M test” sends an email on startup to confirm everything is working.
7. -i N – (command line only, not conf file) set the interval for polling the disk. Seems like this shoud be controllable from the conf file, but since it isn’t I’m staying with the default of 30 minutes.

Notes:

On Linux, “smartctl -c” always showed a failure in the offline data collection status:

(0×05) Offline data collection activity was aborted by an interrupting command from host.
Auto Offline Data Collection: Disabled.

Examining the messages file shows auto-collection being enabled and the scheduled offline collection being started. Everything seems normal, but auto-collection becomes disabled at some point. On two WindowsXP PCs, data collection activity completes normally and Offline Collection is enabled. I don’t know how auto-collection was enabled on these two machines; perhaps HDD Health did it.

Is the Linux collection failure connected with auto-collection becoming disabled? First attempt at solution: switched from “-o on” to off after realizing that my scheduled testing ran the same test. Changed short test schedule to one per week in case it was causing the interruption. The problem has gone away and smartctl now reports “data collection activity was completed without error”.

References:

• Wikipedia – best description of the SMART attributes that I found (other than the spec itself which is exhausting). The external link “Out SMART your hard drive” helped explain why the raw data was different between my Maxtor and Seagate hard drives.
• smartmontools – home page for the SMART tools. They are installed by default in openSUSE Linux, and available for download for Windows XP.
• HDD Health – a graphical user interface that presents current SMART information and failure alerts for Windows PCs. Still need smartmontools to trigger the offline tests.

This problem plus the announcement of openSUSE 11.0 Alpha caused me to reconsider my upgrade plans. I am happy with 10.2 but was planning to upgrade to 10.3 solely to eliminate the nightly 1.5 hour zmd update runs (which I’ve complained about at length in a previous post).

Since I am now going to have to poke around with updating anyway, I decided to look once more for instructions on how to disable the ZENworks ZEN management daemon (zmd). If I succeed in turning off zmd, I may skip the 10.3 release entirely and go directly from 10.2 to 11.0.

How to Disable ZMD:

I found this openSUSE-Community.org article which provides simple instructions for disabling and removing zmd. Using it as a guide, I performed the following steps:

1. rczmd stop – this stopped zmd. Hallelujah! I’ve never known how to do this before now.
2. Start the YaST, Software, Installation Source GUI.
3. Add ftp.suse.com/pub/suse/update/10.2 as a new catalog.
4. Disable (status = Off, update = Off) the old (utah.edu) mirror catalog. This catalog can be removed once the ftp catalog is working.
5. Uncheck the “Synchronize with ZENworks” check box.
6. Click Finish.
7. The catalog information was successfully downloaded from ftp.suse.com, new updates appeared in the updater applet, and were successfully applied. Everything seems to be working.
8. I restarted the Installation Source GUI and was dismayed to see the “Synchronize with ZENworks” box still checked. Don’t know if it is still turned on, or if the GUI is just urging me to turn it back on.
9. Leaving zmd turned off but still installed, I let the system run for a few days until I verified that newly released updates from openSUSE were reported in the updater applet.
10. Once verified, I removed the zmd related packages as described in the article:
    rpm -e zmd libzypp-zmd-backend sqlite-zmd rug zen-updater
11. Restarted the Installation Source GUI: the “Synchronize with ZENworks” box is now grayed out.
12. Rebooted; start-up works fine without ZENworks zmd.

Updater Applet:

If you are running KDE, you may need to perform the following step:

1. Switch the panel updater applet (controlled  by /etc/sysconfig/sw_management) from zlm (the zen-updater update manager) to opensuse.

I had already done this manually during my previous battles with zmd, but I have some recollection that it will happen automatically if the zen-updater application isn’t found. For Gnome, I don’t know what applet (if any) will appear in the panel.

Win XP ran fine after all of the updates, but when I rebooted into openSUSE 10.2, it was unable to connect to the LAN. I found the following alarming entries in /var/log/messages:

  kernel: NETDEV WATCHDOG: eth0: transmit timed out
  kernel: eth0: Transmit timeout, status 0d 0000 c07f media 10.
  kernel: eth0: Tx queue start entry 4  dirty entry 0.
  kernel: eth0:  Tx descriptor 0 is 0008224e. (queue head)
  kernel: eth0:  Tx descriptor 1 is 0008224e.
  kernel: eth0:  Tx descriptor 2 is 0008224e.
  kernel: eth0:  Tx descriptor 3 is 0008024e.

Assuming that on-the-fly loading of the new driver by Windows XP plus a warm reboot had put the LAN chip in an undefined state, I did a full power-off reboot. No help. Perhaps my Linux configuration had been damaged coincidentally. To check, I rebooted a third time into an old, still functional SUSE 10.0 partition. It now failed with the same NETDEV errors. Anxiously, I rebooted into Windows XP, which still worked fine.

I was now faced with convincing evidence that a driver running under Windows XP was leaving the LAN interface firmware or hardware in a condition that could not be (or was not) properly re-initialized by Linux — something I would have dismissed as impossible had someone asked me prior to today.

Wanting my Linux back up as soon as possible, I ran Windows XP System Restore and rolled back out of the driver update. Holding my breath, I rebooted into openSUSE and found myself back on the LAN. Here are the before and after messages sections edited for easy comparison: messages-watchdog.txt and messages-normal.txt.

So Windows XP System Restore (which has saved my butt more than once) is the hero of this incident, with the problem likely in the Linux driver or the Realtek chip itself. I found 30K web hits on the error message, with this thread being the best match. No authoritative solution has appeared even though Linux users have been experiencing this problem consistently since 2005. Probably because debugging it would be a tedious, thankless task.

mount: unknown filesystem type ’smbfs’

Figured I just needed to install the package, but YaST came up empty. Searching on the web, I find that SMB file system support is not compiled into openSUSE 10.2 and that people are using cifs (Common Internet Filesystem) instead. I tried it and it worked, but some people aren’t happy about the removal of smbfs.

mount -t cifs -o username=uuu,password=ppp //winHost/Shared\ Docs /mnt

The mount seems to work just like the smbfs mount. A cursory search turned up no reason why smbfs support was removed by openSUSE. Anyone know the reason?

Update: Upon receiving Nick’s comment (thanks, Nick), I searched for more details and discovered the Linux CIFS Client Guide on the Samba web site. It describes the differences between the Linux smbfs and cifs file system drivers, and continues with an in-depth discussion of cifs driver usage and optimization.

• YaST, System, sysconfig editor, cron – edits various configuration parameters stored in the /etc/sysconfig/cron file (this file can also be edited directly).
• YaST, System, System Services – turn the cron service on/off here.
• /etc/crontab, /etc/cron.d/*, /var/spool/cron/tab/<userid> – these files all use the format described in the crontab 5 man page. My as-installed configuration has one line in /etc/crontab that calls run-crons every 15 minutes (*/15). All of the other directories were empty. Also, the one line starts with a dash, a special feature for root that prevents sending a message to the syslog file.
• /usr/lib/cron/run-crons – shell script called by the default /etc/crontab entry. run-crons runs all pending shell scripts in the /etc/cron.* sub-directories. This is an extensive script containing the logic to handle systems that don’t run 24×7.
• /etc/cron.{hourly, daily, weekly, monthly} – these directories contain bash scripts, not crontab-format files.

As installed, /etc/crontab runs dailies within the first 15 minutes after rebooting and every 24 hours thereafter. If one has the misfortune to get that first run during work hours, cron will continue to run the dailies every day at that time! The daily tasks have a lot of system-wide finds (core files, locate, beagle, etc) that consume 100% of the cpu. This annoyed me frequently in my SUSE 10.0 days.

From reading the run-crons code, I found out about the DAILY_TIME parameter in /etc/sysconfig. If this is set, cron runs the daily tasks only during the hour specified. The trade-off is that the computer must be running at DAILY_TIME (but if not, cron will run daily tasks anyway after MAX_NOT_RUN days). The weekly and monthly tasks aren’t controlled by DAILY_TIME, so I guess if I reboot one minute after noon, weekly and monthly tasks will run at 12:15 pm thereafter.

To try all this out, I set DAILY_TIME to 14:00 and changed the /etc/crontab minutes parameter to 22,52, and will expect to see activity each day at 2:22 pm.

A nice extension would be a WORK_DAY parameter; a time span during which cron would avoid running any of the periodic tasks. This would retain cron’s ability to run tasks within the first 15 minutes after a reboot, so long as it didn’t occur during work hours.

My happiness with openSUSE 10.2 disappears when the Zen Updater runs. Every time it starts, does an update, restarts, etc, update-status (a compiled 64-bit executable, not a Perl or Python script) runs for 5-7 minutes with 99% cpu usage.

Others have complained about this problem, so it’s not just my installation. When I first wrote this, I had a couple of angry paragraphs about the ills of ZENworks and zmd. Since then, I located a more well-reasoned critique of ZENworks (complete with screen shots). It reviews openSUSE 10.1, but most everything still applies.

I started YaST, Software, Online Update Configuration. This turns out to be a canned task that accepts no user input and assigns you randomly to a SUSE update repository each time it runs. So I was moved from utah.edu to somewhere else (with a couple 6 minute update-status runs thrown in).

How shall I deal with ZENworks? First I read an article in SUSEWiki.org on Adding YaST Sources. This discussed how to use a local ISO file instead of the installation CD as the main package catalog, and pointed out a second, YaST update configuration screen: YaST, Software, Installation Source. This is the familiar YaST interface that allows one to configure all package and update repository catalogs.

A log of the various steps I tried (long and tedious, scroll down to the Conclusions):

• YaST, Software, Installation Source.
• Add, Media Type -> Local Directory.
• I checked the ISO image box, browsed to my new /iso directory where I had placed the 10.2 ISO image.
• YaST scanned the image and a new “Configured Software Catalog” appeared.
• To test, I turned the Status Source Setting to Off for the DVD, left the “Synchronize with ZENworks option turned on, and clicked Finish.
• A “synchronizing with ZENworks” info box appeared, so off to the kitchen for a snack during a few minutes of parse-metadata followed by another 6 minutes of update-status.
• Started YaST, Software, Online Update (called YOU in SUSE 10). It suggested an update to Firefox 1.5.0.9, which I new was wrong because openSUSE 10.2 is on 2.0. Where did the problem come from: using YOU, or the ZEN reconfig that switched repositories?
• Installation Source GUI confirms my ISO catalog and the osuosl.org update catalog are both 10.2. Software Management GUI shows the correct version of Firefox currently installed.
• Noticed in the ZEN Software Updater, Configure, that one of the catalogs I had deleted with YaST still appeared. I removed it here also, and the process took only a few seconds! Something is different with update-status.
• Lots of changes through two separate interfaces, so let’s reboot … update-status ran less than 2 min, but both zen-updater and YOU don’t present the correct pending updates.
• Tar file of /var/lib/rpm, then rpm –initdb; rpm –rebuilddb to see if rebuilding the RPM database would fix things. The dates on the DB files were no different upon completion.
• Hid the files, re-ran rpm, no new rpm databases appeared. Apparently rebuilddb is no longer functional. Replaced the files, now YaST Software Management looks normal again. ZEN’s database seems to be in /var/lib/zypp.
• Perhaps the ZEN Management Daemon (zmd) is responsible. Crossing my fingers, I ran Online Update Configuration again. update-status completed in less than a minute. ZEN failed, saying that it had updated YaST (ftp.ale.org this time) but could not update ZEN. Indeed ZEN still retains the old update repository.
• Started YOU, and the correct updates appear!
• Accepted all updates, and they installed correctly, even the Nokia one that had choked ZEN, starting this problem in the first place. Also, new dates have appeared on all of the /var/lib/rpm database files, so they are apparently okay.
• Read some Novell instructions and decided to add a third party repository packman.unixheads.com/suse/10.2 which now appears as a YUM repository. This triggered “synchronizing with ZENworks”; let’s see if the YUM update repository gets fixed.
• The ZEN updater is now showing the exclamation point. It wants to update a bunch of packages that I don’t have installed, packages from packman apparently. I guess it thinks this is the update repository. I turned off packman in the configure screen.
• update-status ran 3 minutes with packman added. So it appears that nothing was wrong with my system: ZEN is just cpu intensive.
• YaST, Software Management now shows ksensor, which I know is from packman. Installation was successful.
• YaST Online Updater is currently working fine with one update catalog and ZEN now presents only the local ISO catalog. Bad news. Options:
  • Keep re-running YaST Online Update Configuration until ZEN installs a catalog that both it and YaST accept. But I’m worried that I’ve broken ZEN somehow and it won’t accept any catalog.
  • Switch the panel updater applet from ZEN to YaST (an earlier post describes the controlling /etc/sysconfig option). Does this also turn off zmd?
  • Make no changes. See if the ZEN applet shows new updates. If not, periodically run YOU to check. Take further action in the event that YOU shows updates and ZEN does not.
• I don’t know what process updates the rpm database and since rpm –rebuilddb was shown to have no effect, I’d better make sure to make a copy of the database before doing anything risky.

Conclusions:

• ZEN processes (zmd, parse-metadata, update-status) are cpu intensive. With no progress bar or feedback of any kind in zen-updater to show concerned users what’s happening, it’s easy to think “infinite loop” when cpu times skyrocket. But it’s probably just a catalog that takes a long time to process.
• ZEN’s configuration of and interaction with YUM update catalogs is fragile. Running YaST, Online Update Configuration to assign a different update catalog is a good option to solve unexplained updater failures and error messages. Sometimes it must be run more than once. Consider it a ZEN reboot.

Current Status:

• Both YaST and ZEN have accepted the switch from the DVD to the local ISO file that I installed. So I won’t ever need to load the DVD again. Excellent – will add this step to my Linux upgrade checklist.
• I now better understand the repositories and DVDs. The retail package DVD (which is double layer) contains noarch, i586, and x86_64 packages for both oss and non-oss. My downloaded ISO DVD image is missing i586 packages. Online repositories have all architectures, but are split between oss and non-oss. I need a source for oss and non-oss i586 packages. Options:
  • Add two online i586 repositories. But update-status run times might return to 6 minutes.
  • Download the i586 DVD ISO image and install that locally.
• Re-ran YaST Online Update Configuration, ZEN installed mirrors.usc.edu successfully such that both zen-updater and opensuseupdater report the same updates.
• Switched the panel updater applet (/etc/sysconfig/sw_management) from the zlm (zen-updater) update manager to opensuse. The SUSE updater now appears (but only in KDE because the updater applet is part of KDE).
• My updating process now looks like it did in SUSE 10.0: the GUI that resembles the package installer with the detailed progress log above and the double progress bars at the bottom. I left the “sync with ZEN” option turned on.

Other information related to package updating:

• Offical openSUSE pages: Using the ZEN Updater, Package Repositories.
• From a LinuxQuestions.org post:
  

  – only common lib is libzypp. For example I deleted all zmd/mono/rug (with exception of single libzypp) and I am using Yast/smart only.
  - rpm db is common to all package managers otherwise eat time you would use different PM different installed/not installed packages would be shown.

• The SMART Package Updater was recommended by a forum post, but a detailed, multi-step installation process and co-existence with ZEN are concerns.
• The Package Management Category at SUSEWiki.org is the source for several of the above links. Other links on Finding RPMs and Package Database Management might be helpful.

• All commands run as root.
• pear remote-list
  WARNING: channel “pear.php.net” has updated its protocols, use “channel-update pear.php.net” to update.
• pear update-channels – successful.
• pear info <pkg> – always responded “No information found for ‘pkg’. I tried both installed packages and the packages I wanted to install.
• pear remote-list – listed available packages and Net_Socket was not listed, even though I could see it on the PEAR web site.
• pear install HTTP_Request -
  install ok: channel://pear.php.net/Net_Socket-1.0.6
  install ok: channel://pear.php.net/Net_URL-1.0.14
  install ok: channel://pear.php.net/HTTP_Request-1.4.0
• pear info HTTP_Request – now it lists information about this package. Something isn’t working; I certainly should be able to get info about a package before installing.
• pear list -
  Installed packages, channel pear.php.net:
Package Version State
Archive_Tar 1.3.1 stable
Console_Getopt 1.2 stable
Crypt_HMAC 1.0.1 stable
HTTP_Request 1.4.0 stable
Net_Socket 1.0.6 stable
Net_URL 1.0.14 stable
PEAR 1.4.11 stable
• This shows another problem. YaST offered a few PEAR packages at install time and I selected a few including PEAR::DB. The DB package appears in /usr/share/php5/PEAR along with Archive Tar and Console Getopt, yet is not listed above. Why not?
• pear run-tests -pr Crypt_HMAC – “running 0 tests”, even though HMAC has a test.php file under the test subdirectory. So I don’t understand this command either.