Hi, I'm not subscribed to debian-user any more because of the volume, but please feel free to respond to me directly via e-mail if you have any questions, comments, etc.: [EMAIL PROTECTED]
I helped a friend upgrade from bo to hamm yesterday over the phone. This is not easy in and of itself :^) But we had problems with the cd_autoup.sh script and with dselect as well. Upgrade details: 1.) 1.3.1 installed on a Pentium II 266 (Gateway machine), upgrading to hamm beta so we could get the latest XFree86 SVGA server to support his STB Velocity 128 video card. Originally installed from the "Official Debian" CD from CheapBytes last year, did *not* previously upgrade using the 1.3.1r6 CD from CheapBytes. 2.) Upgrading using the 2.0 beta CD-ROM from CheapBytes. 3.) Upgrading using the cd_autoup.sh script available from ftp.debian.org, the running dselect to upgrade all the packages to hamm. 4.) The original bo install might have been somewhat broken, because my friend did it without my help. This could explain some dselect problems. Also, perhaps there are problems with the CheapBytes CD? Here's what we had problems with: A.) The cd_autoup.sh script is slightly broken. We cd'ed to /cdrom/hamm before running the script because this seemed like the logical place to be to me. *No*place* on the CD corresponded the to definition of DM in the shell script. This meant we had to change the definition of the variable DM to: DM=./$ARCH B.) The definition of the variable PKGS_NET is incorrect. You need to replace the line: PKGS_NET=$( echo "$PKGS_NET" | sed -e "$SEDSCRIPT" ) with: PKGS_NETBASE=$( echo "$PKGS_NETBASE" | sed -e "$SEDSCRIPT" ) PKGS_NETSTD=$( echo "$PKGS_NETSTD" | sed -e "$SEDSCRIPT" ) C.) We had several packages fail to be removed by cd_autoup.sh because they were somehow on hold. We had to do: # dpkg --force-hold -r packagename by hand on these to fix this, then rerun and rerun cd_autoup.sh until it ran without errors. These packages being on hold may have been caused by an originally broken install of bo(?). D.) It's hard to talk somebody through running dselect over the phone because there's so much info on the screen that's vital. But even considering that, we had alot of problems. We had dependency conflicts that we couldn't easily resolve because several installed packages depended on another package, but this package wasn't offered for installation on the resolution screen. This seems strange to me, I've never seen dselect act like this before. Finally we found the needed packages by searching through the Select menu and got them installed. E.) Dselect just plain old decided for itself to install 9wm et al and uninstall fvwm and fvwm2. We didn't even check on these selections because we figured it was a no-brainer. We did catch the 9wm stuff before running Install, but fvwm and fvwm2 were uninstalled and we had to go back and reinstall them. F.) *Lots* of his packages were listed as "Hold" and I have no idea why. Maybe the original install was broken and caused the hold problems. Maybe the dpkg database got messed up somehow and caused the 9wm and fvwm installation/removal problems. Maybe the CheapBytes CD is somewhat broken. I'm not sure, I'm just documenting the problems we had with the upgrade. In the end we successfully upgraded to hamm and now he needs to take care of the held packages and install and configure the SVGA X server for his video card. I use and love Debian and plan to keep on using it. But this was a very exhausting and frustrating experience. Maybe alot of the problems are because I'm dumb. I hope so, and I hope other people's upgrade experiences go alot smoother than ours. Thanks for listening. Clemmitt Sigler Va. Tech Physics Dept. -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] < /dev/null