Date: Wed, 9 Oct 2019 15:37:15 -0400 From: Charles Sprickman <spork@bway.net> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Bob Eager <rde@tavi.co.uk>, freebsd-fs@freebsd.org Subject: Re: Cannot mount an older disk Message-ID: <1D679F0E-49BB-4B7A-9D41-E03D480A394E@bway.net> In-Reply-To: <20191009080525.GJ44691@kib.kiev.ua> References: <12475952-c412-60a8-6ff7-7ebcd5c84ed8@aldan.algebra.com> <20191009083216.39e0c903@raksha.tavi.co.uk> <20191009080525.GJ44691@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
--=20 Charles Sprickman NetEng/SysAdmin Bway.net - New York's Best Internet www.bway.net spork@bway.net - 212.982.9800 > On Oct 9, 2019, at 4:05 AM, Konstantin Belousov <kostikbel@gmail.com> = wrote: >=20 > On Wed, Oct 09, 2019 at 08:32:16AM +0100, Bob Eager wrote: >> On Tue, 8 Oct 2019 21:35:07 -0400 >> "Mikhail T." <mi+t@aldan.algebra.com> wrote: >>=20 >>> Hello! >>>=20 >>> Going through older hard drives, I found one that still seems to = work=20 >>> and was curious, what's on it. The OS -- 12.1-STABLE -- sees it = find.=20 >>> The disklabel seems sane (except for the number of partitions): >>>=20 >>> # /dev/ada1: >>> 8 partitions: >>> # size offset fstype [fsize bsize bps/cpg] >>> b: 12582912 0 swap >>> c: 1465149168 0 unused 0 0 # "raw" = part, >>> don't edit >>> d: 1452566256 12582912 4.2BSD 8192 65536 52352 >>>=20 >>> and there are ada1, ada1b, and ada1d entries under /dev. So far so >>> good. Unfortunately, both mount and fsck tell me the same blatant >>> lie, that the device does not exist: >>>=20 >>> # fsck -y /dev/ada1d >>> Can't open /dev/ada1d: No such file or directory >>>=20 >>> # mount /dev/ada1d /mnt >>> mount: /dev/ada1d: No such file or directory >>>=20 >>> Any suggestions? Thank you! Yours, >>=20 >> Custom kernel? If so, try booting GENERIC. Might be that a support fs >> option is missing. >=20 > This is most likely a stray bsd label which appeared in the first = (second ?) > block of the disk due to some pecularities of old partitioning tools. > Note the absence of the 'sN', i.e. MBR partition, between raw disk = name > and bsd slice. Some time at 9 or 10 lifetime priorities changed due = to > switch to gpart. >=20 > I do not remember how this was worked around, most likely by zeroing = second > block of the disk. Of course, it is better to do the experiment on a = copy > if the original is suspected to contain a useful information. All of mine are old, and probably in =E2=80=9Cdangerously dedicated=E2=80=9D= mode. Is there any reason that we=E2=80=99re not backwards-compatible or is it = just something that was not tested? I guess I could boot a 9.x live CD, but that would be kind of sad and = make me feel like a Linux user. :) C > _______________________________________________ > freebsd-fs@freebsd.org <mailto:freebsd-fs@freebsd.org> mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs = <https://lists.freebsd.org/mailman/listinfo/freebsd-fs> > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org = <mailto:freebsd-fs-unsubscribe@freebsd.org>"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1D679F0E-49BB-4B7A-9D41-E03D480A394E>