Subject: Re: kern/21408: "sd0: no disk label" messages are stupid and annoying
To: None <netbsd-bugs@netbsd.org>
From: David Laight <david@l8s.co.uk>
List: netbsd-bugs
Date: 05/14/2003 17:38:28
> >Synopsis: "sd0: no disk label" messages are stupid and annoying
(affects sysinst as well...)
> 1. It is common for vnd devices to not have disklabels (checking
> the contents of a makefs(1)'d file system image, for instance).
> Repeated opening of a vnd device thus fills the message buffer
> with "vnd0: no disk label" messages. This is very irritating.
The vnd driver fills all the NetBSD partitions with reference to the
whole disk if/when readdisklabel reports an error.
Is this really desirable?
Isn't it enough to ensure that the 'whole disk' partition (c or d)
is setup? Maybe setup 'a', but doing the others is rather pointless.
> >Fix:
> Lack of a disk label should not be considered an error. All
> readdisklabel() routines in machine-dependent code will need
> to be adjusted for this.
Do you think that readisklabel() should not actually report any errors
at all? But just generate the 'best' disklabel it can?
I've been editing (hacking) the i386 code, at it gets rather difficult
to decide what is an 'error', and what is 'expected'.
The problem is that a disk can have:
- A NetBSD MBR partition with a NetBSD disklabel.
- A NetBSD MBR partition without a NetBSD disklabel.
- A NetBSD MBR partition without a NetBSD disklabel, but with a NetBSD
disklabel in the second sector of the disk.
- A valid MBR without a NetBSD partition, but with a NetBSD disklabel
in the second sector of the disk.
- A valid MBR without a NetBSD partition and no NetBSD label in the
second sector.
- An invalid MBR with a NetBSD disklabel in the second sector of the disk.
- A NetBSD disklabel in the first sector of the disk.
- No label information at all.
Not to mention that fact that the NetBSD label could be byte reversed!
A slightly related point - does anyone know if d_npartitions is intended
to be a bound on the number of allocated netbsd partitions, or the number
of entries available in the on-disk structure?
The latter would make more sense, but some code seems to set it to the former.
The problems arise if you move a disk from/to a system where MAXPARTITIONS
is 8 to/from one where it is 16.
David
--
David Laight: david@l8s.co.uk