System BackupRestore
Dances With Crows
I don't quite yet have this down to a science and I've only recently started learning about how dual-multi-boot systems function and the part GRUB and it's 3 stages (1, 1.5 ,2) plays into all this. While I can't give you the particulars of what-how you might obtain your goals, I can impart some info...
AFAIK; In ATA-IDE-EIDE HDDs - The MBR-MPT 1 and 2 lives on CHS (0,0,1) - Cylinder0, Head0, Sector1. Also residing in this first sector are the Master Parbreastion Tables (MPT). Sectors are typically 512 Bytes.
ATA-IDE Drives can contain up to a total of 4 Primary parbreastions, -or- 3 Primary and 1 Extended parbreastion....(for a total of 4 Parbreastion Tables).
Pete -- You'll get quicker and better help if you omit your guesses about underlying causes. Instead, leave the diagnosis to us. Hoping not to sound too...
That's all there is room for in this first Sector. The one, and only one possible "Extended" parbreastion can be sub-divided into "Logical Drives" (winspeak = Drive Letters).
It seems from what I've been able to learn about GRUB over these last few weeks, that (please correct my errors, if found);
* Stage 1 2 refers to the part that is residing in the 1st 440 bytes of the HDD, (aka the MBR, aka Boot Code). * Stage 1.5 refers to the GRUB "entry(s)" in the Parbreastion Tables - the last 64bytes of the first Sector. * Stage 2 refers to the GRUB files found inboot-grub-grub.conf andboot-grub-menu.lst
There are some terms with which I am not yet comfortable in attempting to define - these include, but are not limited to; * BootStrap Loader * BPB (BIOS Parameter Block) * BF-BPB (Big FAT BIOS Parameter Block) - refers to FAT32 parbreastions
How these terms and their functions all interact with one another is yet another uncomfortable area as of yet....to wit, I shall withhold comment.
Note; What makes it possible to use a DOS command such as FDISKmbr and to have this command Rewrite the MBR, without altering the Parbreastion tables, relies upon the fact that the first 440 bytes ONLY are overwritten anew, the last 64bytes (MPT) are untouched by this command. Hence, one can restore a new MBR, without altering the MPT.
To "read each line exactly...", I agree that's as good as it gets in ksh. However, null bytes in input will cause interesting results (read may return...
See these screenshots for an idea of what data exists, and how it looks in the MPT, and more info;
huh, seems i've got a little reading to do :-)
1 Master Boot Record Master Parbreastion Tables -- the MBR occupies the first 440 bytes of the available 512 bytes - there's 6-8 bytes used by NTFS 5.x, otherwise they're empty(?) - and then there's the 2 "Active" signature bytes, written as (0xAA55), read as (55AAh). The MPT resides in the 'almost' last 64 bytes of that same first Sector.
Per Peter T. Breuer: Haven't touched it yet. It already has the "User" option. Unfortunately I cannot show it here...
================================================================ Layout of Master Boot Record
============================= ============================= 4 byte disk serial number (Used by Windows 2000 2 bytes null (0) and newer.) ============================= 16 byte parbreastion table entry ============================= 16 byte parbreastion table entry ============================= 16 byte parbreastion table entry ============================= 16 byte parbreastion table entry ============================= 2 byte MBR signature (0xAA55) =============================
2 MBR-MPT are better explained; above table taken from
see GRUB;
hth
Ubundu: Doing something securitywise with it's parbreastion 284
Linux groups from Newsgroups