[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

bios - Re: GRUB problem (long, description of BOOT)



hi ya mike

On Tue, 27 Sep 2005, Mike McCarty wrote:

> > 
> > the "tracking info" is dependant on the filesystem
> 
> It is not.

i beg to differ ... different fs has different disk
structure to tune itself for various things to make
it better or worst than other fs

> It is used by the uController on the disc itself
> to servo.

the disk controller on the disk does its magic too
but that is 1 level lower than the track info needed
by the fs 

the disk controller also does all the bad-block remapping
so that the fs thinks it has a clean 100GB of disks
even if its using 110GB of actual physical space

> A FS format should not disturb the low level
> format.

no it doesne't, but it uses that info in conjunction
with what it needs to be faster/better

> Anyone who redoes the low level format is taking
> his figurative life into his own hands.

those are the folks that insist on using "dd"

semi proof:
 
	a) partition and format with xfs your test disk  ( /dev/hdc ) 
	   with your favorite too
		let's say test disk is all xfs and 8 partitions

	b) use dd if=/dev/MasterDisk of=/dev/hdc
		lets say MasterDisk is reiserfs

	after the dd, you have lost all info about /dev/hdc
	and the "test disk" is now a clone of MasterDisk
	( the test disk is now 1 partition and reiserfs )

	c) mark some blocks as bad with "badblock" command
	and see what dd does to those sectors when you copy
	one disk to another
 
> > some intermingle track info ( aka servo data ) with data
> 
> Not without changing the ROM contained on the disc.

maybe there is a difference in what you call track info
and what i'm calling track info ..
	servo data vs meta-data vs ??-data

	servo data is on one platter as yu say,
	OR interspersed amongst each track ( not on one platter )
 
	meta-data is for the ext3, xfs, jfs, dos, etc

> I'm afraid that dd cannot see that information, nor
> can it destroy it.

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

if the bad block is marked at the disk controller,
than yes, dd cannot change those badblocks and servo info

bad blocks is part of servo data ?? and is managed
in various wys

> > 
> > fdformat or superformat ( low level formatting ) is done 
> > separately from the filesystem formatting
> 
> Yes, fdformat does the first two levels, but not the third.

yup
 
> > 	mkdos, format a:, mkfs.vfat, ...
> 
> Which does the third level. (Though not the fourth.)

yup
 
> There is only one MBR per physical disc. Each partition has
> a BR, not an MBR.

okay ... i'll bite with the mbr vs br
 
> > not 100% sure but we all know any of these are bootable, each having
> > enough info to make it bootable 
> > 	( maybe a difference in terminology )
> > 	/dev/hda1	windoze
> > 	/dev/hda2	debian
> > 	/dev/hda3	redhat
> > 
> > 	each partition has its own MBR allowing it to be bootable
> 
> I'm afraid you have some misconceptions yourself.

just a difference of vocabulary of mbr or br per your correction

> > important to note that its active, but is NOT required to boot
> 
> Depends on what boot program one is using. Since the current
> context is Windows, that is the context I used.

yup... i'm using lilo/grub context... nto sure if loadlin needs the 
active boot flag
 
> > the boot sequence is configurable in the BIOS setting
> 
> It may or may not be configurable in the ROM boot program
> settings.

sure it is ... always have been since 1979 ...

bootsequence:
	floppy
	cdrom
	hda
	hdc
	usb-stick
	network

	- mix and match as you need and change it

	- it is also stored in nvram or flash portion of the bios rom

	- you know that once you change the boot sequence it
	always uses that boot sequence .. and you do NTO have to
	tell it again to boot from usb-stick or whatever you list first 

> > 	512 bytes
> > 	  2 bytes for boot flag
> > 	 64	4 partitons of 16 bytes each
> > 	----
> > 	446	is the actual mbr 
> 
> As I said, some consider the PT to be separate from the MBR,
> some consider it to be part of the MBR.

yup...
 
c ya
alvin



Reply to: