Date: Thu, 02 Mar 2000 19:03:04 -0700 From: Warner Losh <imp@village.org> To: current@freebsd.org Subject: sysinstall vs disks Message-ID: <200003030203.TAA19605@harmony.village.org>
next in thread | raw e-mail | index | archive | help
I'm running the latest sysinstall (I just built it and installed it in
/stand/sysinstall). When I tried to run the disk slice (fdisk)
editor, it told me that I had no disks on my system. It appears that
Disk_Names is returning no disks because DIOCGSLICEINFO is returning
ENODEV for all the disks that are opened and stat'd correctly.
I see this same behavior with the following libdisk program:
#include <sys/types.h>
#include <libdisk.h>
#include <stdio.h>
int
main(int argc, char **argv)
{
char **n;
n = Disk_Names();
printf("Disk names: ");
while (*n) {
printf("%s", *n);
free(*n);
n++;
}
printf("\n");
}
When I run the above program, I see no output, for similar reasons
(BTW, there's a fd leak in Disk_Names, which shouldn't matter).
More generally, I've been trying to track down why disklabel auto is
currently broken after a fdisk -e. I have to make a lot of disks that
are all slightly different (think CF cards from many different mfg
that are all the same size, but report slightly different geom, so I
can't cookie cutter it).
Things I've tried:
# fdisk -e -v ad8 | tail -7
1: sysid 165,(FreeBSD/NetBSD/386BSD)
start 32, size 20448 (9 Meg), flag 80 (active)
beg: cyl 0/ sector 1/ head 1;
end: cyl 319/ sector 32/ head 1
2: <UNUSED>
3: <UNUSED>
4: <UNUSED>
# disklabel -w ad8 auto
disklabel: No space left on device
# disklabel -w ad8s1 auto
disklabel: ioctl DIOCGDINFO: Invalid argument
disklabel: auto: unknown disk type
If I hand craft the disk label using a mutant version of the diskprep
awk script that phk posted awhile ago, then I can get it to work. The
"No space left on device" error is caused because the disk label
returned from the kernel covers the entire disk, rather than the
entire slice (in this case, they are different by 32 sectors, which is
why the DIOCSDINFO/DIOCWINFO is failing, btw). I can see what label
is trying to be written by adding -r to the disklabel and hacking
disklabel to go ahead and write the label, even if the kernel retjects
it. Turned out to be a bad idea, since it causes lots of other
problems....
Warner
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200003030203.TAA19605>