This file documents the instructions for upgrading to Slackware 13.37, the packages added, removed, renamed, and/or split during the development cycle from Slackware 13.1 through 13.37, and some potential "gotchas" that users can avoid by arming themselves with a little knowledge. *** INSTRUCTIONS FOR UPGRADING FROM 13.1 *** Follow the instructions detailed in the UPGRADE.TXT located in this directory. Note that upgrading from a Slackware version earlier than 13.1 is NOT supported at all and will most likely not work. *** PACKAGE ADDITIONS SINCE 13.1 *** a/btrfs-progs a/gdisk a/libcgroup a/lrzip a/mcelog a/util-linux (renamed from util-linux-ng) ap/ddrescue ap/lxc ap/moc d/slacktrack (moved from /extra) d/yasm (moved from /extra) kde/libktorrent l/gdk-pixbuf2 l/libdbusmenu-qt l/libelf l/libmpc l/liboggz l/libpcap (split from tcpdump package) l/libplist l/libsndfile l/phonon-mplayer n/ca-certificates n/idnkit n/iptraf-ng (replaced iptraf) n/iwlwifi-100-ucode n/iwlwifi-6xxx-ucode n/rfkill x/radeon_ucode x/xdg-user-dirs x/xf86-video-nouveau xap/xaos extra/google-chrome/* /testing/ includes the following: 2.6.38.4 kernel mesa-7.10.2 libdrm-2.4.25 xf86-video-nouveau-git_20110417_8378443 *** PACKAGE REMOVALS SINCE 13.1 *** a/util-linux-ng (renamed to util-linux) kde/guidance-power-manager l/eggdbus n/iptraf (replaced by iptraf-ng) x/libXTrap x/libXprintAppUtil x/libXprintUtil x/libxkbui x/rstart x/trapproto x/xf86rushproto x/xfindproxy x/xfwp x/xplsprinters x/xprehashprinterlist x/xproxymanagementprotocol x/xsetmode x/xsetpointer x/xtrap extra/kde3-compat/ *** OTHER NOTABLE CHANGES AND HINTS *** The Slackware installer 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.37.6-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 with 13.1, 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. User accounts with permission to use network devices, such as with the wicd package in /extra, should be in the "netdev" group. 4. User accounts with permission to use devices that "dial out" or connect over a serial port (serial console connections to plug computers, sync with a palm device, etcetera) will need to be in the "dialout" group. 5. 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. 6. 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/ The version of Xorg in Slackware 13.37 will not (in most cases) require an /etc/X11/xorg.conf file. Input hotplugging is no longer done using hal; instead, it now uses udev for input device detection and keyboard mapping. /usr/share/X11/xorg.conf.d/ is the "packaged" configuration directory; all files ending with ".conf" in this directory are used by the X server unless there is an identically-named file in the local sysadmin directory. The local sysadmin config directory is /etc/X11/xorg.conf.d/ - all files ending with ".conf" in this directory are parsed. There are several default config files in /usr/share/X11/xorg.conf.d/: * 10-evdev.conf a "catchall" file for input devices using the evdev driver; this should work for most hardware in the absence of a better driver * 50-synaptics.conf overrides the earlier 10-evdev.conf file and uses the synaptics driver for all touchpads * 50-wacom.conf overrides the earlier 10-evdev.conf file and uses the wacom driver for Wacom tablets * 90-keyboard-layout.conf this sample ("normal" en layout) keeps the "old" default of allowing Zap'ing the Xserver. If you need to modify any of these defaults, then copy the relevant file from /usr/share/X11/xorg.conf.d/ to /etc/X11/xorg.conf.d/ and edit the copy. You can still create an xorg.conf file if you wish, or you can create some minimal xorg.conf snippets with only the specific contents that you wish to override (as an example, to use a binary-only video driver) as separate files in the /etc/X11/xorg.conf.d/ directory. Regardless of your chipset (though it seems more common with intel), if KDE crashes on startup, try disabling the Composite extension (which will also disable all of the fancy desktop effects). Place the following content in a file at /etc/X11/xorg.conf.d/disable-composite.conf: Section "Extensions" Option "Composite" "Disable" EndSection Now that KMS (Kernel Mode Setting) for graphics cards has (mostly) stabilized, it is enabled by default for intel, ati, and nvidia graphics chipsets. It is possible to disable it use "nomodeset" as a kernel append in lilo.conf, but Xorg will not work at all on intel and ati chips if you do that. If you want to change the resolution of the KMS console, that can be done with something like this as a kernel append in lilo.conf: append="video=1024x768" Speaking of lilo.conf and KMS, make sure you use either vga=normal or vga=extended -- some of the framebuffers don't like KMS very much... The (formerly) patented bytecode interpreter is now enabled in the freetype package, so your fonts might look a bit different. If this is undesirable, you can restore the previous default with this line: # ln -s ../conf.avail/10-autohint.conf /etc/fonts/conf.d/ 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. 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 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 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" If you have a Thinkpad T400 or T500, you probably want to append "pci=reboot" to the kernel boot parameters. For more information about this issue, see https://encrypted.google.com/search?hl=&q=t400+%22pci%3Dreboot%22