Re: bios - Re: GRUB problem (long, description of BOOT)
hi ya
On Wed, 28 Sep 2005, Mike McCarty wrote:
> You are obviously smart
> and intelligent, but you weren't THERE. I was.
i been playing with them removable 14" disk platters
and stripping um and reassemble um and stick it back
into the dg/dec/si washing machines
> > the disk controller on the disk does its magic too
> > but that is 1 level lower than the track info needed
> > by the fs
>
> Precisely my point. I guess I didn't make myself clear enough. I was
> talking about a low-level format, not a file system thing.
same here .. but never mind, not important ...
we both saying the same thingie ma jiggie
> No longer done by the disc controller. With the advent of
> Advanced Technology attachment (ATA) (incorrectly referred to by
> many as Integrated Drive Electronics [IDE]) drives, the intelligence
> is no longer on the controller board, but rather on the disc
> itself. Modern "controller" boards are just I/O expansion
> ports. The controller logic is now on the disc itself.
there's the disk controllers on the disk drive ..
there's the disk controllers on the motherboard ( ide card )
both can do the same work ... or some of the work ..
> No, dd cannot disturb the low-level format
i say it does ... simple experiment to see
bad blocks and track info go bonkers... when overwritten
by dd ...
- dd and gohost et.al. is low level format and copying
> That requires
> talking to the uC on the disc itself (usually), using
> proprietary commands.
unless you're refrring to disk controller firmware stuff is
yet even loower than low level format
> > servo data is on one platter as yu say,
> > OR interspersed amongst each track ( not on one platter )
>
> Yes, I'm talking about servo data, which cannot be seen
> by dd or any other normal (or even driver level) accesses.
i think we;re talking about the different kidns of servo
data ... created/maintained at different levels
and i'm not talking about file system junk either
but it doesnt matter ... my point is different
apps plays with different data .... and is NOT
jst the factory ( wd, maxtor, seagate ) that can
create these "servo data"
> > sure it can ... try it ... the servo data is gone
> > that track-1234 head-6 sector-47 is not longer
> > marked as bad block because dd overwrote it
>
> Certainly it can write to the "reserved" areas of the
> disc (I mean reserved by the file system).
you keep going to filesytem
there is reserved space for servo dta too as you noted
and that data can be over written by dd depending
on its purpose and where and when it is written
> But it cannot
> write to the servo area (which is used by the uC on the
> disc to ensure proper head alignment).
am not talking about the head alignment and gaps or anything
> Bad blocks and bad track info are used by different levels
> of the system.
bingo !!!... and written by different programs and firmware
and apps
> The bad blocks are a file level thing
no...
bad blaocks can also be marked as bad by the disk firmware
with whatever code it wants touse to indicate a bad
sector or bad track and which one is its replacement
> and
> can be modified or obliterated by dd, as you note. The bad
> track info and sector remapping is a low level construct,
> and cannot be modified by dd.
sure it can ... and that is my point ...
but that's where we disagree ... not a biggie ..
> The bad block information stored in the File Allocation Table
> (FAT)
don't care about that ... that is a file system issue ...
now low level servo data
> used by a low-level format. You may be confusing this information
> (not stored in a FAT for for non-FAT FS, naturally) used by the file
> system with the low-level bad track remapping.
nope ... not confusing fs related junk vs servo data..
> The servo tracks are used to supply the "weak force" used in
> automatic control of the head movement mechanism.
there are other things that is part of servo data ...
like gaps ... and other whacky stuff
> The older MFM and RLL drives used stepper motors and a wound
> band of steel to move the heads.
nobody uses mfs/rll anymore .. non-issue for dd
> > just a difference of vocabulary of mbr or br per your correction
>
> I've been formatting hard discs since 1984 when each level was
hee heee ... i been doing that since 1973... or sooner ... gotcha
including writing and debugging them silly disk controllers
on decs and dg ... and few other assorted junk ... long before
PCs came alone
> The boot record (aka boot sector) is contained on each volume.
> It contains the BIOS Parameter Block (BPB).
we been over all this .. and i agreed w/ ya about the difference between
with br vs mbr
> There has been in past some confusion of the terms BR, BPB, MBR, and PT.
yup... and 99.99% of the folks don't worry about the differences
> Well, I repeatedly used in my message the word "traditionally", which
> was *supposed* to be a hint that there are other ways of doing things.
yup...
> BUT, this guy has a problem with a Windows MBR on his disc not
> recognizing/using the boot procedure he wants.
windoze wwill overwrite grub/lilo ..and you cannot stop it
you wil have to reboot from knoppix and other standalone variations
to overwrite/fix windoze's mbr/br
> > sure it is ... always have been since 1979 ...
>
> Sir, the IBM PC wasn't *around* in 1979.
sure it was .... or its predessor ...
apple, kaypro, heathkit, etc,etc..
using the same "OS" and boot mechanism and crt, and tape
etc..etc.. and even punch cards
In 1979 the common machines
> used 8080, 8085, or Z80 processors, were built on S-100 boards,
yup ... and there was the 4040 and z8, f8, ... and discrete
cpu/alu/mmu/pio etc,etc
that one can build separately before the "all-in-one" 8080/6800
c ya
alvin
Reply to: