From owner-freebsd-bugs Tue Mar 28 21:25:48 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA21697 for bugs-outgoing; Tue, 28 Mar 1995 21:25:48 -0800 Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id VAA21691; Tue, 28 Mar 1995 21:25:46 -0800 Received: from localhost (localhost [127.0.0.1]) by precipice.shockwave.com (8.6.11/8.6.9) with SMTP id VAA01190; Tue, 28 Mar 1995 21:25:09 -0800 Message-Id: <199503290525.VAA01190@precipice.shockwave.com> To: "Jordan K. Hubbard" cc: freebsd-bugs@freefall.cdrom.com Subject: Re: kern/280: new slice manager totally confused about old slice disks In-reply-to: Your message of "Tue, 28 Mar 1995 19:23:25 PST." <4104.796447405@freefall.cdrom.com> Date: Tue, 28 Mar 1995 21:25:09 -0800 From: Paul Traina Sender: bugs-owner@FreeBSD.org Precedence: bulk > 3) Oh where oh where has my MSDOS partition gone? Oh where oh where > can it beeeeee? Try copying the new MAKEDEV over and doing a ./MAKEDEV sd0, then try: mount -t msdos /dev/sd0s1 /dos Assuming, of course, that slice 1 is the DOS partition. This is actually a very GOOD part of the change and I'm happy that we have it. It will make auto-detecting and mounting the DOS partition from the install much easier (I can just look to see what partition is a DOS partition and then mount the corresponding slice). Aha, ok, this worked for me, I now understand a lot more about the slice scheme (took only 30 seconds wall clock time and 1 second CPU time). I would suggest documenting the living hell out of this. The gratuitous kernel printfs when accessing the label are a bit much, do they only happen when booting in verbose mode? sd0s1: start 32, end = 511999, size 511968: OK sd0s4: start 512000, end = 3514367, size 3002368: OK sd0: rejecting partition in BSD label: it isn't entirely within the slice sd0: start 512000, end 3514367, size 3002368 sd0d: start 0, end 3514367, size 3514368 sd0: rejecting partition in BSD label: it isn't entirely within the slice sd0h: start 32, end 511999, size 511968 sd1s1: start 32, end = 819199, size 819168: OK sd1s2: start 819200, end = 2041855, size 1222656: OK sd1s5: start 819232, end = 2041855, size 1222624: OK sd0s1: start 32, end = 511999, size 511968: OK sd0s4: start 512000, end = 3514367, size 3002368: OK sd0: rejecting partition in BSD label: it isn't entirely within the slice sd0: start 512000, end 3514367, size 3002368 sd0d: start 0, end 3514367, size 3514368 sd0: rejecting partition in BSD label: it isn't entirely within the slice sd0h: start 32, end 511999, size 511968 bpf: lo0 attached bpf: tun0 attached sd0s1: start 32, end = 511999, size 511968: OK sd0s4: start 512000, end = 3514367, size 3002368: OK sd0: rejecting partition in BSD label: it isn't entirely within the slice sd0: start 512000, end 3514367, size 3002368 sd0d: start 0, end 3514367, size 3514368 sd0: rejecting partition in BSD label: it isn't entirely within the slice sd0h: start 32, end 511999, size 511968 sd1s1: start 32, end = 819199, size 819168: OK sd1s2: start 819200, end = 2041855, size 1222656: OK sd1s5: start 819232, end = 2041855, size 1222624: OK sd1s1: start 32, end = 819199, size 819168: OK sd1s2: start 819200, end = 2041855, size 1222656: OK sd1s5: start 819232, end = 2041855, size 1222624: OK sd1s1: start 32, end = 819199, size 819168: OK sd1s2: start 819200, end = 2041855, size 1222656: OK sd1s5: start 819232, end = 2041855, size 1222624: OK sd1s1: start 32, end = 819199, size 819168: OK sd1s2: start 819200, end = 2041855, size 1222656: OK sd1s5: start 819232, end = 2041855, size 1222624: OK sd1s1: start 32, end = 819199, size 819168: OK sd1s2: start 819200, end = 2041855, size 1222656: OK sd1s5: start 819232, end = 2041855, size 1222624: OK I'm going to try writing out the new boot blocks, now that I understand what things should be doing a little better. This is not going to be fun to support, but I have to admit that it's far nicer than the old organization. Kudos to all.