Re: Changed names of logical disks on recent -CURRENT: part of logical disks not accessible now

From: gelraen <gelraen.ua_at_gmail.com>
Date: Mon, 22 Dec 2008 07:30:13 +0200
2008/12/22 Ivan Voras <ivoras_at_freebsd.org>:
> Paul B. Mahol wrote:
>> On 12/20/08, gelraen <gelraen.ua_at_gmail.com> wrote:
>>> Hello,
>>>
>>> I've csup'ed about 1 hour ago (previous csup was few days back),
>>> recompiled kernel and slice names changed from ad0s5 to something like
>>> ad0s3s1, etc.
>>> But in /dev I found only 3 levels of slices:
>>
>> Maybe because of recent switch from geom_bsd, geom_mbr to
>> geom_part_bsd and geom_part_mbr.
>
> Yes, it's almost certainly because of that. The OP should contact marcel
> /at/ freebsd.org and probably be ready to send him boot (zeroeth)
> sectors of his drive(s) and partitions.
>
>
>

Hmm.... I've just noticed one strange thing: corresponding to PTs of
ad0s3 and ad0s3s2, ad0s3s2s1 uses whole slice, and first sector of
ad0s3s2s2 located beyond boundaries of ad0s3s2.
So I've booted 7.0-RELEASE, to ensure that all still working, and
dumped all boot sectors directly from ad0, calculating offsets
manually.

It seems strange to me, but second entry in PTs on extended partition
contains offset directly from ad0s3, not from ad0s3s2, ad0s3s2s2 etc.,
and sized to only one slice, not the rest of extended partition. And,
because ad0s3s2 now simply does not contain needed data, PT of
ad0s3s2s2 can not be readed:
# fdisk ad0s3s2s2
fdisk: could not detect sector size

I think, now I should move PT entries from ad0s3s2 and so on directly
to PT of ad0s3, but I don't sure about how would other OS and previous
versions of FreeBSD will understand this


BTW, now fdisk seems to be unable to work with regular files, it fails
with message
fdisk: unable to get correct path for tmp.bin
: Inappropriate file type or format

and ktrace shows next thing:
  5740 fdisk    CALL  ioctl(0x3,DIOCGSECTORSIZE,0xbfbfe5e4)
  5740 fdisk    RET   ioctl -1 errno 25 Inappropriate ioctl for device
Received on Mon Dec 22 2008 - 04:30:15 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:39 UTC