LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   HowTo: Upgrade Slackware 12.0 to 12.1 (https://www.linuxquestions.org/questions/slackware-14/howto-upgrade-slackware-12-0-to-12-1-a-640473/)

shadowsnipes 05-07-2008 03:37 AM

HowTo: Upgrade Slackware 12.0 to 12.1
 
This HowTo will show you an example of how to upgrade Slackware 12.0 to 12.1.

Note: This HowTo is just a guide and does not cover all possible scenarios. Rather it attempts to expand on the great information carefully compiled in the UPGRADE.TXT and CHANGES_AND_HINTS.TXT through a practical example. Again, this HowTo is just a guide and may not be correct for your situation. Use your brain and adjust accordingly. If you have any questions, concerns, comments, or complaints please voice them through posting. This is a forum after all :)

Updates:
All of the most recent changes are in RED.

2008-07-03
  • Note about Liberation Fonts overriding MS TTFs
  • Link to Beautiful Fonts thread

2008-05-18
  • Split HowTo into two parts
  • Expanded Updates section
  • More kernel package information, patching sources for non-SMP, UTF8 console
  • Added more to Miscellaneous Fixes section - mostly because I saw a few threads crop up recently about some of the issues I had not discussed (though were still in the CHANGES_AND_HINTS.TXT).
  • Discussed Remote Control changes in Audacious

2008-05-08
  • Latest Slackpkg recommendations added
  • Notes about rc.modules symlink, files under etc/modprobe.d

The sections of this HowTo are:
Part 1
Should You Upgrade?
Things You Need to Upgrade
Backup Computer
Getting 12.1 Sources
Create List of Non-Slackware Software
Begin Upgrade
Mass Upgrade
Alternative Mass Upgrade with slackpkg
Kernel Packages

Part 2 - Skip to post #19
LILO and the Fancy Bootsplash
Get Rid of Obsolete Slackware Packages from 12.0
Merge Changes for Config Files
Update Your Graphics Drivers (if needed)
Miscellaneous Fixes
Rebuild/Upgrade any Non-Slackware Packages (as Needed)
Fix Other Random Problems


** Should You Upgrade? **
This should be the first thing you ask yourself. What's in it for you? If you aren't sure, you should read the following docs:
ANNOUNCE.12_1
RELEASE_NOTES
CHANGES_AND_HINTS.TXT

How much work will it take? Well that depends on your system. If your system is in a state of disaster with software installed who knows where then it might be a better idea to backup and install a fresh Slackware 12.1 instead.


** Things You Need to Upgrade **
1) Slackware 12.1 sources – however you can get them: On a CD/DVD, local mirror, from a slackware mirror, network mount, etc
2) Slackware 12.0 installation – This is a HowTo on upgrading from 12.0 after all...

Quote:

Originally Posted by CHANGES_AND_HINTS.TXT
Note that upgrading from a Slackware version earlier than 12.0 is NOT supported at all and will almost certainly lead to breakage.

So, for instance, you can't directly upgrade (safely) from Slackware 9.0 to 12.1. You would probably need to upgrade incrementally to each version. After you're done you need to post a member success story :)

3) Time – This is not a one click upgrade process. It will require that you think. Take your time and do it right the first time. Please read the UPGRADE.TXT and CHANGES_AND_HINTS.TXT before attempting an upgrade! This HowTo does not cover everything included in those files.
4) (Newest Graphics Driver) – It might be a good idea, for instance, to grab the latest Nvidia driver now if you are going to need it later.


** Backup Computer **
This is without a doubt the first thing you should do before making any major system changes.

Quote:

Originally Posted by UPGRADE.TXT
Before you begin, I would strongly recommend making a backup of your
system, or, if not the entire system, at least the /etc directory. You
might find that you need to refer to a few things after the upgrade
process is complete. Back it up, or take your chances.


** Getting 12.1 Sources **
Most people will probably download the full iso, but if you have downloaded some sources from -current previously it might be more worth your while to simply mirror. In my case I had previously used Alien Bob's mirror-slackware-current.sh to create a local mirror of -current and install cds. I had used these to test -current. Before using mirror-slackware-current.sh I recommend you create mirror-slackware-current.conf based upon the options that you want changed from the defaults (see beginning of mirror-slackware-current.sh).

An example mirror-slackware-current.conf
Code:

BUILDER="shadowsnipes <email@youremail.com>"
SLACKROOTDIR="/mnt/path/to/Slackware_Mirror"
ISO="NONE"
EXCLUDEFILE="/home/USERNAME/scripts/mirror-slackware/mirror-slackware-excludes"

My mirror-slackware-excludes contains
Code:

pasture/
source/
slackware/kdei/

Also, if you run the script with -h you can see the runtime arguments available.

After -current became Slackware 12.1 all I had to do was
change my mirror folder names from slackware-current to slackware-12.1 and slackware-current-iso to slackware-12.1-iso.

Then run
Code:

mirror-slackware-current.sh -r 12.1
which mirrors the 12.1 release instead of -current. There were almost no changes between my latest copy of -current and 12.1.

Another tip for using this script: If you have to mirror onto a non-linux partition take out the 'p' from the actual rsync commands in the script so that they don't try to preserve permissions. In my case I only had enough free space on an external NTFS drive, so that is what I used. There are two places I had to change the script, since the sync is done twice. I simply changed a line that looks like
Code:

$RSYNC --delete --delete-excluded -z -rlptD \
to
Code:

$RSYNC --delete --delete-excluded -z -rltD \
Also, for this to work correctly on a non-linux partition you must make sure the user running the script is the owner (mount using the uid option).


** Create List of Non-Slackware Software **
Before you move on into the upgrade you need to properly assess where you are, and in particular, what non-slackware software you have installed.

By far the easiest way to do this is to use slackpkg, which you can find in /extra (for alternate scripts see this thread about Listing Non Stock Slackware Packages). It is recommended that you download the latest stable slackpkg release in order to have all the features used in this HowTo (such as batch and default_answer support). Do note, that the latest release is likely to be a later version than the one in the latest stable Slackware release, so you should add slackpkg to your blacklist to prevent accidentally downgrading it. You should also check the ChangeLog periodically to see if there are any crucial fixes.

Once you install it, be sure to edit blacklist, mirrors, and slackpkg.conf under /etc/slackpkg as desired (set the mirror to one for 12.0 for now). Then to get your list you can simply do
Code:

slackpkg update
slackpkg -dialog=off -batch=on -default_answer=no clean-system > NonSlackwarePackages.txt

NonSlackwarePackages.txt now contains a list of packages that aren't a part of the Slackware tree.

Now is a good time to get rid of any of those non-slackware packages that you no longer need. There is a chance that you will have to rebuild some of your custom packages after the upgrade.

I suggest organizing this list. You might want to, for instance, group some packages together that should be rebuilt or updated. You might also want to add any notes about software installed that is not packaged. It would be a good idea to refer to CHANGES_AND_HINTS.TXT again at this point.


** Begin Upgrade **
As root, go into runlevel 1.
Code:

telinit 1
Mount mirror or install medium.
If the files are on a cd then you will have to mount the other cd(s) in order to install the other packages. In my example, I was using a local mirror on my external hard drive (second partition).
Code:

mount -t ntfs-3g /dev/sda2 /mnt/externalNTFS
cd into the mirror's directory
Code:

cd /mnt/externalNTFS/Slackware_mirror/Slackware-12.1/
upgrade glibc-solibs
Quote:

Originally Posted by UPGRADE.TXT
Upgrade your glibc shared libraries. This is important, or things might go haywire during the first part of the upgrade:

Code:

upgradepkg slackware/a/glibc-solibs-*.tgz
upgrade package utilities
Code:

upgradepkg slackware/a/pkgtools-*.tgz
** Mass Upgrade **
The most basic way to upgrade/install all of the packages is to follow UPGRADE.TXT.
Quote:

Originally Posted by UPGRADE.TXT
3. Upgrade everything else (and install new packages):

upgradepkg --install-new /root/slackware/*/*.tgz

If you wish to upgrade everything except for the KDEI language
packs for KDE (these take a lot of space and can be dealt with
after the main upgrade more quickly and easily), running this
script in the "slackware" directory will do the trick:

#!/bin/sh
for dir in a ap d e f k kde l n t tcl x xap y ; do
( cd $dir ; upgradepkg --install-new *.tgz )
done

Keep in mind that if you are using cds your packages will be split among them, so you will have to use more than one instance of upgradepkg. By the same token, the for loop snippet given above should be altered to reflect which packages sections are actually on the cd.

If you need any non-en_US language packs for KDE please refer to UPGRADE.TXT.

Also, if you don't want to upgrade/install certain packages (ie. blacklist them), then you will have to write a slightly more complicated script, install those package sections manually, or use something like slackpkg to help you.


** Alternative Mass Upgrade with slackpkg **
The trick to using slackpkg to do this is to specify a mount point as the mirror in /etc/slackpkg/mirrors. Since it is just a mount point, it does not matter what kind of device the partition is on as long as you can read it. In my case I had a local mirror on a NTFS partition on an external hard drive. I simply added the following to /etc/slackpkg/mirrors

Code:

cdrom://mnt/externalNTFS/Slackware_mirror/Slackware-12.1/
Of course, you could also specify a regular, non-local, mirror and use slackpkg in the usual way.

Blacklisting packages
It is also important to make sure /etc/slackpkg/blacklist has all the packages listed you don't want to be messed with. For instance, I do special things with my firefox packages so I list mozilla-firefox in the blacklist. Some people like to blacklist the kernel packages.

A keen observer might note that by default a/aaa_elflibs is already blacklisted, while the instructions in UPGRADE.TXT clearly have you installing them. In general, yes, aaa_elflibs should be blacklisted because it will overwrite your core libraries. During a full system upgrade, however, you can upgrade them, but you don't have to. The more important thing to realize is that this package is really only there to make sure you have the core libraries you need in case you do not do a full install of Slackware. As such, if you do a full install/upgrade of Slackware it is likely that you won't need that package anyways. If you aren't sure, simply check if all the files included are already installed (my pkg-sanity script or these other useful scripts may be of some help). In this upgrade, I found no libraries where missing from not installing it. If you do choose install it, for whatever reason, just make sure it is one of the first packages installed (which is probably why it has 'aaa' in the front). Another post on aaa_elflibs

Once your slackpkg configuration is all set, update with the new mirror
Code:

slackpkg update
and install the new packages
Code:

slackpkg install-new
Review the list and deselect any you are not ready to install at this point.

Note: By default, slackpkg will prompt you to handle new config files after installing/upgrading packages. If you need help on this skip down to the "Merge Changes for Config Files" section momentarily.

Upgrade all the packages
Code:

slackpkg upgrade-all
Again, review the list and deselect any you are not ready to install at this point. You might want to look at the kernel section of this HowTo before you upgrade them.

Since I was using fuse and ntfs-3g (both created via slackBuilds from slackBuilds.org) for my external NTFS partition, I decided not to upgrade those packages just to be safe. After all the other packages were installed I copied the packages to my hard drive, unmounted the external drive, stopped fuse (/etc/rc.d/rc.fuse stop), and then upgraded the fuse and ntfs-3g packages using upgradepkg. After that I started fuse and remounted the drive.

If you need any non-en_US language packs for KDE please refer to UPGRADE.TXT.


** Kernel Packages **
Keep in mind that the kernel image packages change the symlinks in /boot for System.map, config, and vmlinuz. This is important to note because a lot of people refer to vmlinuz in their boot manager's configuration. Which ever kernel image package is installed last (usually huge-smp) will have the symlinks pointing to its respective files. So, after upgrading your kernel packages you might have to fix these symlinks and modify your bootloader's configuration (/etc/lilo.conf for LILO) accordingly.

Also, if you ever modified your past kernel sources or built custom kernels, you should take a look in the following places to see if any clean up is necessary:
/usr/src
/lib/modules
/etc/rc.d/rc.modules*
In my case, I had a kernel sources folder and a module folder for a custom 2.6.21.5 kernel I had built that I needed to remove (I no longer intended to use them). I also had a rc.modules file for it that needed to be removed and the rc.modules symlink had to be fixed.

Please note that it is not recommended that you run the huge kernel for daily use (though it may not cause problems). Also, if you have one of those machines that don't work well with a SMP kernel you will need to patch your kernel sources.
Quote:

Originally Posted by CHANGES_AND_HINTS.TXT
As stated earlier, it is recommended that you use one of the generic kernels
rather than the huge kernels
; the huge kernels are primarily intended as
"installer" and "emergency" kernels in case you forget to make an initrd.
For most systems, you should use the generic SMP kernel if it will run,
even if your system is not SMP-capable. Some newer hardware needs the
local APIC enabled in the SMP kernel, and theoretically there should not be
a performance penalty with using the SMP-capable kernel on a uniprocessor

machine, as the SMP kernel tests for this and makes necessary adjustments.
Furthermore, the kernel sources shipped with Slackware are configured for
SMP usage, so you won't have to modify those to build external modules
(such as NVidia or ATI proprietary drivers) if you use the SMP kernel.

If you decide to use one of the non-SMP kernels, you will need to follow the
instructions in /extra/linux-2.6.24.5-nosmp-sdk/README.TXT to modify your
kernel sources for non-SMP usage.
Note that this only applies if you are
using the Slackware-provided non-SMP kernel - if you build a custom kernel,
the symlinks at /lib/modules/$(uname -r)/{build,source} will point to the
correct kernel source so long as you don't (re)move it.

If you decide to use one of the huge kernels anyway, you will encounter
errors like this:
kobject_add failed for uhci_hcd with -EEXIST, don't try to register
These occur because the respective drivers are compiled statically into the
huge kernels but udev tries to load them anyway. These errors should be safe
to ignore, but if you really don't want them to appear, you can blacklist the
modules that try to load in /etc/modprobe.d/blacklist. However, make sure you
remove them from the blacklist if you ever decide to use the (recommended)
generic kernels.

Also, if you need an initrd (you do if running the generic kernel) you will need to set that up. Please see /boot/README.initrd for instructions on this if needed.

Stock Kernels use UTF8 conole now
If you find you have problems with the console after this upgrade you might need to add the following append line for each of your kernel images listed in your /etc/lilo.conf. Personally, I had no such problems, so this was not needed for me.
Quote:

Originally Posted by CHANGES_AND_HINTS.TXT
The new 2.6.24.x kernels default to use a UTF8 console. This might break some
things, so if you prefer the "old" default, you'll need to add this to your
kernel's lilo stanza: append = "vt.default_utf8=0"

Finally. since your kernels changed you will need to run lilo (assuming you are not using another bootloader). Before you do that, make sure your /etc/lilo.conf is still pointing to the correct images, and you can also choose to add a bootsplash to your Lilo prompt. This is covered in the next section.


This HowTo is continued at Post #19

rworkman 05-07-2008 09:04 AM

Excellent post, shadowsnipes; I *really* like that you made many references to the existing documentation instead of trying to rewrite it.

Moderators, please sticky this, as it will surely be useful to people.

There are a couple of points I'd like to make:
1. No idea how I missed the two removed packages in C&H, but thanks for the note on those. I'll try to do better next time :)
2. About slackpkg leaving config files as *.orig, that is a *really* big issue in /etc/modprobe.d/ - the explanation about it is in C&H.

dive 05-07-2008 09:12 AM

Good post.

The slackpkg method is how I did it, but I used a normal mirror in /etc/slackpkg/mirrors. That way you don't need download the iso.

onebuck 05-07-2008 10:09 AM

Hi,

Great post!

pwc101 05-07-2008 04:19 PM

Quote:

Originally Posted by shadowsnipes (Post 3145427)
Create List of Non-Slackware Software
Before you move on into the upgrade you need to properly assess where you are, and in particular, what non-slackware software you have installed.

By far the easiest way to do this is to use slackpkg, which you can find in /extra. Once you install it, be sure to edit blacklist, mirrors, and slackpkg.conf under /etc/slackpkg as desired (set the mirror to one for 12.0 for now). Then to get your list you can simply do
Code:

slackpkg update
slackpkg -dialog=off -batch=on -default_answer=no clean-system > NonSlackwarePackages.txt

NonSlackwarePackages.txt now contains a list of packages that aren't a part of the Slackware tree.

Now is a good time to get rid of any of those non-slackware packages that you no longer need. There is a chance that you will have to rebuild some of your custom packages after the upgrade.

I suggest organizing this list. You might want to, for instance, group some packages together that should be rebuilt or updated. You might also want to add any notes about software installed that is not packaged. It would be a good idea to refer to CHANGES_AND_HINTS.TXT again at this point.

First off, thanks for the great post. I'll be referring it to during my upgrade, although I'm contemplating a clean install, since I haven't done one for a couple of releases, and I'm sure there's all sorts of nastiness lurking in the recesses of /usr... ;)

However, I'm sure I'm just being dense, I can't get slackpkg to generate a list of non-Slackware packages. When I run the second command (after the slackpkg update), I just get the slackpkg usage information output into NonSlackwarePackages.txt. I've edited the relevant files in /etc/slackpkg; is there some more obvious step I'm missing?

shadowsnipes 05-07-2008 10:50 PM

Quote:

Originally Posted by pwc101 (Post 3146088)
However, I'm sure I'm just being dense, I can't get slackpkg to generate a list of non-Slackware packages. When I run the second command (after the slackpkg update), I just get the slackpkg usage information output into NonSlackwarePackages.txt. I've edited the relevant files in /etc/slackpkg; is there some more obvious step I'm missing?

It's not your fault; It's mine. I should have pointed everyone to the newer version of slackpkg, since the one released for 12.0 (slackpkg 2.61) does not have the batch argument yet. It should be safe to install slackpkg 2.70.3 from 12.1's repo instead.

I apologize for the confusion. I'll edit my HowTo promptly.

rworkman 05-07-2008 11:11 PM

Quote:

Originally Posted by shadowsnipes (Post 3146371)
It's not your fault; It's mine. I should have pointed everyone to the newer version of slackpkg, since the one released for 12.0 (slackpkg 2.61) does not have the batch argument yet. It should be safe to install slackpkg 2.70.3 from 12.1's repo instead.

I apologize for the confusion. I'll edit my HowTo promptly.


Point them to slackpkg.org to get the latest stable release (2.70.4 at the moment), and then do two things:
1) add slackpkg to /etc/slackpkg/blacklist so that it doesn't try to "upgrade" itself back to the version in Slackware's /extra
2) keep an eye on slackpkg.org for future updates.

* making a mental note to see about upgrading slackpkg in /patches - 2.70.3 misses the kernel-headers package due to the weird ARCH designation in the full package name.

shadowsnipes 05-08-2008 12:00 AM

Quote:

Originally Posted by rworkman (Post 3146389)
Point them to slackpkg.org to get the latest stable release (2.70.4 at the moment), and then do two things:
1) add slackpkg to /etc/slackpkg/blacklist so that it doesn't try to "upgrade" itself back to the version in Slackware's /extra
2) keep an eye on slackpkg.org for future updates.

* making a mental note to see about upgrading slackpkg in /patches - 2.70.3 misses the kernel-headers package due to the weird ARCH designation in the full package name.

I'm trying to find a good way to make the changes for now. I'm running into problems become I've reached the maximum number of character allowed in a single post (should have split this one up, I suppose). Perhaps the moderators can cut me a little slack for this post, or maybe they can insert a post right after my first that I can edit.

Or perhaps I just need to be more concise :)

Edit:
By the way, I did add the Warning about extra (.orig) files under /etc/modprobe.d. Thanks for the reminder about this.

Edit 2:
I managed to fit in the slackpkg info by taking out the new find commands I added to list and remove .orig files

Edit 3:
I realize now that I could probably split the HowTo up into more than one post similar to how Shilo did in the "this is how I do it all" thread. I could just put a link at the end of the first post linking to the next.

This, of course, is not ideal, but doable. I'll wait to make any major changes like that until
1) I need to add/change enough information to warrant a need to split
2) I've gotten some feedback and know that splitting is the best feasible option

Thanks for the input everybody!

pwc101 05-08-2008 04:57 AM

Quote:

Originally Posted by shadowsnipes (Post 3146371)
It's not your fault; It's mine. I should have pointed everyone to the newer version of slackpkg, since the one released for 12.0 (slackpkg 2.61) does not have the batch argument yet. It should be safe to install slackpkg 2.70.3 from 12.1's repo instead.

I apologize for the confusion. I'll edit my HowTo promptly.

Thanks shadowsnipes and rworkman.

Upgrading to the latest version solved the problem, and revealed I have 147 packages installed that are not part of Slackware... looks like the clean install will take a while to get just how I like it! ;)

Thank <insert favourite deity here> for SlackBuilds!

mm07 05-09-2008 08:22 PM

Hey All,

Getting ready to upgrade 12.0 -> 12.1.
Reading all the posts, and the general consensus is that after the upgrade, I should recompile any custom software I built and installed.
And I should pull down the latest slackbuilds stuff and re-install that as well.


So my question is:
Why should I upgrade at all?? Why not just do a clean build if I'm going to have to reinstall/recompile everything anyway. (I realized the old stuff will work, but I'm talking recommended and best practices)

So I'm undecided...
I want to try an upgrade, but it seems like a little but of a waste of time..
I have a 10G / partition, and store all my data on another partition, so if I have to reinstall my added software anyway, I'm not sure what value an upgrade buy's me.

Thoughts and opinions?
-Mike

shadowsnipes 05-09-2008 08:56 PM

Quote:

Originally Posted by mm07 (Post 3148765)
Hey All,

Getting ready to upgrade 12.0 -> 12.1.
Reading all the posts, and the general consensus is that after the upgrade, I should recompile any custom software I built and installed.
And I should pull down the latest slackbuilds stuff and re-install that as well.


So my question is:
Why should I upgrade at all?? Why not just do a clean build if I'm going to have to reinstall/recompile everything anyway. (I realized the old stuff will work, but I'm talking recommended and best practices)

So I'm undecided...
I want to try an upgrade, but it seems like a little but of a waste of time..
I have a 10G / partition, and store all my data on another partition, so if I have to reinstall my added software anyway, I'm not sure what value an upgrade buy's me.

Thoughts and opinions?
-Mike

Well, you don't have to rebuild all of your custom software. As the HowTo says, you really only need to if something is broken. In my case, I had some broken libraries, so to be safe I went ahead and rebuilt practically all of my libraries. I also rebuilt stuff like WINE because newer versions were out, but I didn't rebuild quite a few packages.

Granted, assuming you save your packages, you could just reinstall them after a clean install. The big deciding factor on whether or not to do an upgrade versus a clean install is all in the little things. Usually there are some little things that, even if you back up all your files, you might forget. It takes a lot of work to restore all those random files, and when you upgrade only some of them might change, and then it is obvious which files you need to merge. However, you can't just restore a bunch of random files after a clean install because you are bound to clobber something. You have to know which ones to restore (unless you are just reinstalling your machine as the same version as your backup- then mass restore of course should work). Therefore, you are more likely to lost some of your settings.

So, in summary, if you are happy with how your system functions, I either recommend you don't do anything or upgrade. You are more likely to be able to keep all of your settings this way.

If you are not happy with your settings, or your system is not organized at all (unpackaged software cluttering up your system) and you want a fresh start, then a clean install is the obvious choice.

Keep in mind that even if you do a clean install, some of this guide may still apply such as getting list of non-slackware software, Miscellaneous Fixes, and the software rebuilding section.

These are just my opinions on the matter, so it might be nice to hear what others say as well.

SqdnGuns 05-09-2008 09:01 PM

Great How-To!

I did a fresh install but this is a most informative thread.

lorton 05-10-2008 08:10 AM

Upgraded using "upgradepkg --install-new *tgz" in a ap d e f k kde n t tel x xap
I didn't check the lilo file & it failed to reboot (My fault).
The ps2 mouse didn't work rc.modules sorted this.
HP device didn't work so I reinstalled it, works fine.
This is my first upgrade as I usually reinstall, I have to say it went very well.
Do you think Windows is as easy to upgrade!
Thanks to all
Lez

T3slider 05-10-2008 06:05 PM

Quote:

Originally Posted by lorton
The ps2 mouse didn't work rc.modules sorted this.
HP device didn't work so I reinstalled it, works fine.

Quote:

Originally Posted by CHANGES_AND_HINTS.TXT
The psmouse module is no longer blacklisted by default; instead, it is loaded
with the imps protocol per /etc/modprobe.d/psmouse -- if you need/want a
different protocol, edit that file. Note that options declarations have
no bearing on *if* a module is loaded - they only affect *how* it is loaded.
In other words, the module should now be loaded automatically (since it's no
longer blacklisted), and the options in /etc/modprobe.d/psmouse are the ones
applied when loading it.

The /etc/modprobe.d/blacklist file has been changed significantly; be sure to
move/merge the /etc/modprobe.d/blacklist.new file in its place. Also, you
must NOT leave a backup of the old blacklist file (such as blacklist.orig)
in /etc/modprobe.d/ -- ALL files in that directory are checked, so if a
module is blacklisted in *any* of them, it won't be loaded.

Your solution (editing /etc/rc.d/rc.modules) is more of a hack than the proper solution. Things have changes since 12.0, and now, instead of the psmouse module being blacklisted by default and subsequently loaded with rc.modules, the psmouse module is NOT blacklisted and is loaded using the options specified in /etc/modprobe.d/psmouse. You should comment the psmouse line in rc.modules out (thus restoring it to its original form) and try getting things working the proper way. If you leave a backup of /etc/modprobe.d/blacklist from your Slackware 12.0 installation in addition to the new /etc/modprobe.d/blacklist file from the 12.1 upgrade, both files will be checked and the psmouse module will be blacklisted (ie it will not be loaded). If there is a /etc/modprobe.d/blacklist.new file, you should overwrite /etc/modprobe.d/blacklist with this file (and I mean overwrite -- again, if you leave a backup of the original file in that directory, it'll still get checked). If that's the case you should also check other .new files in /etc to make sure you merged them all (a crucial part of upgrading from 12.0 to 12.1). If you already merged/overwrote the .new files (including the one in /etc/modprobe.d), then you should make sure to delete the backup of the blacklist file from 12.0.

As for the HP device:
Quote:

Originally Posted by CHANGES_AND_HINTS.TXT
There is a minor problem with the HPLIP and CUPS versions in Slackware 12.1;
hp-toolbox will not work unless LC_ALL is set to a UTF8 locale.
An easy workaround is to start it with "LC_ALL=$LANG.UTF8 hp-toolbox" if
you're not using a UTF8 locale. Also, your user account must be a member
of the "lp" group for hp-toolbox to work properly, and to use the scanner
portion of some (all?) HP print/scan/copy units, you'll need to be a member
of the "lp" group. This is due to the fact that hplip's udev rules set
the device with group "lp" ownership.

That information is also referenced in the original post of this thread. I'm *guessing* that was your problem -- you didn't need to reinstall HP Device Manager (aka Toolbox) to get it to work -- and now you've unnecessarily introduced a third party package that's harder to maintain and may not work 100% reliably. I would recommend reverting to the original package included with Slackware 12.1.

Please make sure to read all of the documentation (especially UPGRADE.TXT and CHANGES_AND_HINTS.TXT) and thoroughly before (and after) upgrading or installing fresh -- it'll give you less headaches and a better system in the end.

[edit]I've just realized that by "reinstalling" HP Device Manager you may have meant reinstalling the 12.1 package (ie there was an error during the upgrade that you fixed), in which case you may have done the right thing. However, I'm not sure how you "reinstalled" the app and therefore will leave my above advice just in case it affects you.[/edit]

vvoody 05-10-2008 09:55 PM

Great job!
I have upgraded to 12.1 following your article:-)

shadowsnipes 05-10-2008 10:05 PM

Quote:

Originally Posted by T3slider (Post 3149474)
Please make sure to read all of the documentation (especially UPGRADE.TXT and CHANGES_AND_HINTS.TXT) and thoroughly before (and after) upgrading or installing fresh -- it'll give you less headaches and a better system in the end.

I probably should have stressed this more strongly in the HowTo. Everyone needs to read these docs for an upgrade, and the CHANGES_AND_HINTS.TXT should be read always.

In fact, I probably read both of those documents three (different) times before writing this HowTo.

The documentation is very informative, and while this HowTo includes most of it, it does not include all of it. This is intentional because:
1) I don't want this HowTo to replace the official documentation
2) This HowTo is meant to be an example of how to use the documentation

Really, it should just be a habit to read at least these two documents for every upgrade/install. I wouldn't mind at all if the setup program for Slackware gave you the option to show you them. This way, more people would likely see and read them.

vvoody 05-10-2008 10:24 PM

I have a problems.

When somebody 'has sent a nudge' to my MSN, the kopete don't play a sound. Before upgrading, it worked well. I open the 'Notification Setting'. And I click the play button of ''Kopete_Received.ogg", but I can not hear the sound. When I play the 'Kopete_Received.ogg' by other apps like mplayer, I hear the sound!

And I found that in the 'Notification Setting', I can play the some other *.ogg.

shadowsnipes 05-10-2008 10:54 PM

Quote:

Originally Posted by vvoody (Post 3149605)
I have a problems.

When somebody 'has sent a nudge' to my MSN, the kopete don't play a sound. Before upgrading, it worked well. I open the 'Notification Setting'. And I click the play button of ''Kopete_Received.ogg", but I can not hear the sound. When I play the 'Kopete_Received.ogg' by other apps like mplayer, I hear the sound!

And I found that in the 'Notification Setting', I can play the some other *.ogg.

Do other KDE sounds work (such as when you login to KDE). If you don't use KDE then try other KDE apps that have sound feedback.

It sounds like a problem with Artsd, or whatever your KDE sound system is set to.

shadowsnipes 05-10-2008 11:16 PM

Part 2 of the HowTo
 
I needed to split the HowTo into two posts in order to be under the maximum character limit per post. I apologize for the inconvenience.
----------------------------------------------------------
Part 2 Sections:
LILO and the Fancy Bootsplash
Get Rid of Obsolete Slackware Packages from 12.0
Merge Changes for Config Files
Update Your Graphics Drivers (if needed)
Miscellaneous Fixes
Rebuild/Upgrade any Non-Slackware Packages (as Needed)
Fix Other Random Problems


** LILO and the Fancy Bootsplash **
To use the bootsplash new to Slackware 12.1 you need to modify your lilo.conf. Slackware's liloconfig has an option to add this for you, and looking at its code you can see what it is doing. It uses a function called boot_bmp() that simply cats the necessary text into lilo.conf, and then it makes sure that the boot message is turned off by commenting that line out.

The beginning of my lilo.conf looks like this (the bold sections are what I manually changed for the bootsplash)
Code:

# LILO configuration file
# generated by 'liloconfig'
#
# Start LILO global section
boot = /dev/hda
#compact        # faster, but won't work on all systems.

# Boot BMP Image.
# Bitmap in BMP format: 640x480x8
  bitmap = /boot/slack.bmp
# Menu colors (foreground, background, shadow, highlighted
# foreground, highlighted background, highlighted shadow):
  bmp-colors = 255,0,255,0,255,0
# Location of the option table: location x, location y, number of
# columns, lines per column (max 15), "spill" (this is how many
# entries must be in the first column before the next begins to
# be used.  We don't specify it here, as there's just one column.
  bmp-table = 60,6,1,16
# Timer location x, timer location y, foreground color,
# background color, shadow color.
  bmp-timer = 65,27,0,255

# Standard menu.
# Or, you can comment out the bitmap menu above and
# use a boot message with the standard menu:
#message = /boot/boot_message.txt

prompt
timeout = 40


** Get Rid of Obsolete Slackware Packages from 12.0 **
The CHANGES_AND_HINTS.TXT files does a good job of listing these.

Quote:

Originally Posted by CHANGES_AND_HINTS.TXT
*** PACKAGE REMOVALS SINCE 12.0 ***

a/util-linux: Removed (replaced by util-linux-ng).
ap/espgs: Removed. This is replaced by ghostscript.
ap/gimp-print: Removed. This is replaced by gutenprint.
e/emacs-info: Removed (this is now included in the monolithic emacs package).
e/emacs-leim: Removed (this is now included in the monolithic emacs package).
e/emacs-lisp: Removed (this is now included in the monolithic emacs package).
e/emacs-misc: Removed (this is now included in the monolithic emacs package).
e/emacs-nox: Removed (this is now included in the monolithic emacs package).
l/libmusicbrainz: Removed.
l/libtunepimp: Removed.
l/mcs: Removed (renamed to l/libmcs).
x/dejavu-ttf: Renamed to x/dejavu-fonts-ttf.
x/xorg-server-xdmx: Removed. This is unmaintained upstream.
extra/ham: Removed due to lack of maintenance.
extra/intel-wlan-ipw3945/*: Removed; support for these devices is included
in the kernel now.
extra/linux-wlan-ng: This does not compile on 2.6.24.x kernels.
extra/ntfsprogs: Upgraded and moved to the AP seires.
extra/xf86-video-ati-6.6.3: Removed.
pasture/gcc-3.4.6/: Removed.

slackpkg is again useful here.
Code:

slackpkg -onoff=off clean-system
will list all of the packages not found in Slackware 12.1 (none selected for removal). Compare this to the list you created earlier and select the obsolete slackware 12 packages (the ones appearing in the slackpkg dialog but not your original list). In my example, I found two obsolete packages not included in the CHANGES_AND_HINTS.TXT file.
Code:

xf86-input-acecad-1.2.0
xf86-input-void-1.1.0


** Merge Changes for Config Files **
Quote:

Originally Posted by UPGRADE.TXT
6. Fix your config files. Some of the config files in /etc are going to
need your attention. You'll find the new incoming config files on
your system with the ".new" extension. You may need to fill these in
with information from your old config files and then move them over.

Regardless of what method you choose to upgrade packages, you will have to devote some of your time deciding if there is anything in the new config files that you need.

slackpkg has a nice feature that will find these files for you and ask what you want to do with them. This can be specifically done by running 'slackpkg new-config'. My personal preference is to Prompt for each one. If I know I didn't modify the old config (perhaps because it is not something I use, such as bluetooth), I simply Overwrite it with the new one. For the ones I know I modified, I choose to Keep them, and I manually merge any changes I want later. For all the ones I am not sure about, I Diff them and make my decision from there.

One annoying thing I noticed with slackpkg, is that if you choose Overwrite, the old config file is backed up with a .orig extension. Since I had already backed up my entire system, I found these files to be clutter and used find to remove them.

Here is a command that will find and list the .orig files under /etc
Code:

find /etc -type f -name \*.orig
And the command that will remove them
Code:

find /etc -type f -name \*.orig -exec rm -v '{}' \;
In particular, you need to be careful about any possible .orig files under /etc/modprobe.d.
Quote:

Originally Posted by CHANGES_AND_HINTS.TXT
The /etc/modprobe.d/blacklist file has been changed significantly; be sure to
move/merge the /etc/modprobe.d/blacklist.new file in its place. Also, you
must NOT leave a backup of the old blacklist file (such as blacklist.orig)
in /etc/modprobe.d/ -- ALL files in that directory are checked, so if a
module is blacklisted in *any* of them, it won't be loaded.

It is important to note that slackpkg did not find all the .new files. I used the following command and came up with these additional files.
Code:

find / -type f -name \*.new
/usr/lib/man.conf.new → Overwrite
/etc/group.new → Remove
/etc/passwd.new → Remove
/etc/shadow.new → Remove
/etc/gshadow.new → Remove
The new group and passwd files would only be useful if there were some new groups or users needed for some new feature, and something like that would have been mentioned in CHANGES_AND_HINTS.TXT. It wasn't so they were removed promptly.


** Update Your Graphics Drivers (if needed) **
You probably need to upgrade to the newest driver if you intend on using hardware acceleration. There are slackBuilds for the driver and kernel module for ATI and Nvidia cards. The slackBuilds also come with a nice script that helps you to switch between your proprietary driver and the built in kernel driver.

ATI SlackBuilds
Nvidia SlackBuilds


** Miscellaneous Fixes **
These are all specified in CHANGES_AND_HINTS.TXT.

Removed /etc/rc.d/rc.scanluns
Quote:

Originally Posted by CHANGES_AND_HINTS.TXT
The provided kernels are now compiled with CONFIG_SCSI_MULTI_LUN=y so there
should be no need for the /etc/rc.d/rc.scanluns script (it should now be
deleted, as it's not included in the sysvinit-scripts package any more).

If this configuration causes a problem with any real SCSI drives, then you
should add this to your kernel's lilo stanza: append = "max_luns=1"

Removed /etc/rc.d/rc.hplip
Quote:

Originally Posted by CHANGES_AND_HINTS.TXT
HPLIP no longer requires daemons to be started at boot time, so any
/etc/rc.d/rc.hplip script should be removed.

Added alias for hp-toolbox to either /etc/profile (system-wide) or ~/.profile (user specific)
Code:

alias hp-toolbox='LC_ALL=$LANG.UTF8 hp-toolbox'
Added my user to lp group
Quote:

Originally Posted by CHANGES_AND_HINTS.TXT
There is a minor problem with the HPLIP and CUPS versions in Slackware 12.1;
hp-toolbox will not work unless LC_ALL is set to a UTF8 locale.
An easy workaround is to start it with "LC_ALL=$LANG.UTF8 hp-toolbox" if
you're not using a UTF8 locale. Also, your user account must be a member
of the "lp" group for hp-toolbox to work properly, and to use the scanner
portion of some (all?) HP print/scan/copy units, you'll need to be a member
of the "lp" group. This is due to the fact that hplip's udev rules set
the device with group "lp" ownership.

Remove obsolete udev files
The two files to remove are located under /etc/udev/rules.d/. I actually did not have a 70-persistent-net.rules file, and it was not created until I removed 75-network-devices.rules, so keep this in mind.
Quote:

Originally Posted by CHANGES_AND_HINTS.TXT
If you have more than one network card and have been using the
75-network-devices.rules file, it is now called 70-persistent-net.rules
(and is generated from 75-persistent-net-generator.rules).
Rules for optical devices are now located in 70-persistent-cd.rules (and
are generated from 75-cd-aliases-generator.rules).
You will need to remove the old rules files (75-optical-devices.rules and
75-network-devices.rules) so that they don't conflict.


As stated above, Slackware's udev implementation will automatically create
rules files for your optical devices and network interfaces
on first boot.
If you add/remove/replace any of this hardware, and/or you "clone" a system
to another hard drive for deployment, you will need to either remove these
two rules files (so that udev will regenerate them to reflect the new or
changed hardware) or edit them accordingly.

Fix slow Xfce Terminal
I noticed after the upgrade that having Terminal open caused workspace switching to be slower and Terminal also resized slower than normal.
This is easily fixed by creating /etc/profile.d/x-fix.sh
Code:

#!/bin/sh
# This should fix slow Xfce Terminal in Slackware 12.1
export XLIB_SKIP_ARGB_VISUALS=1

Do not forget to make it executable.
Quote:

Originally Posted by CHANGES_AND_HINTS.TXT
If you notice Xfce's Terminal and perhaps some other applications being drawn
very slowly in X, then you should try explicitly disabling the Composite
extension in /etc/X11/xorg.conf, or set XLIB_SKIP_ARGB_VISUALS=1 in your
environment prior to starting X. For more information on this, see:
http://bugzilla.xfce.org/show_bug.cgi?id=2792

Computer won't shutdown completely
I did not have this problem, but I added it here because I lot of people did. If you are one of those people (see "Slackware 12.1 - Halt Problem") just add the following append line to your /etc/lilo.conf.
Quote:

Originally Posted by CHANGES_AND_HINTS.TXT
If you have an older machine (with a BIOS released prior to 2001) and it will
not power off on shutdown, try adding this to your kernel's lilo stanza:
append = "acpi=force"

Mouse does not work
I did not have this problem either, but many people seemed to have missed the notes about this in the CHANGES_AND_HINTS.TXT, so I felt it deserved attention here.
Quote:

Originally Posted by CHANGES_AND_HINTS.TXT
The psmouse module is no longer blacklisted by default; instead, it is loaded
with the imps protocol per /etc/modprobe.d/psmouse -- if you need/want a
different protocol, edit that file. Note that options declarations have
no bearing on *if* a module is loaded - they only affect *how* it is loaded.
In other words, the module should now be loaded automatically (since it's no
longer blacklisted), and the options in /etc/modprobe.d/psmouse are the ones
applied when loading it.

So, for instance, if your mouse doesn't use imps then edit /etc/modprobe.d/psmouse so that it uses the correct protocol for your mouse. - Thread related to 12.1 mouse problems

There are more helpful hints in CHANGES_AND_HINTS.TXT. Read it if you haven't already done so!


** Rebuild/Upgrade any Non-Slackware Packages (as Needed) **
Depending on how much and what specific software you have installed, this portion of the upgrade process can take the longest or shortest chunk of time.

Looking at my list I had created previously, I had 75 Non-Slackware packages. Some of these I chose to simply remove and some had become part of slackware (and so were upgraded during the upgrade process). As for the rest of them, if there was a newer version that looked worth my time I chose to upgrade. The others I only upgraded if they were broken.

Fortunately, almost all of my packages were created via slackBuilds (most scripts from slackBuilds.org), so I didn't need to go looking through any repositories.

Since some of the libraries were broken (no surprise) I chose to rebuild them all. A good number of the packages worked fine as is. For the few that didn't, I ran ldd to see what libraries were causing problems and rebuilt/upgraded as needed.

It is important to note that even if you choose to have a fresh installation you will have to do this step of the process.


** Fix Other Random Problems **
This is a separate section because there was no mention of these problems in CHANGES_AND_HINTS.TXT. Some may be specific to my machine as well.

Default 640x480 no longer displays
It seems that the newest Nvidia driver (169.12) for my 7600GS does not correctly handle my monitor (Dell 152FP) at a 640x480 resolution, while my previous driver (100.14.19) on Slackware 12.0 worked fine. The problem is that the driver now by default uses the wrong vertical sync. To fix it, I simply had to specify that 640x480 be used at 75Hz. This is easily done be changed my Modes under the Screen Section (in /etc/X11/xorg.conf) from
Code:

Modes      "1024x768" "800x600" "640x480"
to
Code:

Modes      "1024x768" "800x600" "640x480_75"
The other VESA modes work fine in the VertRefresh range I specified in my Monitor section (60.0 - 75.0) and are auto-detected correctly.


Remote Control for Audacious broken
This is not a problem with Slackware or Audacious, but rather a consequence of the remote control utility not keeping up with Audacious development. In my case, I had been using FoxyTunes and I had created a symlink at /usr/lib/libxmms.so that pointed to /usr/lib/libaudacious.so. This enabled FoxyTunes to work with Audacious by selecting XMMS as the player.

However, this was using Audacious 1.3.2 on Slackware 12.0. On Slackware 12.1, with Audacious 1.5.0, this no longer works because /usr/lib/libaudacious seems to have been removed. If you read the Audacious FAQ, you will see that this change has been in place since version 1.4. The remote control of audacious is now done through audtool (it has a man page), so keep this in mind when using remote control utilities.

For those interested in controlling Audacious through FoxyTunes feel free to post in this FoxyTunes thread. I've contacted the FT developers a couple times about official Audacious support, and I have been told it is on their ToDo list.

Font Problems
Here is a useful thread on font issues in 12.1.

Beautiful Fonts in 12.1 is also worth a read.

If you have Microsoft TTFs installed and the new Liberation fonts are overriding them, then (as root) simply remove the symlink at
/etc/fonts/conf.d/60-liberation.conf and then run fc-cache -f.


Enjoy Slackware 12.1!

vvoody 05-10-2008 11:27 PM

Quote:

Originally Posted by shadowsnipes (Post 3149617)
Do other KDE sounds work (such as when you login to KDE). If you don't use KDE then try other KDE apps that have sound feedback.

It sounds like a problem with Artsd, or whatever your KDE sound system is set to.

I can hear the sound when I login/logout to KDE.

MQMan 05-13-2008 11:40 AM

Apart from the extra effort in understanding what packages have been added in 12.1, is there any reason why I shouldn't leave off the "--install-new" from the mass upgradepkg. I only install the packages I need, instead of everything, and so would rather just upgrade those.

My anticipated steps would be:

Upgrade glibc
Upgrade pkgtools
Remove obsolete packages
Upgrade installed packages
Add new packages, as required.

Does anyone see any issues with this.

Cheers.

shadowsnipes 05-13-2008 12:13 PM

Quote:

Originally Posted by MQMan (Post 3151965)
Apart from the extra effort in understanding what packages have been added in 12.1, is there any reason why I shouldn't leave off the "--install-new" from the mass upgradepkg. I only install the packages I need, instead of everything, and so would rather just upgrade those.

My anticipated steps would be:

Upgrade glibc
Upgrade pkgtools
Remove obsolete packages
Upgrade installed packages
Add new packages, as required.

Does anyone see any issues with this.

Cheers.

No, as long as you are sure you added all the new packages that are needed.

The list of new packages is, of course, included in the Slackware documentation, but you should be able to use slackpkg to create a list as well. Similar to generating a list of non-Slackware software, the following command should (I haven't tested this yet) give you a list of new Slackware software.

Code:

slackpkg -dialog=off -batch=on -default_answer=no install-new > NewSlackwarePackages.txt
Edit:
Just to clarify something, as far as I know, Pat always suggests a full install. Therefore, it could always be possible to have "issues" if you don't have a full install. If you know what you are doing then this shouldn't be a problem.

digger95 05-13-2008 02:06 PM

Excellent guide shadowsnipes! Thanks to everyone for taking the time to write this all down and provide relevant links as well. It's been very helpful. In the end I just decided to back everything up to data-dvd and do a fresh install of 12.1. It just 'feels' cleaner. I'm afraid I'm one of those people who's bothered by the fact that there may be leftover and unused 'stuff' lurking on my machine. LoL. It's a burden.

onebuck 05-13-2008 02:39 PM

Hi,
Quote:

Originally Posted by digger95 (Post 3152094)
Excellent guide shadowsnipes! Thanks to everyone for taking the time to write this all down and provide relevant links as well. It's been very helpful. In the end I just decided to back everything up to data-dvd and do a fresh install of 12.1. It just 'feels' cleaner. I'm afraid I'm one of those people who's bothered by the fact that there may be leftover and unused 'stuff' lurking on my machine. LoL. It's a burden.

Nothing wrong with being careful with ones equipment. You can trim the full install to your needs.

shadowsnipes 05-18-2008 05:45 PM

I just finished updating the HowTo. As some keen observers have noticed, I had to split it into two posts in order to be under the character/post limit. Most changes are in RED, and there's a mini changelog at the top of the original post. If I goofed anything please let me know.

Quote:

Originally Posted by rworkman (Post 3145689)
Moderators, please sticky this, as it will surely be useful to people.

I agree with this. If this thread has helped you please leave a post, so it can be bumped back up where people can see it easier. Hopefully it will be stickied in the future.

shadowsnipes 05-23-2008 10:35 PM

vvoody was very kind in creating a Chinese translation of this HowTo. Please see http://www.linuxsir.org/bbs/thread329142.html for vvoody's translation.

tunkaflux 07-03-2008 05:43 AM

Remote upgrade
 
Hello,

A quick question regarding this HOWTO and remote upgrading.

Is it necessary to go into runlevel 1? Reason for asking is when I go to runlevel 1, most likely ssh will be killed and I will lose the connection to my machine...

Kind regards.

rworkman 07-03-2008 11:02 AM

Quote:

Originally Posted by tunkaflux (Post 3202751)
A quick question regarding this HOWTO and remote upgrading.

Is it necessary to go into runlevel 1? Reason for asking is when I go to runlevel 1, most likely ssh will be killed and I will lose the connection to my machine...

s/most likely//

If you're doing the upgrade remotely, then no, don't go to runlevel 1. Instead, stop as many services as possible and then do the upgrade.

shadowsnipes 07-03-2008 12:09 PM

tunkaflux,

in addition to rworkman's sound advice, I'd recommend that you use a screen session if you are going to be doing the upgrade remotely. That way if you inadvertently lose your connection you can just reconnect to that screen session. You also don't need to be connected the whole time. You can ssh in, start screen, and later during a long mass upgrade command you can detach the session and disconnect from ssh.

Take careful note of what services are running during the upgrade as you will have to restart them after wards (restarting ssh should not kick off active connections).

By they way, I added a minor update to the HowTo (Part II). I just mentioned how to make MS TTFs and Liberation fonts play nice.

niels.horn 07-27-2008 08:20 AM

Just upgraded to 12.1 yesterday. I always prefer to wait a bit so that others can find the first glitches ;-)

Thanks for all the info in this thread - upgrade went without problems.

Just had to reconfigure my vmware (as expected because of the new kernel) and find a new vmware-any-any* package on the internet.

shadowsnipes 07-27-2008 11:17 PM

Quote:

Originally Posted by niels.horn (Post 3227603)
Just upgraded to 12.1 yesterday. I always prefer to wait a bit so that others can find the first glitches ;-)

Thanks for all the info in this thread - upgrade went without problems.

Just had to reconfigure my vmware (as expected because of the new kernel) and find a new vmware-any-any* package on the internet.

I'm glad you had a good upgrade! Are you sure you even needed an any-any-update tarball for your version of vmware? Back when I upgraded to Slackware 12.1 I upgraded to VMware-server-1.0.6-91891 and it did not need an any-any-update. This probably isn't true if you are using a newer custom kernel, however. Also, with vmware I recommend that you move the vmware startup script (SysV style) links in /etc/rc.d/rc5.d/ to /etc/rc.d/rc4.d/ so that they work properly (in case you use runlevel 4).

niels.horn 07-29-2008 05:44 AM

Quote:

Are you sure you even needed an any-any-update tarball for your version of vmware?
Well, I haven't upgraded my vmware yet, still using an older version (1.04.???? I think).
My vmware script is in init.d and is started from rc.local (if [ -x ...] etc.). Any reason to change this setup?

I am still having a minor problem with the font in runlevel 3. I mostly use runlevel 4, but for maintenance etc. I boot in runlevel 3.
Using the console, some international characters won't display correctly (õ / ã), others will (é / ó / á). In X/KDE everything works fine. Since I live in Brazil, some filenames can have these characters.
Tried changing the font with setfont but no satisfactory results up to now.
I guess it has someting to do with the change to UTF?

It's nothing urgent, just something that annoys me a bit :)

shadowsnipes 07-29-2008 10:57 AM

Quote:

Originally Posted by niels.horn (Post 3229636)
Well, I haven't upgraded my vmware yet, still using an older version (1.04.???? I think).
My vmware script is in init.d and is started from rc.local (if [ -x ...] etc.). Any reason to change this setup?

By default vmware installs its init script under /etc/init.d and creates SysV style symlinks in /etc/rc.d/rc?.d. Because of this you don't really have to use Slackware style init scripts for it. You just need to move the symlinks in rc5.d to rc4.d so runlevel 4 will make use of them. However, if you do prefer Slackware init scripts for this, then you should remove all the vmware links under rc?.d and move the init script under init.d to /etc/rc.d/rc.vmware. Also, in addition to calling the start routine in rc.local, you should call a stop routine in rc.local_shutdown (you will probably need to create this file- make it executable of course).

Quote:

Originally Posted by niels.horn (Post 3229636)
I am still having a minor problem with the font in runlevel 3. I mostly use runlevel 4, but for maintenance etc. I boot in runlevel 3.
Using the console, some international characters won't display correctly (õ / ã), others will (é / ó / á). In X/KDE everything works fine. Since I live in Brazil, some filenames can have these characters.
Tried changing the font with setfont but no satisfactory results up to now.
I guess it has someting to do with the change to UTF?

It's nothing urgent, just something that annoys me a bit :)

You probably just need to set your UTF-8 locale. Here is a section of the CHANGES_AND_HINTS.TXT that may be of some help.

Quote:

Originally Posted by CHANGES_AND_HINTS.TXT
Input methods for complex characters (CJK, which is shorthand for Chinese,
Japanese, Korean) and other non-latin character sets have been added. These
input methods use the SCIM (Smart Common Input Method) platform.
The environment variables for SCIM support are set in /etc/profile.d/scim.sh
The requirements for getting SCIM input methods to work in your X session
are as follows:
(1) Use a UTF-8 locale. Look in /etc/profile.d/lang.sh for setting your
language
to (for instance) en_US.UTF-8. As a word of warning: maybe you
should leave root with a non-UTF-8 locale because you don't want root's
commands to be misinterpreted. You can add the following line to your
~/.profile file to enable UTF-8 just for yourself:
export LANG=en_US.UTF-8

(2) Make the scim profile scripts executable. These will setup your
environment correctly for the use of scim with X applications. Run:
chmod +x /etc/profile.d/scim.*
(3) Start the scim daemon as soon as your X session starts. The scim daemon
must be active before any of your X applications. In KDE, you can add a
shell script to the ~/.kde/Autostart folder that runs the command
"scim -d". In XFCE you can add "scim -d" to the Autostarted Applications.
If you boot your computer in runlevel 4 (the graphical XDM/KDM login)
you can simply add the line "scim -d" to your ~/.xprofile file.
This gives you a Desktop Environment independent way of starting scim.
When scim is running, you will see a small keyboard icon in your system tray.
Right-click it to enter SCIM Setup. In 'Global Setup' select your keyboard
layout, and you are ready to start entering just about any language
characters you wish! Press the magical key combo <Control><Space>
in order to activate or deactivate SCIM input. The SCIM taskbar in the
desktop's corner allows you to select a language. As you type, SCIM will show
an overview of applicable character glyphs (if you are inputting complex
characters like Japanese).

/etc/profile.d/lang.sh has some nice comments as well.

niels.horn 07-29-2008 10:16 PM

Quote:

Originally Posted by shadowsnipes (Post 3229934)
By default vmware installs its init script under /etc/init.d and creates SysV style symlinks in /etc/rc.d/rc?.d. Because of this you don't really have to use Slackware style init scripts for it. You just need to move the symlinks in rc5.d to rc4.d so runlevel 4 will make use of them. However, if you do prefer Slackware init scripts for this, then you should remove all the vmware links under rc?.d and move the init script under init.d to /etc/rc.d/rc.vmware. Also, in addition to calling the start routine in rc.local, you should call a stop routine in rc.local_shutdown (you will probably need to create this file- make it executable of course).

Ok, understood. I am so used to the "Slackware" way of doing things that I put it in the rc.local script. I did clean up the rc.? scripts. I might study this SysV style of starting things. It seems that it may have some advantages like starting some scripts only in runlevel 3, others only in runlevel 4. Is this correct?

Quote:

Originally Posted by shadowsnipes (Post 3229934)
You probably just need to set your UTF-8 locale. Here is a section of the CHANGES_AND_HINTS.TXT that may be of some help.

/etc/profile.d/lang.sh has some nice comments as well.

Well, this part is a bit more complicated... But I solved my problem today.
Since I exchange files with a Windows notebook (sorry... from the company I work for... :( ), I use the ISO-8859-1 character set (export LANG=pt_BR.ISO8859-1 in /etc/profile.d/lang.sh) to copy files in both directions, maintaining all special characters in the filenames. I have this setup since Slackware 10.x I think, including some Samba shares etc. Changing completely to UTF seems complicated now, since I have tons of files with names I won't be able to list.
What worked for me is the following:
Code:

#!/bin/bash
kbd_mode -a
echo -ne '\033%@'
setfont LatArCyrHeb-16

Where:
  • kbd_mode -a --> sets the keybord to ASCII mode (as oposed to UTF mode)
  • echo -ne '\033%@' --> resets the tty configuration
  • setfont LatArCyrHeb-16 --> sets a nice font with all the special characters I need
I put this in a small script I start from /etc/rc.d/rc.local so my console works fine without affecting my X/KDE settings.

By the way, I do read the CHANGES_AND_HINTS.TXT file ;) But no offense taken! And thanks for all the help until now.

shadowsnipes 07-30-2008 12:53 AM

Quote:

Originally Posted by niels.horn (Post 3230464)
Ok, understood. I am so used to the "Slackware" way of doing things that I put it in the rc.local script. I did clean up the rc.? scripts. I might study this SysV style of starting things. It seems that it may have some advantages like starting some scripts only in runlevel 3, others only in runlevel 4. Is this correct?

You can actually do all the same stuff with Slackware style init scripts, so it really just boils down to what you like best. For instance, if you want runlevel 3 specific actions then you could create a rc.3 script to handle it. inittab might run this file out of the box, but if it doesn't for some reason then you could always check the runlevel (use runlevel command) in rc.M and then call rc.3 if it's needed. For runlevel 4 specific actions there already is a rc.4 file.

At first glance, SysV style scripts may be seem more suited if you need to have some runlevel-specific funky order to shutdown or start services, but you can easily accomplish this by hacking the Slackware init scripts as well (and without learning the link naming conventions for SysV). So, again, it all boils down to preference. That being said, I definitely recommend you become familiar with SysV scripts, because pretty much every distro uses them.

Edit:
I thought I would add (since the thread is about upgrading) that one disadvantage of hacking the Slackware init scripts versus using provided SysV scripts is that you have to spend more time merging changes from the upgrade. Of course, using rc.local, rc.local_shutdown, and rc.netdevice would not require any script hacking, and they are usually sufficient for most needs.

niels.horn 07-30-2008 06:39 AM

Quote:

Originally Posted by shadowsnipes (Post 3230573)
That being said, I definitely recommend you become familiar with SysV scripts, because pretty much every distro uses them.

For me, the essence of Linux is having options to choose from :)
Any suggestion on where to find some not-too-basic documentation on SysV scripts? I mean, I don't need to learn what's a runlevel or how to write a shell script... But I would like to understand the logic of SysV scripts - what calls what, in which order, etc.
Thanks again!

shadowsnipes 07-30-2008 08:38 AM

Quote:

Originally Posted by niels.horn (Post 3230829)
For me, the essence of Linux is having options to choose from :)
Any suggestion on where to find some not-too-basic documentation on SysV scripts? I mean, I don't need to learn what's a runlevel or how to write a shell script... But I would like to understand the logic of SysV scripts - what calls what, in which order, etc.
Thanks again!

http://www.debian.org/doc/debian-pol...tml#s-sysvinit

For Slackware you might also want to check out chkconfig.

niels.horn 08-09-2008 10:04 PM

Thanks for the link to the explanation of SysV scripts.

In the meantime, today I upgraded my third Slackware 12 machine to 12.1

It is an 'older' desktop (PIII-600MHz board) and I had some problems for which I would like to share the solutions.

First of all I ended up without a working network interface. After checking the logs (/var/log/messages) I found out all the IRQs were mixed up and there were conflicts between the NIC, video and sound card.
Solved it adding the following line to lilo.conf:
Code:

append = "acpi=force"
Second problem was that my mouse had stopped working.
This was a silly problem and I remembered vaguely reading something somewhere... It was in the CHANGES_AND_HINTS.TXT:
Code:

Also, you must NOT leave a backup of the old blacklist file (such
as blacklist.orig) in /etc/modprobe.d/ -- ALL files in that directory are
checked, so if a module is blacklisted in *any* of them, it won't be
loaded.

I had a blacklist.orig file there that stopped my mouse from working... Serves me well... Should have read the xxxx manual :study: again, even the third time :D

rworkman 08-09-2008 10:33 PM

Niels,

Glad you got everything worked out.

Are you going to attend the SlackShow in Sao Paulo this month?

niels.horn 08-10-2008 06:58 AM

I'll try to go!
I actually live in Rio, about 500km from São Paulo. But I'll be in São Paulo on the 21st so I might stay for another day. The agenda looks interesting, especially the one about Netfilter/IPtables the one about 'encrypted systems' (Alien_Bob).

agentc0re 08-22-2008 03:04 PM

Just wanted to say good job on the How To! Thanks for take the time to write it all up. Since it was never stickied, have you placed all this info on a webpage or something yet by chance? Not that this would ever get lost but it would be nice to have it all on one page and then a nice quick link in a signature for future reference.

shadowsnipes 08-22-2008 08:34 PM

Quote:

Originally Posted by agentc0re (Post 3256337)
Just wanted to say good job on the How To! Thanks for take the time to write it all up. Since it was never stickied, have you placed all this info on a webpage or something yet by chance? Not that this would ever get lost but it would be nice to have it all on one page and then a nice quick link in a signature for future reference.

Thank you for your appreciation :) I have not put this HowTo on a personal web page as of yet. I may do so in the future if I decide to maintain a personal site. The main reason I decided to post it here instead of the wiki was so that the contents would show up in the LQ forum searches. I believe that more people search LQ threads than the Wikis. Plus, it is nice for there to be a place for discussion.

Hopefully when future Slackware versions come out I will have time to generate similar threads (or web pages).

I updated my signature per your request ;)

agentc0re 08-22-2008 08:44 PM

Quote:

Originally Posted by shadowsnipes (Post 3256607)
I updated my signature per your request ;)

Ha ha, i wasn't requesting that you do it. I was going to throw it in mine but i held off just in case you had a webpage with it looking a little cleaner, since it's broken up a bit in the post. :)

harryhaller 08-23-2008 03:20 AM

Rate this thread
 
Quote:

Just wanted to say good job on the How To! Thanks for take the time to write it all up. Since it was never stickied, have you placed all this info on a webpage or something yet by chance? Not that this would ever get lost but it would be nice to have it all on one page and then a nice quick link in a signature for future reference.
Perhaps if we rated it, it would become a sticky?

Click "Rate Thread" just above the top post on the right and give it the five stars it deserves. I have.:)

NightSky 01-04-2009 07:56 PM

The Slackware Upgrade Time Saver
 
Thank you, thank you...to Shadowsnipes your are a gentle person and a scholar as is Rob....Plez dear moderator sticky this most important and useful post ;)


All times are GMT -5. The time now is 09:55 PM.