From owner-freebsd-questions@FreeBSD.ORG Sat Jan 23 06:42:36 2010 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16FFF106568D for ; Sat, 23 Jan 2010 06:42:36 +0000 (UTC) (envelope-from john@dexter.starfire.mn.org) Received: from dexter.starfire.mn.org (starfire.skypoint.net [173.8.102.29]) by mx1.freebsd.org (Postfix) with ESMTP id D154D8FC1A for ; Sat, 23 Jan 2010 06:42:35 +0000 (UTC) Received: (from john@localhost) by dexter.starfire.mn.org (8.11.3/8.11.3) id o0N6gQ643723; Sat, 23 Jan 2010 00:42:26 -0600 (CST) (envelope-from john) Date: Sat, 23 Jan 2010 00:42:26 -0600 From: John To: Ian Smith Message-ID: <20100123004226.C42331@starfire.mn.org> References: <20100122235448.A229410656EE@hub.freebsd.org> <20100123161628.I14027@sola.nimnet.asn.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20100123161628.I14027@sola.nimnet.asn.au>; from smithi@nimnet.asn.au on Sat, Jan 23, 2010 at 05:34:10PM +1100 Cc: freebsd-questions@freebsd.org, Randi Harper Subject: Re: "Invalid partition table" after installation (GOOD NEWS!) X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 06:42:36 -0000 On Sat, Jan 23, 2010 at 05:34:10PM +1100, Ian Smith wrote: > In freebsd-questions Digest, Vol 294, Issue 12, Message 19 > On Fri, 22 Jan 2010 16:35:21 -0600 John wrote: > [..] > > > > OK! Well! Good news! After a sort. > > > > > > > > I switched to BootMgr, and it came right up with 8.0! > > > > > > > > Slight downside - extra prompt during boot, and of course, it > > > > offers me all three slices, when I only need to boot from > > > > one. > > See boot0cfg(8); you can specify which slice/s are offered by the boot > menu, from none to four, and you can specify the delay in ticks (~1/18 > second). I'm not sure if 0 is a valid delay, but 1 is not very long. > > > > > Is that's what's wrong with "Standard" MBR? Are all three FSD > > > > partitions (type 165) marked bootable and that's upsetting it? > > > > Can I change it so only one of them is marked bootable? > > See fdisk(8) -a switch. I expect this would clear other active flags. > > > > > Anyway, it appears that there is a problem with the "Standard" MBR > > > > boot. I don't think I was doing anything that unnatural - I wanted > > > > quite a few file systems, so I used multiple slices, both to keep > > > > the boot slice below 1.5Gb and to be able to support all the file > > > > systems I wanted, and maybe that's what upset it. I don't know. > > > > All I know is that Standard MBR didn't work, and BootMgr does. > > > > > > > > I'm willing to spend SOME time trying to debug / fix this for the > > > > good of the community and the next poor sucker who comes along > > > > behind me, but I need to move somewhat quickly. I actually plan > > > > to use this machine! > > > > > > OK - my current best theory is that if the Standard boot manager > > > is faced with anything other than exactly 1 bootable slice (partition > > > to it), it defaults to "Invalid partition table." I'll bet anyone > > > lunch that this is true. Any takers? > > Perhaps. Certainly only one should be set active at boot time, either > statically or by being chosen by a boot menu. > > > > I'll test my theory tonight and let you all know how it turns out. > > > If this is true, then we should at least post some warnings, if not > > > actually fix the installation process so that if you choose "Standard," > > > it helps ensure that you have one and only one bootable slice/partition! > > > > > > Whaddaya think? > > sysinstall (fdisk) lets you toggle the active flag while slicing the > disk. You're supposed to have set one (and only one) active there, and > you've already chosen which slice you want to install to, though I agree > that selecting Standard boot sector might check for one active slice. > > > > Well, better it happen to me than someone from another community who is > > > trying us out for the first time... > > All good grist for the achives .. > > > OK, so here's the update so far. It was, indeed, the case that > > all three slices (partitions) were marked as active (bootable), to wit: > > The data for partition 1 is: > > sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) > > start 63, size 2883825 (1408 Meg), flag 80 (active) > > beg: cyl 0/ head 1/ sector 1; > > end: cyl 1023/ head 15/ sector 63 > > The data for partition 2 is: > > sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) > > start 2883888, size 10224144 (4992 Meg), flag 80 (active) > > beg: cyl 1023/ head 255/ sector 63; > > end: cyl 1023/ head 15/ sector 63 > > The data for partition 3 is: > > sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) > > start 13108032, size 143193456 (69918 Meg), flag 80 (active) > > beg: cyl 1023/ head 255/ sector 63; > > end: cyl 1023/ head 15/ sector 63 > > The data for partition 4 is: > > > > > > So - I used dd to make a copy of the MBR, and wrote a C program to > > interpret it and clear the other two flags. Once I was satisfied > > with that, I used the sysctl from earlier in the thread (which I > > assume allows me to actually change things) and dd to put the > > modifed mbr back in place on sector 0. Now fdisk reports > > The data for partition 1 is: > > sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) > > start 63, size 2883825 (1408 Meg), flag 80 (active) > > beg: cyl 0/ head 1/ sector 1; > > end: cyl 1023/ head 15/ sector 63 > > The data for partition 2 is: > > sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) > > start 2883888, size 10224144 (4992 Meg), flag 0 > > beg: cyl 1023/ head 255/ sector 63; > > end: cyl 1023/ head 15/ sector 63 > > The data for partition 3 is: > > sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) > > start 13108032, size 143193456 (69918 Meg), flag 0 > > beg: cyl 1023/ head 255/ sector 63; > > end: cyl 1023/ head 15/ sector 63 > > The data for partition 4 is: > > > > > > So - there's only ONE active partition, but it still has bootmgr. > > Well I'm sure it was fun writing a program, but fdisk -a should do :) > > > I have used dd and cat to manufacture a new boot record from > > /boot/mbr and the parition (slide) table I've modified, > > and I'm tempted to put THAT in place over this one, but I'm > > afraid of what that might mean - are there other changes > > to the structure of the disk that I need to make to switch from > > BootMgr to the "Standard" MBR? Even if my synthesized MBR > > is correct, is it going to run into trouble at the next step? > > Does it need a different "level 1" boot code? Or should I just > > use "fdisk -b /boot/mbr" rather than my synthesized mbr? > > Will that take care of all the linkages (if any)? > > fdisk -b /boot/mbr should work .. it doesn't mess with the slice table, > so now you have it how you want it, that should be fine. OTOH, perhaps > boot0cfg with zero slices offered would come to the same thing? > > boot0cfg -f will save your current boot sector, in case of accidents. > > > I still think that the ultimate solution is to CHANGE THE > > INSTALLATION PROCESS so that there is ONE and ONLY ONE > > active partition when the "Standard" mbr is used. Well, I'll > > make that an even more general statement - let's change the > > installation process so that ONLY THE FREEBSD PARTITION(s) > > CONTAINING /boot GET THE ACTIVE FLAG SET. There's nothing > > to boot otherwise, anyway, right? > > Yes, but consider systems having two or more versions of FreeBSD, using > a boot menu to choose which to boot. I know of one running 6-STABLE, > 7-STABLE, 8-STABLE and 9-CURRENT on one laptop, but I'm only running > 7-STABLE and 8.0-RELEASE on mine. All contain a /boot dir of course. > > > I'm not 100% sure how best to do this, but I have some ideas. I > > think it starts with having fdisk leave the flag off by default, > > and only turn it on for slices where it has loaded boot code, but > > maybe it's not that simple. > > Unless you choose to, fdisk (as run by sysinstall) doesn't mess with > slices other than the one you're working with. Whether it should is > another matter, I can't imagine all usage cases, but you'd want to run > suggested changes to fdisk by the right lists (maybe -hackers and -fs?) > > > My concern is that it sounds like someone is already working on > > fdisk / diskpart with an eye to replacing it, so maybe I'm > > working on a "zombie" problem that's already "walking dead." > > I have no interest in putting time and effort into that in > > such a case, but I'm very willing to help in this area if it > > will have some value. > > > > Open to suggestions here, folks - what do you say? > > > > John Lind > > john@starfire.MN.ORG > > Not wishing to sound unkind, but you might explore a bit more deeply > what fdisk and boot0cfg already offer. We hear something about ongoing > work on sysinstall and its potential replacement, and conversion to the > GEOM framework is underway, but you'd need to hunt out the right lists > and be running -CURRENT to be participating in the process, I expect. > > cc'ing Randi Harper, who's been working on sysinstall lately (and to > whom I still owe some mail about related matters) > > cheers, Ian Thanks, Ian! I'm very paranoid about fdisk, because I don't seem to be able to make it work on a file - it insists on messing with the disk. Quoting from above... > sysinstall (fdisk) lets you toggle the active flag while slicing the > disk. You're supposed to have set one (and only one) active there, and > you've already chosen which slice you want to install to, though I agree > that selecting Standard boot sector might check for one active slice. I didn't explicity tell it to set ANY of the slices/partitions to active/bootable. It did that all on its own. I would be happy to work with someone working on sysinstall. -- John Lind john@starfire.MN.ORG