John wrote:
On Fri, Jan 22, 2010 at 04:35:21PM -0600, John wrote:
On Fri, Jan 22, 2010 at 11:01:02AM -0600, John wrote:
On Fri, Jan 22, 2010 at 08:09:50AM -0600, John wrote:
On Fri, Jan 22, 2010 at 07:27:56AM -0600, John wrote:
On Fri, Jan 22, 2010 at 06:36:14AM -0600, John wrote:
On Fri, Jan 22, 2010 at 08:16:59PM +0800, Fbsd1 wrote:
John wrote:
On Thu, Jan 21, 2010 at 10:25:26PM +0800, Fbsd1 wrote:
John wrote:
On Thu, Jan 21, 2010 at 04:38:22PM +0800, Fbsd1 wrote:
John wrote:
I've tried the "modern BIOS" geometry and the "255 head" geometry.
I've ensured that the first slice (boot slice) is smaller than 1.5
Gb.  I've tried to figure out what the BIOS thinks the geometry
is, but it doesn't seem to want to tell me.  At least, I can't find
it in the BIOS menu anywhere.  When I boot from the CD-ROM with
the 255 head geometry, though, it complains about the disk geometry,
saying 16h,63s != 255h,63s or something like that - it flies by
pretty fast (is there a way to go back and see that from the CD-ROM
"boot only" boot?).

I'm using the "Standard" boot manager, and the entire disk is devoted
to FreeBSD.

System
BIOS version  PT84510A.86A.2004.P05
Processor Type: Intel Pentium 4
Processor speed: 2.20Ghz

Memory: 512Mb

Disk: Primary IDE Master ST380021A (Seagate Barracuda ATA IV 80Gb)
Primary IDE Slave: IOMega ZIP 250
Secondary IDE Master: Sony CD-RW CRX19 (what I boot from to install)
Secondary IDE Slave: DVD-ROM DDU1621

Boot sequence:
1) ATAPI CD-ROM
2) Hard Drive
3) "Removable Dev."

"Modern BIOS" geometry: 155061/16/63 for ad0
"calculated" geometry: 9729/255/63 for ad0

ad0s1 start=63, size=2875572
ad0s2 start=2875635, size=10217340
ad0s3 start=13092975, size=143203410
unus  start=156296384, size=5103

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

Suggestions, please?  I'm making zero headway right now. :(
What version of FreeBSD are you running????
Well, yes, I suppose that would be a good bit of information!

What I'm *TRYING* to run is 8.0.  It seems to install successfully
(of course - after doing all that), but then when I try to boot
from the hard drive, I see an otherwise-blank screen that says:


Invalid partition table


and that's as far as it goes!

_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
There are reports of this sort of thing caused by 8.0 fdisk when doing a install from scratch over a hard drive that all ready has an older version of Freebsd installed on it.

The solution is to force the scratching of the MBR on the disk first before running sysinstall fdisk.

Boot a LiveFS CD, then at a root prompt do:

sysctl kern.geom.debugflags=16  and:

dd if=/dev/zero of=/dev/adx oseek=1 bs=512 count=1

where x equals your drive number.
OK.  I did exactly that.  I confirmed that the second 512 bytes were zero
by doing a dd if/dev/ad0 bs=512 count=2 | od -c
and everything from 001000 through 002000 was zero.

But I still got "Invalid partition table" after the installation.

I guess I should set up one of my other systems as a local mirror.
I've done the installation so many time already, and it looks like
I'm not done yet!
On the 8.0 fdisk/MBR subject.
Doing dd if=/dev/zero of=/dev/adx oseek=1 bs=512 count=1 was the
solution from another post to the list with subject 'SunFire X2100
fails'. Here is another post that gives more details
http://www.freebsd.org/cgi/getmsg.cgi?fetch=322687+326879+/usr/local/
www/db/text/2009/freebsd-questions/20091227.freebsd-questions

It seems in 8.0 gpart was introduced and a change was made to fdisk to
support its sector o mbr format. 8.0 fdisk and disklabel are now broken.

Searching the list archives may shed more light on your problem.
Hmmm.  This seems to describe a case where fdisk fails to change
the slice table.  That is definitely not my case.  The changes
certainly get made.  The next time I go to retry the installation,
it has the information I gave it the previous time.  I suppose it is
possible that it is putting it (and reading it) in the wrong location,
which is why the MBR throws up.

The problem is that I have a finite (and smallish) amount of time
in which to solve this.  It seems like the most expedient route
forward at this point may be to try to install 7.2 and see how
that goes.
OK - well, I just tried with 7.2.  I got exactly the same results.
After what seems like a successful installation, I try to boot from
the hard disk and get "Invalid partition table."  Should I try Boot
Manager?  Could that make a difference?  Is it possible that this
combination of BIOS, processor, disk drive, etc., just isn't going
to to do for me?  I can't just keep throwing hours at this problem.
--

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.

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?

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?

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?

Well, better it happen to me than someone from another community who is
trying us out for the first time...
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.

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)?

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?

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.

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?

Having not heard anything, I proceeded first with my BootMgr modifed
partition table which had only the first partition marked active.

It worked.

So - then - since I had nothing invested in the system other than
an installation (one of many), so I decided to try my synthesized
"Standard" boot record (now with just one active slice/partition).

It worked!

No more "Invalid partition table".

So - I believe that my theory is correct.

1) The FreeBSD-supplied "Standard" boot manager will report
   "Invalid partition table" and stop if there is not exactly
   1 slice/partition marked "Active" (bootable).
2) The 7.2 and 8.0 installation processes (sysinstall fdisk)
>    will mark all FreeBSD slices/partitions as "Active" (bootable),
   rendering the system unbootable with the "Standard" boot manager
   if there is more than one FreeBSD slice / partition.

I have also discovered that BootMgr will boot a partition whether or not
it is marked as active, so it wouldn't be necessary to mark ANY
of them active for BootMgr's sake.  It may even be that BootMgr uses
that flag to indicate the last one booted, but that's only supposition
on my part.

I believe that there is room for improvement here.

What you have described it how things are designed to work. Your problem is the way you configured your slices. I think your understanding of freebsd slices/partitions verses msdos partitions is where the problem is.

Your stated you have this configuration
 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

This is not how Freebsd is designed to work.
This is incorrect architecture.
The disklabel pgm of sysinstall is used to allocate file systems within the slice. The correct layout to achieve your desired structure.
 ad0s1a / 384Mb
 ad0s1b SWAP 1Gb
 ad0s1d /var 512Mb
 ad0s1e /tmp 384Mb
 ad0s1f /usr 1Gb
 ad0s1g /mail 2Gb
 ad0s1h /ports 1Gb
 ad0s1i /mysql 4Gb
 ad0s1j /home 50Gb
 ad0s1k /src 3Gb
 ad0s1l /obj 3Gb
 ad0s1m /extra 8483Mb

The problem with this layout is all the sub-directories under /user are coded in the make port compile process and in sendmail, and mysql. You are creating a can of worms changing the default directory tree layout.

What goal are you trying to achieve by doing this?
If you continue with port install you will see what i mean?



_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Reply via email to