From owner-freebsd-questions Mon Mar 27 11:40:50 2000 Delivered-To: freebsd-questions@freebsd.org Received: from aragorn.neomedia.it (aragorn.neomedia.it [195.103.207.6]) by hub.freebsd.org (Postfix) with ESMTP id 6C53C37B9D6 for ; Mon, 27 Mar 2000 11:40:46 -0800 (PST) (envelope-from bartequi@neomedia.it) Received: from bartequi.ottodomain.org (ppp1-pa5.neomedia.it [195.103.207.113]) by aragorn.neomedia.it (8.9.3/8.9.3) with SMTP id VAA02721; Mon, 27 Mar 2000 21:40:12 +0200 (CEST) From: Salvo Bartolotta Date: Mon, 27 Mar 2000 20:42:04 GMT Message-ID: <20000327.20420400@bartequi.ottodomain.org> Subject: Re: Accessing FreeBSD 3.4-STABLE filesystems from4.0-STABLE... To: Brad Knowles , freebsd-questions@FreeBSD.ORG In-Reply-To: References: X-Mailer: SuperCalifragilis X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 3/27/00, 6:30:08 PM, Brad Knowles wrote regarding Re:= =20 Accessing FreeBSD 3.4-STABLE filesystems from4.0-STABLE...: > At 9:13 AM -0800 2000/3/27, Julian Elischer wrote: > > in a 4.0 kernel, teh block device doesn't exist, you always use the= > > character device, > > so it was renamed so that /dev/da0s1a is teh name for the char devi= ce > > but if you are using a device on a 3.4 disk it refers toi the block= =20 device > > (which isn't in a 4.0 kernel) > This is a 4.0-STABLE system: > $ cd /dev && ls -la da[01]s1? > crw-r----- 1 root operator 13, 0x00020000 Mar 20 09:38 da0s1a > crw-r----- 1 root operator 13, 0x00020001 Mar 20 09:38 da0s1b > crw-r----- 1 root operator 13, 0x00020002 Mar 20 09:38 da0s1c > crw-r----- 1 root operator 13, 0x00020003 Mar 20 09:38 da0s1d > crw-r----- 1 root operator 13, 0x00020004 Mar 20 09:38 da0s1e > crw-r----- 1 root operator 13, 0x00020005 Mar 20 09:38 da0s1f > crw-r----- 1 root operator 13, 0x00020006 Mar 20 09:38 da0s1g > crw-r----- 1 root operator 13, 0x00020007 Mar 20 09:38 da0s1h > crw-r----- 1 root operator 13, 0x00020008 Mar 18 21:45 da1s1a > crw-r----- 1 root operator 13, 0x00020009 Mar 18 21:45 da1s1b > crw-r----- 1 root operator 13, 0x0002000a Mar 18 21:45 da1s1c > crw-r----- 1 root operator 13, 0x0002000b Mar 18 21:45 da1s1d > crw-r----- 1 root operator 13, 0x0002000c Mar 18 21:45 da1s1e > crw-r----- 1 root operator 13, 0x0002000d Mar 18 21:45 da1s1f > crw-r----- 1 root operator 13, 0x0002000e Mar 23 12:34 da1s1g > crw-r----- 1 root operator 13, 0x0002000f Mar 18 21:45 da1s1h > This is a different 3.2-RELEASE system: > $ cd /dev && ls -la da[01]s1? > brw-r----- 1 root operator 4, 0x00020009 Jul 7 1999 da1s1b > brw-r----- 1 root operator 4, 0x0002000c Jul 28 1999 da1s1e > brw-r----- 1 root operator 4, 0x0002000d Jul 29 1999 da1s1f > It seems to me like I've got the correct character devices > created under 4.0-STABLE, and yet there still isn't a valid > filesystem that fsck can find on /dev/da0s1a, which I know to be > false because I can reboot the machine and bring it up in 3.4-STABLE > on that disk. > So, I'll repeat the question -- what do I have to do in order to= > get 3.4-STABLE disks readable under 4.0-STABLE, and/or 4.0-STABLE > disks readable under 3.4-STABLE? Dear Brad Knowles, just my two cents to the general issue. From 4.0-CURRENT slice (yet to upgrade to 4-STABLE), I can happily=20 access my (IBM) *IDE* "3-STABLE" disks as adNsM (e.g. ad2s2e.); from=20 my 3-STABLE slice, I can access my (IBM) *IDE* "4.0-CURRENT" disks as=20 wdNsM (e.g. wd0s3f.) I do NOT have SCSI disks, so I can't tell anything about your specific=20 problem. However, although I need to access each other's IDE disks read-only=20 from either slice, I seem to understand that, at this stage, it should=20 be HARMLESS to access them read write (at least, from 4.0-CURRENT or=20 -STABLE). If any of such operations is NOT safe, I hope somebody will jump in=20 the discussion and tell us :-) HTH, Salvo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message