Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 30 Nov 95 21:05 WET
From:      uhclem%nemesis@fw.ast.com
To:        FreeBSD-gnats-submit@freebsd.org
Subject:   misc/856: Install 2.0.5 Upgrade option does too much damage FDIV043 
Message-ID:  <m0tLLmf-000CR4C@nemesis.lonestar.org>
Resent-Message-ID: <199512010320.TAA20441@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

>Number:         856
>Category:       misc
>Synopsis:       Install 2.0.5 Upgrade option does too much damage FDIV043
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Nov 30 19:20:03 PST 1995
>Last-Modified:
>Originator:     Frank Durda IV
>Organization:
None
>Release:        FreeBSD 2.1-STABLE i386
>Environment:

A 2.0.5 RELEASE system was upgraded to 2.1.0-RELEASE using the 2.1.0-RELEASE
system and the Install "Upgrade 2.0.5" option, instead of wiping the
disks and starting over.

>Description:

I had the opportunity to try the 2.0.5 to 2.1.0 upgrade on a 2.0.5
system and find that this option should not be used by even experienced
persons.    Note that prior to the upgrade, I made to complete dumps
of the system on different tapes, and a tar of /etc which I hid down
in a partition well out of the way of any installation process.
So all I lost was time, and some EMAIL that was trashed by the
resulting system.

Here are some of the problems encountered:

1.	During the upgrade, you are asked for a location where a
	copy of /etc can be saved.  It offered /usr/tmp/etc, but
	I selected /a/etc2.0.5 instead.  

	The installation appears to run normally, then the system
	starts "resurrecting" files in /etc.  It pops up several
	times listing files that it can't handle that the user must
	deal manually with, such as sysconfig, rc, rc.serial, kerberosIV,
	etc.  It suggests you write the names down (I did) and fix them
	in a shell you are offered later.   That's fine.

	When I got the shell, I started by doing a diff against
	the old file the install placed in /a/etc2.0.5 and what was
	in /etc now.  The first several files were identical, but
	that didn't surprise me since this system wasn't very 
	configured.   Then I noted that files that should have been
	different were not, such as sysconfig.  I checked the files
	in /a/etc/2.0.5, and several (but not all) showed modification
	times of just a few minutes earlier, instead of weeks earlier
	from the previous 2.0.5 installation.

	I suspect the upgrade procedure inadvertantly copies the new
	files over the old ones in the "safe" directory.  Fortunately
	I had a "tar" hidden around that could be used to recover the
	files as they stood prior to upgrading, and then the diffs could
	be done.


2.	Once I got through with this shell (and I was in it for nearly an
	hour), I didn't know what I was supposed to do next.  There may
	have been an instruction when the shell was spawned, but it scrolled
	off the screen 50-odd minutes earlier.)  So I did a CTRL-D, and got
	the message:
	PANIC: Not going anywhere without init!  or something to that effect.
	The system halted and left all the filesystems were dirty.  

	What is the correct procedure to get out of the shell and completing
	the upgrade installation?


3.	After rebooting and cleaning, I updated the kernel configuration
	and attempted a kernel build.  The kernel failed to compile in a
	couple of places due to old files from the 2.0.5 distribution that
	aren't in 2.1.0, but aren't deleted in the upgrade.  Their presence
	confused make depend/make and resulted in compiler errors.  Deleting
	the extra files and re-doing the make depend/make produced a kernel
	OK.

	Then I started a 'make world' and started running into the same
	type of problem in applications and libraries.   I finally blew the
	make world off.

	This type of problem would only show up if you really upgraded a
	2.0.5 system, and not if you simply re-ran the upgrade on a system
	that was already (or close to) 2.1.0.   This may explain how this
	problem escaped detection.


4.	I rum SMAIL on this system, so as soon as the above issues were
	ironed-out, I re-installed it from the pre-compiled binaries.
	(It is one of those ports distributions).  Anyway, it installs
	its files and then moans that a version already exists on the
	system and the install may not be proper, suggesting you run
	pkg_delete.  So I do this, and re-install.  But the package
	refuses, until I delete the ".is_installed" file.  Then
	it installs without complaint, but mail delivery no longer works.
	I fiddled and even re-compiled SMAIL and installed that, and
	mail would not be delivered.  Finally, I restored all of the files
	from the 2.0.5 tree that had anything to do with SMAIL, and most of
	the problem went away.  However, the system doesn't recognize itself
	by one of its domain names anymore, and keeps sending mail to itself,
	and mail to a local user is never delivered (it just sits in
	/var/spool/smail/input and gets examined every two minutes and put
	back there), so I will probably nuke the entire system and install
	2.1.0 from scratch and see what happens.   This is just too weird.

>How-To-Repeat:

See above.


>Fix:
	
Don't use the upgrade option.  The user warning clearly isn't scary enough
and it will cause problems no matter who you are.   Even if you have
SCSI drives.  :-)  (This was an all-SCSI system, not that it matters.)

I recommend that the upgrade option be pulled from the next release
unless we can determine a way to address deleting "old 2.0.5" files
without deleting user-created files that may be lurking in the same
directories.  Also fix the update of /etc so that the "safe" files
don't get altered.   I don't know what to suggest about how SMAIL
disintegrated after the upgrade.  I know non-port versions of SMAIL work
OK on 2.1.0.

>Audit-Trail:
>Unformatted:



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0tLLmf-000CR4C>