*BSD News Article 73652


Return to BSD News archive

Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.mel.connect.com.au!news.syd.connect.com.au!gidora.zeta.org.au!not-for-mail
From: bde@zeta.org.au (Bruce Evans)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Help: FreeBSD 2.1 'mount' fails on a 2.0 SCSI partition
Date: 14 Jul 1996 16:08:42 +1000
Organization: Kralizec Dialup Unix
Lines: 87
Message-ID: <4sa2ta$gce@godzilla.zeta.org.au>
References: <Hc3d6BAgq$4xEwMa@icrt.demon.co.uk>
NNTP-Posting-Host: godzilla.zeta.org.au

In article <Hc3d6BAgq$4xEwMa@icrt.demon.co.uk>,
Lars G. Erlandsen <lerland@icrt.demon.co.uk> wrote:
>...
>FreeBSD 2.1 was installed from CD-ROM without problems on the new IDE
>drive. However, shock horror, it gets into fits when I'm manually trying
>to mount the SCSI disk, complaining about overlapping partitions, in
>particular '/dev/sd1s1d' (yes, I've got two SCSI disks as well, now!).
>===============================================================
>sd1s1: rejecting partition in BSD label: it isn't entirely within the
>slice
>sd1s1: start 32, end 1435647, size 1435616
>sd1s1d: start 0, end 2110811, size 2110812
>===============================================================

This is normal for converting a 2.0 system to 2.0.5 or later.  The 'd'
partition meant the whole disk in 2.0, but it is just another partition
in 2.0.5 or later and in all non-i386 BSDs.  The driver rejects it at
boot time because it would be dangerous to use it as just another
partition.  Rejection only involves not putting it in the in-core disk
label.  However, if you write the label back to the disk, then the
old label will be overwritten, and you would need to restore the 'd'
partition to use the system under 2.0 again.

>Ironically, it then mounts the root partition, which is -- a) the
>partition that is not in a fit state, anyway after just a tar, and b)
>not the one I need. The usr partition is not accessible. But 'fsck'
>finds everything, and reports no problems when I run it on the unmounted
>SCSI slice, though (I think).

None of the other partitions should have changed.  You should have got
warnings about rejection of the usr partition.  The warnings say where
it was so that it is easy to put it back.

>The slice looks like (in the eyes of 'disklabel'):
>===============================================================
># /dev/sd1s1:
>type: SCSI
>disk:
>label: MBR based label
>flags:
>bytes/sector: 512
>sectors/track: 32
>tracks/cylinder: 64
>sectors/cylinder: 2048
>cylinders: 700
>sectors/unit: 1435616
>rpm: 0
>interleave: 0
>trackskew: 0
>cylinderskew: 0
>headswitch: 0           # milliseconds
>track-to-track seek: 0  # milliseconds
>drivedata: 0
>
>8 partitions:
>#        size   offset    fstype   [fsize bsize bps/cpg]
>  a:    61440        0    4.2BSD     1024  8192    16   # (Cyl.    0 -
>29)
>  b:   163840    61440    4.2BSD     1024  8192    16   # (Cyl.   30 -
>109)
>  c:  1435616        0    unused        0     0         # (Cyl.    0 -
>700*)
>  e:  1210336   225280    4.2BSD     1024  8192    16   # (Cyl.  110 -
>700*)
>
>===============================================================
>
>At this point, I can see that I have 6 different options for digging out
>the home partition (the 7th one - scrapping everything - is for now a
>non-starter), but for all of them there are vital pieces in the jigsaw
>puzzle missing:

It looks like the 7th partition was beyond the end of the FreeBSD slice.
The 'c' partition may have been truncated too.  To fix this you first
have to extend the slice to cover the entire area described by the
label.  The missing partition should then reappear provided you haven't
written back the label and there are no further inconsistencies in the
old label.

>2. Assume the FreeBSD 2.1 team have changed the partitioning software
>sufficiently to make it non-portable between 2.0 and 2.1 (not
>unreasonable given the added functionality it now offers on the
>partitioning). Action: Rely on some migration

The partitioning layout is portable provided the old one was consistent.
-- 
Bruce Evans  bde@zeta.org.au