On 10/21/07, William Case <billlinux@xxxxxxxxxx> wrote:
> Hi Jacques et al;
>
> On Sun, 2007-10-21 at 17:56 -0400, Jacques B. wrote:
> [snip]
> > > 2) How BIOS originally writes disk and partition locations to the MBR
> > > or after installing a new harddisk. It must have some BIOS info even if
> > > 'fdisk', 'parted' or 'mkfs' are used as part of the installation. I
> > > don't know if these are even involved but I plan to check.
>
> I believe that the easiest way to get at what is happening regarding the
> MBR is to figure out what happens with a virgin hard drive. So...
>
> If I have just installed a new drive on a new machine, how do I
> configure the drive (before partitioning) so that it has a MBR. Suppose
> I am offering customers an option of Operating Systems that will be
> installed after they make their choice of systems. At that time I will
> install the appropriate partitions and file systems.
To ensure the drive is indeed clean, I'd wipe it with dd first. dd
if=/dev/null of={hard disk you want to wipe}. Just in case the drive
was either used at some point by the techs at the business where you
bought it, or the manufacturer in question doesn't wipe them clean,
whatever.
>
> Can I put a MBR on a drive without formatting the rest?
I may be wrong, but I don't believe you can, other than if you were to
dd the first 446 bites off an existing drive with a MBR onto the new
drive. But that wouldn't achieve any benefit that I know of.
>
> If so, how do I do it and what program do I use? fdisk or parted have
> no mention of a MBR. MS-fdisk has a hidden /mbr switch for reinstalling
> or patching a broken MBR, but that is all I can find.
The MBR would be populated by the OS being installed. It would
install the boot code it needs to point to its kernel. Again I stand
to be corrected but I am reasonably certain on that.
>
> > > 3) What code system it uses to designate disks and partitions. I have
> > > found three or four sites that break down the meaning of binary code bit
> > > by bit. That needs study.
>
> If you are interested; a detailed bit by bit explanation:
> "MBR"
> http://www.ata-atapi.com/hiwmbr.htm
>
> "Part Table"
> http://www.ata-atapi.com/hiwtab.htm
>
> Originally suggested by Mike Wright.
>
> I have an additional 10 - 20 pages cut and pasted as explanations; from
> poweron to init. I would be glad to share it in its raw form; or send
> you what I've got after I have cleaned it up into something readable.
If you want to either send me the raw data, or better yet the URL
where you got the data from so if I use it I can quote the source that
would be great.
>
> > Thanks Bill. I re-googled the Linux boot process and one of the
> > references I found a while back that I re-found is:
> > http://www.ibm.com/developerworks/library/l-linuxboot/index.html
> >
> > Being from IBM it has more credibility than an individual's personal
> > site (not to devalue the latter, just that one must always assess the
> > credibility of online sources/resources).
> >
> > Another is from RedHat at
> > http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-boot-init-shutdown-process.html
> > I don't believe I had read that one. Must go back and read that when
> > I have to get my head back into the boot process.
> >
> > I also came across http://oldfield.wattle.id.au/luv/boot.html today
> > which I hadn't looked at before. It's very simplified. I haven't
> > scrutinized it yet for accuracy and I don't recognize the domain as a
> > trusted source so take it accordingly.
> >
> > And this one http://itreviews.blogspot.com/2006/05/linuxs-boot-process-explained.html
> > is a personal blog. Again we must take it with a grain of salt.
> > There are a number of feedback postings on it which can help either
> > validate or question some of the blogster's facts.
> >
> Checked out those sites. Most are repetitive and don't really drill down
> to the hardware level, where after all, for boot loading most of the
> action is taking place. There is nothing very abstract about this
> process. Going up an abstraction layer obfuscates, not clarifies,
> MBRs.
>
>
> --
> Regards Bill
>
> --
> fedora-list mailing list
> fedora-list@xxxxxxxxxx
> To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
>
