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
-- 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: > > 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: >> >>> Hello! >>> >>> Going through older hard drives, I found one that still seems to work >>> and was curious, what's on it. The OS -- 12.1-STABLE -- sees it find. >>> The disklabel seems sane (except for the number of partitions): >>> >>> # /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 >>> >>> 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: >>> >>> # fsck -y /dev/ada1d >>> Can't open /dev/ada1d: No such file or directory >>> >>> # mount /dev/ada1d /mnt >>> mount: /dev/ada1d: No such file or directory >>> >>> Any suggestions? Thank you! Yours, >> >> Custom kernel? If so, try booting GENERIC. Might be that a support fs >> option is missing. > > 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. > > 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 “dangerously dedicated” mode. Is there any reason that we’re 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>
