Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 11 May 95 11:23:22 MDT
From:      terry@cs.weber.edu (Terry Lambert)
To:        gurney_j@efn.org (John-Mark Gurney)
Cc:        hackers@FreeBSD.org
Subject:   Re: installation program for 0412-SNAP
Message-ID:  <9505111723.AA00740@cs.weber.edu>
In-Reply-To: <Pine.NEB.3.91.950510223225.194A-100000@unix> from "John-Mark Gurney" at May 10, 95 10:45:57 pm

next in thread | previous in thread | raw e-mail | index | archive | help
I'm not the install god, but since Jordan is busy release-rolling, maybe
I can address some of the points.

> now for the heart of the matter...  there should be a intermediate 
> installation that doesn't limit you...  I was going to mount my /, /usr, 
> /games, and /programming .  only the last two I could preserve... this is 
> number one... there should be a way to preserve the contents of a 
> drive... maybe mounting the drive then clearing the directories like 
> /etc, /var, and others...  that way you can actually preserve some of the 
> data on them...  then I go to add /usr... well... I can't preserve that 
> and that is my main partion... right now it is 550 megs... it has the 
> home directories, my file archives (including FreeBSD), X and other 
> stuff...  now the installation wants to newfs that...  so I think... 
> ok... why don't I just not mount it... and afterward mount it...

1)	Preserving partitions during an install.

	The binary load format has changed; this is a sufficient
	but not necessary reason to stomp all the partitions.  The
	main reason is that the file system itself has changed,
	notably needing a larger volume label, and changing the
	way symbolic links are structured.  In addition, the major
	and minor numbers have increased in size.

	With a change in file system format, it's highly recommended
	that you reformat, and if you don't want to, desirable to
	make it difficult to discourage you from having a mixed
	install.

2)	Preservation of /usr.

	The /usr partition can be preserved by choosing an install
	that doesn't have a seperate user, then changing the mount
	table after the install.  Since /usr contains some important
	system binaries, that's to be discouraged, but not prevented.

	Once installed without a seperate /usr, you can mount the
	previous /usr on /mnt, and using the new /usr as a template,
	choose directories like /usr/bin and /usr/lib to update
	manually, unmount the partition, modify the fstab to mount
	the replacement /usr, rename the current (newly installed)
	/usr in case you have boot problems, create a new /usr with
	mdir, chown, chgrp, and chmod, and then reboot.

3)	Preservation of existing X binaries.

	The X server itself will need to be updated, period.  If you
	are using shared libraries and don't want to replace them, you
	will need to preserve them when you install the new X.  Since
	the X isn't unit installable (there are significant R5/R6
	differences), it's likely that the only binaries you will want
	to preserve are those that were not part of the X distribution
	itself.

> so I go to proceed with my swap, /, /programming, and /games assigned...  
> well... my / is only 47megs and it won't let me past to install without 
> assigning /usr... what's up???

The install installs binaries and system files for multiuser boot into
the /usr directory.  You must assign /usr, although you can leave it on
your / partition temporarily.

> can't I make my own descisions...  sure 
> you can have the warning but don't force it on you...  sure I probably 
> couldn't install the bindist on just the /... but I could skip the 
> installation of the bindist... reboot off the hard drive... manually 
> mount /usr... and then install the bindist after possibly cleaning 
> /usr/bin, etc...

This is what you have to do, in compination with ithem (2) above.

> I personally liked the old installation much better... the only 
> installation took less time... was a little more experience friendly...  
> it also forced along some routes but didn't on some of the more important 
> ones...  what I would like to see is the ability to do an intermediate 
> installation... one that the user isn't a FreeBSD hacker and happens to 
> sup current... or an idiot that doesn't know a hard disk from a floppy 
> disk... one that does know the system ok...  knows how to mount the 
> disks... disklabel them manually... modify the fstab...  among other 
> capbilities...

It has to get worse before it gets better.

The ideal installation is data-driven in two ways.  The first is with
an addition to the system files to associate files with installed
packages and permissions checking, like SCO.  This would facilitate
breaking up the reinstall into a two stage deinstall-old/install-new
process.  The second is to damage the majority of what has traditionally
been though of as the /etc directory and to move system information out
of /etc and the other places it is spread out in (including things like
/etc/printcap and /etc/netstart) over to /var and to make sure that the
resulting data is *data alone* and not shell scripts or anything else
system specific, which would allow you to replace all the shell scripts
and binaries without touching the data (like machine name, routes, passwd
and shadow files, NIS(YP) setup, file systems, etc.).

To get from the current to the ideal demands at least one additional
painful revision, and the destruction of a lot of what is considered
the Berkeley legacy in the system directories.

> right now the installation is almost TOO idiot proof...  people like me 
> whoo kinda know the system but don't know how to go about manually 
> installing the whole new system are basicly dead in the water... we can't 
> upgrade because the install wants to newfs all our valuable data... and 
> we can't just get the basic /bin, /sbin, kernel, and bootblocks installed 
> so we can install the bindist by hand...  I hope you understand what I 
> said... and hope that the changes can be made by the 2.1 RELEASE...  TTYL...

I'd argue that the "idiot proof" appearance of the install is really the
result of it being largely inflexible, and is a result of making it
robust first, more than anything else.  And yes, a robust installation
has as a side effect that it's more difficult for an idiot to mess it up,
just as it's more dificult for an experienced person to "mess it up".


					Terry Lambert
					terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.



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