Date: Sun, 24 Jan 2010 16:40:40 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: John <john@starfire.mn.org> Cc: freebsd-questions@freebsd.org, Randi Harper <randi@freebsd.org> Subject: Re: "Invalid partition table" after installation (GOOD NEWS!) Message-ID: <20100124135557.T14027@sola.nimnet.asn.au> In-Reply-To: <20100123004226.C42331@starfire.mn.org> References: <20100122235448.A229410656EE@hub.freebsd.org> <20100123161628.I14027@sola.nimnet.asn.au> <20100123004226.C42331@starfire.mn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 23 Jan 2010, John wrote:
> 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 <john@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.
I haven't checked the code, but that seems to be correct. For sure
setting one slice active in sysinstall's fdisk menu turns off another.
[..]
> > > > > 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 have checked the code :) and you are right; /boot/mbr aborts if more
than one slice is set active. I'm pasting from 5.5 sources, but have
checked this section vs 8.0 .. /usr/src/sys/boot/i386/mbr/mbr.s says:
# Scan the partition table looking for an active entry. Note that %ch is
# zero from the repeated string instruction above. We save the offset of
# the active partition in %si and scan the entire table to ensure that only
# one partition is marked active.
#
main: xorw %si,%si # No active partition
movw $partbl,%bx # Partition table
movb $0x4,%cl # Number of entries
main.1: cmpb %ch,(%bx) # Null entry?
je main.2 # Yes
jg err_pt # If 0x1..0x7f
testw %si,%si # Active already found?
jnz err_pt # Yes
movw %bx,%si # Point to active
main.2: addb $0x10,%bl # Till
loop main.1 # done
testw %si,%si # Active found?
jnz main.3 # Yes
int $0x18 # BIOS: Diskless boot
.. where err_pt prints 'Invalid partition table' and exits.
> > > > 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.
Someone owes you lunch, but I'm not sure it's me :) The question is how
all three slices you setup with sysinstall wound up having their active
flags set, which does seem a mystery. It's not the boot code's fault.
> > > > 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.
To be fair, if you read the help (F1) in sysinstall's fdisk section, it
makes the point that you should mark one slice active or select the Boot
Manager, and because of other usage cases (like allocating other slices
or disks post-install) sysinstall has to be very careful in assuming
what you're wanting to do. That said, marking each slice that you setup
as active without you having done so deliberately does seem wrong.
[..]
> > > 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?
Actually, no that's not right. fdisk -B updates the boot sector, -b
specifies which bootcode to use, /boot/mbr being the default anyway.
> > 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.
Well I wouldn't recommend using fdisk -f unless you're really certain
you know what you're doing with a configuration file. I see there's the
-p switch to write a formatted config file out from the current setup
(which wasn't in 5.5 anyway) so that's worth saving the output from for
restoration later, but really all you needed here is fdisk -a1 to set
slice 1 active (and clear any others).
Being paranoid is highly recommended with some fdisk options, but if you
use the -t switch you can try anything, nothing will be written to the
disk, and you get to see that interactively you get plenty of warning
before updating the boot sector. eg safely try 'fdisk -tv -a1 ad0'
See note in boot0cfg(8) about setting sysctl kern.geom.debugflags=0x10
to update the boot sector of a mounted disk; I'm pretty sure it applies
to fdisk in the same circumstances, though fdisk(8) doesn't mention it.
Personally I've always relied on sysinstall and more lately sade(8) to
do things like post-install config of other slices and/or BSD partitions
without trying to do the ikky cylinder and sector maths, but YMMV.
> 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.
Yeah, perhaps you'd enjoy finding that code in sysinstall and suggesting
a patch, bearing in mind possible other usage cases. Happy hunting!
BTW, fbsd1's assertion that you should have made all your partitions in
one slice rather than across three, is both wrong and right :) What
you're doing is certainly unconventional, but valid, though there may be
plusses and minuses in having so many fixed-size partitions:
> > >>>>> ad0s1a / 384Mb
> > >>>>> ad0s1d /usr 1Gb
> > >>>>> ad0s2b SWAP 1Gb
> > >>>>> ad0s2d /tmp 384Mb
> > >>>>> ad0s2e /var 512Mb
> > >>>>> ad0s2f /var/mail 2Gb
> > >>>>> ad0s2g /usr/ports 1Gb
> > >>>>> ad0s3d /home/mysql 4Gb
> > >>>>> ad0s3e /home 50Gb
> > >>>>> ad0s3f /usr/src 3Gb
> > >>>>> ad0s3g /usr/obj 3Gb
> > >>>>> ad0s3h /extra 8483Mb
Looks like an 80GB drive? A few points, given you know your own usage:
/ 384MB is small these days, more than one kernel rebuild with symbols
might lean on that. There's lately talk of changing suggested / size in
sysinstall from 512MB to 1GB, and/or moving symbols somewhere else.
/tmp 384MB could well be limiting too, depending on your usage. I tend
to link /tmp to /var/tmp or /usr/tmp myself, having been burned ..
Probably you'll want to link /var/db/mysql to your /home/mysql, as the
former is the default mysql dir and you won't want to mess with that.
3GB for /usr/src and /usr/obj is, um, very generous. On another slice I
recently built 7-STABLE and 'du -d1 /usr' has ~512MB /usr/src, bit over
1GB for /usr/obj, but over 2GB in /usr/local, over 3GB on my 8.0 system
with not a lot installed yet. Your /usr wouldn't take that at all,
unless you link (or mount) /usr/local somewhere else too.
In short, run 'du -d1 /usr' especially ('du -xd1' to not descend into
the mounts), and perhaps reconsider your partitioning in that light?
cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100124135557.T14027>