[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

cd_autoup.sh and hamm upgrade problems.



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.: csigler@vt.edu

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 debian-user-request@lists.debian.org < /dev/null


Reply to: