diff options
Diffstat (limited to 'slackware64-current/CHANGES_AND_HINTS.TXT')
| -rw-r--r-- | slackware64-current/CHANGES_AND_HINTS.TXT | 363 |
1 files changed, 363 insertions, 0 deletions
diff --git a/slackware64-current/CHANGES_AND_HINTS.TXT b/slackware64-current/CHANGES_AND_HINTS.TXT new file mode 100644 index 000000000..2f980b8f3 --- /dev/null +++ b/slackware64-current/CHANGES_AND_HINTS.TXT @@ -0,0 +1,363 @@ +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"
+
|