From owner-freebsd-hackers Fri May 3 10:27:40 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA21888 for hackers-outgoing; Fri, 3 May 1996 10:27:40 -0700 (PDT) Received: from diablo.ppp.de (diablo.ppp.de [193.141.101.34]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA21842 for ; Fri, 3 May 1996 10:27:22 -0700 (PDT) Received: from allegro.lemis.de by diablo.ppp.de with smtp (Smail3.1.28.1 #1) id m0uFObW-000QYHC; Fri, 3 May 96 19:25 MET DST From: grog@lemis.de (Greg Lehey) Organisation: LEMIS, Schellnhausen 2, 36325 Feldatal, Germany Phone: +49-6637-919123 Fax: +49-6637-919122 Received: (grog@localhost) by allegro.lemis.de (8.6.9/8.6.9) id TAA13099; Fri, 3 May 1996 19:24:42 +0200 Message-Id: <199605031724.TAA13099@allegro.lemis.de> Subject: Re: New disks on 2.1-RELEASE: help To: bde@zeta.org.au (Bruce Evans) Date: Fri, 3 May 1996 17:58:21 +0200 (MET DST) In-Reply-To: <199605030442.OAA15889@godzilla.zeta.org.au> from "Bruce Evans" at May 3, 96 02:42:16 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Bruce Evans writes: >> So: my question. Would some kind soul please try this with a SCSI >> disk they don't mind overwriting. Please stick very closely to the >> sequence (or tell me why it's broken :-), since that's what I'm going >> to write. Obviously the disk doesn't have to be sd1. > >> 1. Format: > >> scsiformat sd1 > > `cp somejunk /dev/sd1' would be faster. sd1 should probably be /dev/rsd1. Yes. As Joerg pointed out, scsiformat isn't part of the 2.1 release. >> 2. fdisk -u sd1 > > sd1 should certainly be /dev/rsd1. Works fine as sd1, and that's the way it's documented: The final disk name can be provided as a `bare' disk name only, e.g. `sd0', or as a fully qualified device node under /dev. If omitted, the disks `wd0', `sd0', and `od0' are being searched in that order, until one is being found responding. >> Put at least 2 partitions in. > ^^^^^^^^^^ slices :-) OK :-) > Including at least one FreeBSD one. Otherwise the device used in step 3 > won't exist. Step 3 would still work if you give the slice name (sd1s1, > sd1s2, ...) in step 3. Correct. >> 3. disklabel -w -r sd1 > >> is a tag in /etc/disktab. If you don't have one for your disk, > > Use `disklabel -R -r sd1 ' to avoid mucking with /etc/disktab. There's small choice in rotten apples. I'll describe both ways, if I ever get either one to work reliably. > can be created by editing the output of `disklabel /dev/rsd1'. OK. I've tried both ways, I've installed 2.1-RELEASE, and it just plain does not work. There's every possibility I've made an incorrect turn in the minefield, but this isn't the first time I've done this (the first time was about 4 years ago with BSD/386 0.3.1). I believe we have multiple breakages here. But first to your next point: >> Back to the problem: disklabel issues an ioctl (DIOCSDINFO) against >> the raw disk, and then checks the return value. disklabel.c:408: > >> if (ioctl(f, DIOCSDINFO, lp) < 0 && >> errno != ENODEV && errno != ENOTTY) { >> l_perror("ioctl DIOCSDINFO"); >> return (1); >> } > >> In the -current kernel, this ioctl returns an EINVAL when issued >> against a disk with an invalid label. I changed this to: > >> if (ioctl(f, DIOCSDINFO, lp) < 0 && >> errno != ENODEV && errno != ENOTTY && errno != EINVAL) { >> l_perror("ioctl DIOCSDINFO"); >> return (1); >> } > > This is wrong. EINVAL usually means that the supplied label is invalid. > It sometimes means that the wrong device is being labelled, but this case > should be rare because `disklabel sd1' always uses the correct partition > (sd1c). Why is this wrong? At this point, the label *is* invalid. The point of the exercise is to make a valid one. > I'd better change some ENODEV's to EINVAL's to stop disklabel from ignoring > fatal errors :-(. DIOCSDINFO /dev/rsd1 doesn't make sense, so it seemed like > a good idea to return ENODEV for it. (You have to label the logically > different device /dev/rsd1c even if you want to use the whole disk for BSD.) I don't understand this. We're currently getting EINVAL, not ENODEV. Did you mean to say this the other way round? And the way I see it, sd1, sd1c and /dev/rsd1c are the same thing: if I do a # ktrace disklabel -w -r sd1c cdc94161 # kdump ... lots of junk 230 disklabel RET execve 0 230 disklabel CALL open(0x1c368,0x2,0xefbfd464) 230 disklabel NAMI "/dev/rsd1cc" 230 disklabel RET open -1 errno 2 No such file or directory 230 disklabel CALL open(0x1c368,0x2,0x1c368) 230 disklabel NAMI "/dev/rsd1c" 230 disklabel RET open 3 ... lots more junk Evidently disklabel prepends a /dev/r and first tries to postpend a c to the name. ---------------------------------------------------------------------- OK, back to my problems. First, I don't see that /etc/disktab or ~/mydiskinfo have much in the way of advantages against each other. I'm trying to (and occasionally succeeding in) adding a "CDC 94161-9 6226" type 0 fixed SCSI 1 as /dev/sd1 shared between DOG and FreeBSD. I have no problems (apart from this damn interactive business) making the partition table, which has two valid entries: Partition Type Offset 1 DOG 1 2 BSD 99540 fdisk says: The data for partition 0 is: sysid 6,(Primary 'big' DOS (> 32MB)) start 1, size 99539 (48 Meg), flag 0 beg: cyl 0/ sector 2/ head 0; end: cyl 315/ sector 35/ head 8 The data for partition 1 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 99540, size 205065 (100 Meg), flag 80 beg: cyl 316/ sector 1/ head 0; end: cyl 966/ sector 35/ head 8 Let's look at the problems with /etc/disktab first. I created an entry cdc94161|CDC 94161-9: \ :ty=winchester:dt=SCSI:se#512:nt#9:ns#35:nc#967:rm#3600:\ :ob#99540:pb#40950:tb=swap:\ :oc#99540:pc#205065:\ :oh#140490:ph#164115:tb=4.2BSD: After formatting or copying /dev/zero, I fdisk as shown above. Then I do: # disklabel -w -r /dev/sd1c cdc94161 disklabel: ioctl DIOCSDINFO: Label magic number or checksum is wrong! (disklabel or kernel is out of date?) This is what I reported yesterday under 2.2-current. It's just the same under 2.1-release. My fixed version works under either version. So I did that: # disklabel-fixed -w -r sd1c cdc94161 # disklabel-fixed -w -r sd1c cdc94161 disklabel: ioctl DIOCSDINFO: Open partition would move or shrink The only way I have found to get this problem to go away is to overwrite the beginning of the partition: # dd if=/dev/zero of=/dev/rsd1 seek=99540 obs=512 count=100 100+0 records in 100+0 records out 51200 bytes transferred in 1 secs (51200 bytes/sec) # disklabel-fixed -w -r sd1c cdc94161 # disklabel-fixed -w -r sd1c cdc94161 disklabel: ioctl DIOCSDINFO: Open partition would move or shrink There's obviously something broken here. OK, you wanted me to use the proto version. So let's look at that. I did: # disklabel /dev/rsd1 >diskproto Warning, revolutions/minute 0 boot block size 0 super block size 0 # cat diskproto # /dev/rsd1: type: unknown disk: label: flags: bytes/sector: 512 sectors/track: 35 tracks/cylinder: 9 sectors/cylinder: 315 cylinders: 967 sectors/unit: 304605 rpm: 0 interleave: 0 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 3 partitions: # size offset fstype [fsize bsize bps/cpg] c: 304605 0 unused 0 0 # (Cyl. 0 - 966) I'd say this is broken, too. From the various complaints I've seen from disklabel, slice c needs to be inside the FreeBSD slice. Here, it's given the whole disk. OK, I modified this, and created: 8 partitions: # size offset fstype [fsize bsize bps/cpg] b: 40950 99540 swap 0 0 # (Cyl. 316 - 445) c: 205065 99540 unused 0 0 # (Cyl. 316 - 966) h: 164115 140490 4.2BSD 0 0 # (Cyl. 446 - 966) When I try to create the file system, I get (sing along with me) # dd if=/dev/zero of=/dev/rsd1 seek=99540 obs=512 count=100 100+0 records in 100+0 records out 51200 bytes transferred in 2 secs (25600 bytes/sec) # disklabel -R -r sd1 diskproto disklabel: ioctl DIOCSDINFO: Label magic number or checksum is wrong! (disklabel or kernel is out of date?) # disklabel-fixed -R -r sd1 diskproto # disklabel-fixed -R -r sd1 diskproto disklabel: ioctl DIOCSDINFO: Open partition would move or shrink In summary, I'd say that disklabel is broken, whichever way you want to look at it. OK, it's also not exactly a good tool, but it's all we have on the 2.1 CD-ROM. I think we can get by with my version (and, as I said before, I think that disklabel is broken, not the return codes from the drives), but that doesn't help much: I'm describing this for people using the 2.1 CD, and they need to be able to do it with the software on the CD. If you have any bright ideas, I'd be very grateful. ---------------------------------------- Other problems encountered along the way: if I make a partition too large, I get: # disklabel -R -r sd1 diskproto write: Read-only file system At the same time, the console claims: May 3 19:10:48 daemon /kernel: fixlabel: raw partition size > slice size May 3 19:10:48 daemon /kernel: fixlabel: raw partition offset != slice offset Greg