Sarge to Etch upgrade report
For the longest time, I had been annoyed that shells in a konsole did not
execute startup files. The last time this worked was in woody. Recently
I did some testing and found that it wasn't pdksh. Bash had the same
problem. No matter what I did with .profile or .bashrc files.
I'm happy to report that after the upgrade to Etch (KDE 3.5) this works
properly. Of course, before I could always manually do ". ~/.profile",
but it became extremely annoying as I tend to have about 10 open konsoles
with anywhere from 3 to 6 tabs each. Once done manually, though, the
shell remembers the current directory and displays it at my custom prompt.
During extended tests, I found that at some point I could get the startup
file to be executed, but only when creating a new konsole. Automatic
restoration of a session would not do it (in KDE 3.3/sarge). Under
KDE 3.5/etch, everything works fine.
Furthermore, I found this little gem out there that I put in the .profile,
that contains all my customizations and is called from .bashrc:
if test "$DISPLAY" ; then
export PROMPT_COMMAND='echo \
-ne "\033]30;`echo $PWD | sed \
-e "s/^.*\(.\{20\}\)$/\1/"
`\007\033]31;$PWD\007"'
fi
This puts the current directory path, up to 20 characters in the
konsole tabs and the window frame. Extremely useful to find a
particular shell.
In other aspects of the upgrade, all I had to do was to replace "sarge"
with "etch" in /etc/apt/sources.list and then type in aptitude "U" and
"g g g g g..." AFTER I had gone through the list of packages that it
wanted to remove to put them back with "+". Selecting the meta-package
kde took care a huge chunk of those. Aptitude is apparently smart enough
to install in batches only what it can, due to dependencies. Kudos to
the developers.
The handling of configuration files was great too. I ended up taking the
option to show the differences and then adding my own changes to the new
files since they were much more minor than what the developers had changed,
and I wanted to have those latest changes. I noticed though that the
.bashrc user files were not touched or even apparently known to the upgrade
scripts. From another from-scratch installation, I realized that the .bashrc
that gets installed in a new user's directory is much more involved than
what came with sarge. Should this be reported as a bug?
I'm running a locally compiled kernel on the machine in question (2.6.16)
and that wasn't touched during the upgrade. Alsa apparently was upgraded
and that solved another long-standing problem. The machine is an old
Thinkpad 600E and though sound worked briefly a long time ago, it didn't
until this upgrade.
Problems encountered:
On the first reboot, I got errors about php. So I installed php and
libapache2-mod-php4 manually. I also use unison to back up/keep my
user directories synchronized and the upgrade process installed a
newer version. After that, I couldn't talk to the other machine. Unison
requires identical versions at both ends. Luckily, the distribution
maintainers have kept the old (used in sarge) version also in the etch
package list, so it was a simple matter to uninstall the new and reinstall
the old.
Finally a question: Sarge used hotplug. Etch uses udev. Already in sarge
there were so many files where blacklisted modules could be listed that
I was never sure what files were being read and used. That was probably
part of the reason why sound didn't work as it is known that (at least
this) thinkpad requires the snd-cs4231 module and the kernel tried to
load another. So the question:
Where in Etch should I add the blacklisted modules so that only the
snd-cs4231 (which I've added to /etc/modules) is loaded?
Since this is a built-in device, not removable, I presume udev doesn't
apply, but in /etc/modprobe.d there are 2 files alsa-base-blacklist and
blacklist.
A related issue is: Is there an easy way to go through the system and
identify (and possibly purge, after being asked) old files that are no
longer needed/used? I presume that the packaging system would take care
of files no longer needed, but what about old packages from previous
distributions? To its credit, aptitude handled the hotplug -> udev
transition correctly, I wonder what else it didn't handle...
Well, overall, no major problems. I'm happy with the way the upgrade
turned out. Kudos to the developers!!!
A.
Reply to: