From owner-freebsd-hackers Thu May 11 10:30:08 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA07096 for hackers-outgoing; Thu, 11 May 1995 10:30:08 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id KAA07090 for ; Thu, 11 May 1995 10:30:07 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA00740; Thu, 11 May 95 11:23:23 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9505111723.AA00740@cs.weber.edu> Subject: Re: installation program for 0412-SNAP To: gurney_j@efn.org (John-Mark Gurney) Date: Thu, 11 May 95 11:23:22 MDT Cc: hackers@FreeBSD.org In-Reply-To: from "John-Mark Gurney" at May 10, 95 10:45:57 pm X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@FreeBSD.org Precedence: bulk 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.