path: root/CHANGES_AND_HINTS.TXT

This file documents the instructions for upgrading to Slackware 13.1, the 
packages added, removed, renamed, and/or split  during the development cycle 
from Slackware 13.0 through 13.1, and some potential "gotchas" that users 
can avoid by arming themselves with a little knowledge.


*** INSTRUCTIONS FOR UPGRADING FROM 13.0 ***

Follow the instructions detailed in the UPGRADE.TXT located in this
  directory.  You will also need to read the "LIBATA SWITCHOVER" section
  later in this document.

Note that upgrading from a Slackware version earlier than 13.0 is NOT 
  supported at all and will most likely not work.


*** PACKAGE ADDITIONS SINCE 13.0 ***

a/cpufrequtils
a/usb_modeswitch
ap/mpg123 (moved from /extra)
ap/powertop
kde/kdepim-runtime
kde/kopete-cryptography
kde/oxygen-icons
kde/polkit-kde-1
kde/polkit-qt-1
l/ConsoleKit
l/QScintilla
l/attica
l/ebook-tools
l/eggdbus
l/fftw
l/giflib
l/gst-plugins-good
l/hunspell
l/libdiscid
l/libiodbc
l/liblastfm
l/libnotify
l/libsamplerate
l/v4l-utils
l/loudmouth
l/notify-python
l/polkit
l/polkit-gnome
l/shared-desktop-ontologies
l/system-config-printer
l/virtuoso-ose
n/epic5 (replaces epic4)
n/iwlwifi-1000-ucode
n/iwlwifi-6000-ucode
n/bluez
n/obex-data-server
n/obexfs
n/rt2860-firmware
n/rt2870-firmware
x/xf86-input-wacom
x/xf86-video-nouveau-blacklist
xap/blueman
xap/geeqie
xap/xfce4-notifyd
/testing/btrfs-progs


*** PACKAGE REMOVALS SINCE 13.0 ***

a/device-mapper (part of lvm2 now)
a/loadlin (mostly unneeded now)
ap/cupsddk (part of cups now)
ap/mpg321 (replaced by mpg123)
l/libgtkhtml (obsolete)
l/libungif (replaced by giflib)
n/bluez-libs (part of bluez now)
n/bluez-utils (part of bluez now)
n/epic4 (replaced by epic5)
x/lbxproxy (obsolete)
x/liblbxutil (obsolete)
x/proxymngr (obsolete)
x/xf86-input-citron (does not compile)
x/xf86-input-elographics (does not compile)
x/xf86-input-fpit (does not compile)
x/xf86-input-hyperpen (does not compile)
x/xf86-input-mutouch (does not compile)
x/xf86-video-newport (unneeded)
x/xf86-video-xgixp (at least partially breaks X)
xap/gqview (replaced with geeqie)
kde/mplayerthumbs (part of kdemultimedia now)
extra/mpg123 (moved to AP series)


*** LIBATA SWITCHOVER ***

The "old" ide subsystem in the the linux kernel is now deprecated in favor
  of the newer libata subsystem, and this affects the naming of device nodes
  for almost all types of disk drives -- hard drives in particular will now
  have an "sd" named node.  The following information should allow you to
  handle that changeover gracefully.

  1. Upgrade the kernel and kernel-modules packages normally.
     
  2. Edit /etc/fstab to reflect the change from hd* to sd*.
    
     If you have multiple SATA devices, and especially if you have some of
     both hd* and sd* devices present already, then you're basically going
     to be playing a guessing game right now, and you probably want to
     consider using some of the persistent symlinks in the /dev/disk/by-*/
     directories instead of raw device nodes -- for example, the links in
     /dev/disk/by-id/ should always point to the same device, even if its
     raw device node changes from e.g. sda1 to sdc1 or some such across
     reboots.
 
     * If you are using one of the generic kernels (requiring an initrd),
       then use the sd* name for the root device when creating the image.
     
     * You will almost surely want to remove the udev rules file for cdrom
       devices (it will be regenerated on the next boot with correct
       information reflecting the new libata stuff):  
         # rm -f /etc/udev/rules.d/70-persistent-cd.rules 

     * Speaking of optical devices, if you have multiple disk drives and an
       optical drive using the old ide subsystem, then be aware that the
       optical drive will get a /dev/sr* name instead of /dev/sd* -- this is
       relevant because you might see something like this (if your optical
       drive is currently /dev/hdb):
 
         Old Name --> New Name 
         /dev/hda     /dev/sda
         /dev/hdb     /dev/sr0
         /dev/hdc     /dev/sdb
 
  3. Run lilo.  Note that you have made no edits at all to it yet, unless
     you needed to edit it for the new kernel.  Specifically, do not make
     any changes with respect to hd* --> sd*.
 
  4. Reboot.  At the lilo prompt, press <TAB> and add an append for the
     real root device (which will no longer be /dev/hd*).  For example, if
     the old root device was /dev/hda1, and it will now be /dev/sda1, and
     the name of your kernel image is "Linux" then you would do this:

       Linux root=/dev/sda1

  5. Once the system comes back up, then fix /etc/lilo.conf, run lilo, and 
     reboot again to be sure everything is correct.


*** OTHER NOTABLE CHANGES AND HINTS ***

The Slackware installer now uses udev to initialize your hardware, including 
  the network interface card(s).  This has positive consequences for network 
  installations (using NFS, FTP, HTTP or SMB).  You no longer have to run the 
  'pcmcia' and 'network' scripts prior to running 'setup' - the network 
  interface will be created and intialized by udev.  If a DHCP server is 
  found on your local network, the setup program will let you choose between 
  automatic configuration of your network interface using DHCP or specifying 
  a static IP address.  Using udev, the commandline for fully unattended 
  configuration and startup of the dropbear SSH server has changed slightly. 
  Suppose you want to boot the 'hugesmp' kernel, use DHCP for interface eth0,
  and you have a us-english keyboard layout: the commandline to auto-start 
  the SSH daemon in the installer would become: 
      hugesmp.s kbd=us nic=auto:eth0:dhcp
  Note: if you do not want to use udev, the "auto" keyword in that example 
  commandline must be replaced with the actual name of the network module for 
  your card.  If you do not want to use udev, you must add the parameter 
  "noudev" to the command line that boots the Slackware installer, and the
  original ("old") Slackware hardware configuration scripts will be used.
  Also note that this is not supported...

Use one of the provided generic kernels for daily use.  Do not report
  bugs until/unless you have reproduced them using one of the stock 
  generic kernels.  You will need to create an initrd in order to boot
  the generic kernels - see /boot/README.initrd for instructions.
  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.33.4-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.

As usual, there are changes in udev packaging that need mentioning...
  As with 13.0, the system udev rules now reside in /lib/udev/rules.d/ 
  instead of /etc/udev/rules.d/ in older versions.  There should never be 
  a reason to edit anything in /lib/udev/rules.d/, so if you think you have 
  a case where this is required, either you're wrong or it needs to be 
  addressed in the upstream source.  However, you can override default rules 
  by placing one with an identical name inside /etc/udev/rules.d/  The rules 
  files in /etc/udev/rules.d/ are still intended to (maybe) be edited as 
  needed by local system administrators, and as such, the rules for optical 
  and network devices will still be placed there.

Speaking of udev, pay particular attention to 70-persistent-net.rules and
  70-persistent-cd.rules in /etc/udev/rules.d/ -- these two are automatically
  generated by the system.  If you remove, add, and/or replace some hardware
  (specifically network cards and/or optical drives) in a machine, you will
  probably need to edit one or both of the rules files mentioned above.

HP multifunction printer/scanners require that your user account be a member 
  of the "lp" group for hp-toolbox to work properly, and to use the scanner
  portion of some (all?) units, you'll need to be a member of the "lp" group.
  This is because hplip's udev rules set the device with group "lp" ownership.

HAL is not new anymore, but here are a few notes related to it:
  1. User accounts with permission to mount removable devices and manipulate
     bluetooth devices must be in at least the "plugdev" group.
  2. User accounts with permission to do power-management tasks, such as 
     suspend, hibernate, reboot, and shutdown, via HAL methods should be in
     the "power" group.
  3. HAL will honor settings in /etc/fstab if a device is present there, so
     you could technically have removable devices defined in /etc/fstab, but 
     if the fstab settings do not allow normal users to mount them (with the
     "user" or "users" option), then HAL/dbus will not allow them to be 
     mounted either.  In other words, for example, if your fstab line for the
     cdrom/dvd drive includes the "owner" option, you will not be able to 
     mount it as a normal user.
  4. If you find a need for modified fdi files, those should be placed in the
     relevant directories in /etc/hal/fdi/ instead of /usr/share/hal/fdi/

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
  We've also gotten a report of some other things (such as VirtualBox) that
  might benefit from this.

Speaking of Xorg, the version of Xorg shipped with Slackware 13.1 will not
  (in most cases) require an /etc/X11/xorg.conf file at all.  Configuration of
  input devices and such is handled by HAL, and the X server autoconfigures 
  everything else.  You can still create an xorg.conf file if you wish, or you
  can create a minimal xorg.conf with only the specific contents that you wish
  to override (as an example, to use a binary-only video driver). 
  Due to removed drivers and other such changes, it's quite possible that your
  old xorg.conf will not work correctly with this version of Xorg.

If you need to use a non-US keyboard layout, then copy the file located at
  /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi to /etc/hal/fdi/policy
  and edit it to suit your needs.  Have a look at the contents of that file
  for an example and more information.  If you prefer to do this the "old" way
  using /etc/X11/xorg.conf, then you can use "X -configure" or "xorgsetup" to
  generate an xorg.conf, then add the following lines to the "ServerFlags"
  section to disable input device hotplugging via HAL:
    Option   "AllowEmptyInput"     "false"
    Option   "AutoAddDevices"      "false"
    Option   "AutoEnableDevices"   "false"
  This is also relevant if you prefer to disable HAL completely for whatever
  reason.

If you are using input hotplugging via HAL and a synaptics touchpad, then you 
  might need to copy /usr/share/hal/fdi/policy/10osvendor/11-x11-synaptics.fdi
  to /etc/hal/fdi/policy/ and edit it to suit your needs.  You can also use
  synclient(1) to make changes "on the fly."  
Also note that any touchpads that include actual buttons as part of the 
  touchpad hardware will not have tap-to-click enabled by default.

In KDE, you can access the "System Settings" menu in Administrator mode by 
  running "kdesu systemsettings" as your normal user.

If you see errors like this related to alsa during boot:
    Loading ALSA mixer settings:  /usr/sbin/alsactl restore
    Unknown hardware: "HDA-Intel" ...
    Hardware is initialized using a guess method
    /usr/sbin/alsactl: set_control:1256: failed to obtain info for control #31
    /usr/sbin/alsactl: set_control:1256: failed to obtain info for control #32
 then you will need to remove /etc/asound.state, reboot (so that it is 
 regenerated with correct information), and reset the volume and such.

If you see warnings like this when logging in:
    configuration error - unknown item 'DIALUPS_CHECK_ENAB' (notify administrator)
    configuration error - unknown item 'NOLOGIN_STR' (notify administrator)
  then you need to move/merge /etc/login.defs.new with /etc/login.defs (and
  also move/merge the other .new files that you have obviously neglected).

If you are using a KVM switch, you might experience problems with the mouse
  when switching from one system to another.  If so, you probably need to be
  using the imps protocol for the psmouse driver, and that's a simple edit:
  uncomment the following line in /etc/modprobe.d/psmouse.conf:
    #options psmouse proto=imps
  Next, unload and reload the psmouse module (do this as root):
    modprobe -r psmouse ; modprobe psmouse

If you have set up an encrypted root partition, you will need to have access 
  to your keyboard in order to type the passphrase.  This may require you to 
  add the uhci-hcd and usbhid modules to your initrd image if you have a USB 
  keyboard.  Also note that if you are using a non-US keyboard, you can use the
  '-l' parameter to the 'mkinitrd' command in order to add support for this
  keyboard to your initrd.

If you have permission errors when attempting to burn a cdrom or dvd image,
  such as the following:
    /usr/bin/cdrecord: Operation not permitted. Cannot send SCSI cmd via ioctl
  then cdrecord almost certainly needs root privileges to work correctly.
  One potential solution is to make the cdrecord and cdrdao binaries suid root,
  but this has possible security implications.  The safest way to do that is 
  to make those binaries suid root, owned by a specific group, and executable
  by only root and members of that group.  For most people, the example below
  will be sufficient (but adjust as desired depending on your specific needs):
    chown root:cdrom /usr/bin/cdrecord /usr/bin/cdrdao
    chmod 4750 /usr/bin/cdrecord /usr/bin/cdrdao
  If you don't want all members of the 'cdrom' group to be able to execute the
  two suid binaries, then create a special group (such as 'burning' which is
  recommended by k3b), use it instead of 'cdrom' in the line above, and add
  to it only the users you wish to have access to cdrecord and cdrdao.

If you have compilation errors that look something like this:
  /usr/include/asm-generic/fcntl.h:117: error: redefinition of 'struct flock'
  /usr/include/bits/fcntl.h:142: error: previous definition of 'struct flock'
  /usr/include/asm-generic/fcntl.h:140: error: redefinition of 'struct flock64'
  /usr/include/bits/fcntl.h:157: error: previous definition of 'struct flock64'
  See the following link for some pointers on fixing it:
    http://www.mail-archive.com/blfs-dev@linuxfromscratch.org/msg08942.html

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).

If you are using the pinentry-gtk2 interface (for entering passphrases with
  gpg-agent), be aware that there is a bug in the way scim-bridge and the
  pinentry-gtk2 interact.  The result is that keyboard input does not register
  with pinentry-gtk2.  For the time being, either change the /usr/bin/pinentry
  symlink to use the qt or curses frontend, or don't use scim.

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"