Date: Fri, 2 Jun 2000 09:59:17 +0930 From: Greg Lehey <grog@lemis.com> To: tomb <tomb@cgf.net> Cc: freebsd-questions@freebsd.org Subject: Re: vinum and bad pack magic number Message-ID: <20000602095917.F22978@wantadilla.lemis.com> In-Reply-To: <3937D45A.9C7F9ED@cgf.net> References: <002401bfcb06$a3ecf140$a99d24d4@vindaloo.profero.com> <39353A62.DDBAB828@cgf.net> <20000601111128.F20158@wantadilla.lemis.com> <393764F2.A0D05342@cgf.net> <20000601175607.O20158@wantadilla.lemis.com> <3937D45A.9C7F9ED@cgf.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, 2 June 2000 at 8:35:54 -0700, tomb wrote:
> OK,
>
> So I looked back in my mail acrhive and dug out the dialog I had and
> here's the exact problem. On instruchtion from you I had been
> attempting to create a disklabel on a partition that did not yet
> exist..!
>
>>> At this point I have not done anything to the disk's (like newfs or
>>> /stand/sysinstall) they are low-level formatted only.
>>
>> That's all you need. I'm assuming that you're using an older version
>> of FreeBSD. Do 'disklabel -e da0' and it should work.
>>
>>> 8 partitions:
>>> # size offset fstype [fsize bsize bps/cpg]
>>> a: 8496884 0 vinum 0 0 0 # (Cyl. 0 - 528*)
>>> c: 8496884 0 unused 0 0 # (Cyl. 0 - 528*)
>>>
>
> This was the whole problem. Disklabel did not work and after
> reading the man page for disklabel I could find no way of adding a
> new partition and relabeling it.
Well, you could ask again. disklabel will do this for you, but you
need different options. From disklabel(8):
Writing a standard label
To write a standard label, use the form
disklabel -w [-r] disk disktype [packid]
The required arguments to disklabel are the drive to be labeled and the
drive type as described in the disktab(5) file. The drive parameters and
partitions are taken from that file. If different disks of the same
physical type are to have different partitions, it will be necessary to
have separate disktab entries describing each, or to edit the label after
installation as described below. The optional argument is a pack identi-
fication string, up to 16 characters long. The pack id must be quoted if
it contains blanks. If the -r flag is given, the disk sectors containing
the label and bootstrap will be written directly. A side-effect of this
is that any existing bootstrap code will be overwritten and the disk ren-
dered unbootable. See the boot options below for a method of writing the
label and the bootstrap at the same time. If -r is not specified, the
existing label will be updated via the in-core copy and any bootstrap
code will be unaffected. If the disk does not already have a label, the
-r flag must be used. In either case, the kernel's in-core label is re-
placed.
For a virgin disk that is not known to disktab(5), disktype can be spec-
ified as ``auto''. In this case, the driver is requested to produce a
virgin label for the disk. This might or might not be successful, de-
pending on whether the driver for the disk is able to get the required
data without reading anything from the disk at all. It will likely suc-
ceed for all SCSI disks, most IDE disks, and vnode devices. Writing a
label to the disk is the only supported operation, and the disk itself
must be provided as the canonical name, i.e. not as a full path name.
The following will often work, but not always:
# disklabel -w -r da0 auto
> "fdisk/newfs" was the correct answer
fdisk will do it too, but it's not needed. newfs is very definitely
the *wrong* answer. It also takes a considerable period of time.
> and in my case was in fact operated from stand sysinstall. As
> stated in my previos mail I thought it was necessary to add a
> partition, but you said that was not necessary. This was incorrect
> as I later discovered.
>
> This is the ambiguity that I am fighting with my so called
> experimental methods. At then end of the day the documentation
> could have mention of this, what may seem obvious to the inventor is
> not as clear to us who live in userland.
>
> Getting it working is, at the end of the day, all we care about.
Well, yes, but it would be nice to catch these problems and ensure
that other people don't have them too, rather than making them go
through the same pain again.
Greg
--
When replying to this message, please copy the original recipients.
For more information, see http://www.lemis.com/questions.html
Finger grog@lemis.com for PGP public key
See complete headers for address and phone numbers
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000602095917.F22978>