"Invalid partition table" after installation (GOOD NEWS!)

[Ian Smith]

In freebsd-questions Digest, Vol 294, Issue 12, Message 19
On Fri, 22 Jan 2010 16:35:21 -0600 John <john at starfire.mn.org> 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:
 > <UNUSED>
 > 
 > 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:
 > <UNUSED>
 > 
 > 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 at 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