Date: Thu, 2 Nov 1995 03:32:27 -0600 From: rkw@dataplex.net (Richard Wackerbarth) To: hackers@FreeBSD.org Cc: davidg@Root.COM, joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), nate@rocky.sri.mt.net Subject: Re: More nits Message-ID: <v02130514acbe3cded8bc@[199.183.109.242]>
next in thread | raw e-mail | index | archive | help
At 12:19 AM 11/2/95, Jordan K. Hubbard wrote: >> Ummm, actually, I'm the one who made the changes to /etc/rc. I don't care >> about the CDROM, but I do think it's extremely important that the system not >> come up if some filesystems fail to mount. > >Well, for those of us that *do* care about the CDROM, how about >making these changes a little less draconian? Perhaps a two stage >mount? Everything but the CD and DOS for the first, non-optional stage, >then a second mount of CDs and DOS partitions that's allowed to >fail? I support that idea. An extension of it would be the case of NFS mounts. Some of these mounts are critical and some are optional. For example, mounting /usr might be critical, but /pub/FreeBSD would be optional. If my ftp server came up and could not find the public volumes, that should not keep it from running. It should simply report that the volume is unavailable. Similarly, the CD-ROM might fall in either category. It could represent an essential portion of the tree, or an optional portion. I guess that it could be argued that anything to support login is required and anything else is optional. However, in many situations, such a simplistic approach would keep a machine from accomplishing its mission. I think that, in the final analysis, the system administrator will have to decide what is required and what is optional. Along those lines, I have encountered a problem with termcap being in /usr/share. If the /usr/share volume is a remote NFS volume that happens to be unavailable, I cannot log into the system to "fix" it. ---- Richard Wackerbarth rkw@dataplex.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v02130514acbe3cded8bc>