From owner-freebsd-hackers Wed Aug 30 12:54:37 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id MAA27097 for hackers-outgoing; Wed, 30 Aug 1995 12:54:37 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id MAA27086 for ; Wed, 30 Aug 1995 12:54:28 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id FAA19689; Thu, 31 Aug 1995 05:51:22 +1000 Date: Thu, 31 Aug 1995 05:51:22 +1000 From: Bruce Evans Message-Id: <199508301951.FAA19689@godzilla.zeta.org.au> To: hackers@freebsd.org, jdl@chrome.onramp.net Subject: Re: /etc/disktab and stuff Sender: hackers-owner@freebsd.org Precedence: bulk >> disklabel -B -r -w sd1 xxx >> newfs /dev/rsd1a >> newfs ... # any other partitions on disk >> >> where xxx is a suitable entry that you wrote and put in /etc/disktab. >Does it make sense to attempt to collect people's /etc/disktab entries >and make them more available in the (next) released /etc/disktab? No. You would need a hundred entries for each of a few hundred disks to get a reasonable coverage. Something like the following should work, but I'm less sure about it: disklabel /dev/rsd1 >/etc/label.sd1 # get sub-minimal label vi /etc/label.sd1 # fix deficiencies in label; # partition as required disklabel -R -r sd1 /etc/label.sd1 >In particular, it seems to me that many of the questions that float >down this list are fdisk/disklable related and maybe providing more >example configurations there might mitigate some of those problems. There are already examples in /etc/disktab. You can judge from the small size of the drives in this file how generally (not) useful it is to add special entries to it. Bruce