446642 dd mbr

OK, that should be a good workout. Do two 5 minute segments on the treadmill at 4, two more at 6 to get you aerobic activity up, then cool down with 5 minutes at 4 and 5 minutes at 2. So its 446642.

Or you can divide the numbers like this, 446, 64, 2. Add them up and you get 512. That must be some power of two (9, I suppose), so maybe this is really a computer thread. I guess it is really the number of bytes in a sector on a hard disk.

So here is what you could do with those numbers. Start out with a hard disk, as set aside a portion to dedicate to getting code running on it. IE, Boot It Up! Set aside some space to tell the computer where stuff lives on the hard drive (the partition table). And add a marker signifying the end of all this. So we would call the the Master Boot Record, or MBR. We could do this:

# bytes use

446 bootloader

64 partition table, tells us where partitions are on the hard disk

2 magic number to signify the end of this section, 55aa

The 64 bytes for the partition table is nice! By convention, there are only 4 entries allowed in the Master Boot Record to designate locations of drive partitions. So we need space for 4 descriptions. We have 64 bytes, so each entry gets to use 16 bytes to describe it.

But those numbers are not typical computer geek numbers. They are too simple. To be talking computereze, we have to learn to start counting at zero. So doing that, we can define the memory byte address of these things:

bootloader … | … partition table … |… signature (55aa)

(446 bytes) … |…… (64 bytes) ……. |.. .. (2 bytes) …..

start .. end … | … start …… end … | .. start … end

0 …. 445 ….. | …. 446 ……. 509 … | .. 510 ….. 511

So, armed with this knowledge, we could make a backup of the Master Boot Record of our hard drive, so we could reconstruct it in case it gets wiped out. It is important to realize that when people say a virus ‘destroys everything on your hard drive’, this is physically impossible to do with any speed at all. That would take many minutes, or maybe even an hour. What really is more likely is that it deletes the MBR, and you just have no way to boot. And you have lost track of where it is.

It is really easy to make a copy of the MBR on a floppy disk, using the dd command in Linux. You just put a spare floppy in the floppy drive, and use the dd command like this from the command prompt:

sudo dd if=/dev/hda of=/dev/fd0 bs=512 count=1 and hit enter. Give it your password to allow it to do this as root. Watch the little LED on the floppy, and you should see it come on as the MBR is written to the floppy.

Here is how to interpret this:

sudo -> super user do, means do this as the system administrator. Unix/Linux will not let a normal user issue the dd command that follows.

dd -> copy something somewhere using the instructions that follow

if -> what to copy, the input file. Here we copy starting at the beginning of the first hard drive device, /dev/hda.

of -> where to copy it to. Here we put it at the beginning of the first floppy drive, /dev/fd0. Note that is a zero, not the letter O. Also note we count the hard drives a, b, c etc, but we count the floppy drives 0, 1, 2 etc. So if you count your toes like this, you will likely have either ‘j’ toes, or ‘9′ toes.

bs=512 -> When you copy, do it using a block size of 512 bytes.

count=1 -> Copy only one block

But this should be all be put in persective. There is the old tale of the Berkeley/Stanford/your choice professor that told his engineering students that the person who knows how will always have a good job working for the person that knows why. So maybe we should know why, and by implication, why not.

First, the easiest way to lose all the data on your hard disk is to lose either the boot loader or the partition table. It is normally fairly easy to reinstall the boot loader, it is not easy to reconstruct a damaged partition table. It is a record of where things are on your hard drive. And they could be almost anywhere, depending on how your drive was configured. So by doing the dd thing above, we make ourselves a backup copy in case we get wiped out by a virus, or more likely in my case, I do it to myself somehow.

To put the MBR back, all we have to do is boot the computer with a bootable CD with minimal Linux tools, and issue the command again, only this time sending the data back. It would look like this:

sudo dd if=/dev/fd0 of=/dev/hda bs=512 count = 1

So in one easy stroke, we have taken our backup information and put it in the MBR, wiping out what was there, and presumably bad. Why else would we have done it?

So all this power should give you a warm fuzzy feeling; or give you a panic attack. If you are a normal user, spending most of your time on Google and YouTube, then feel warm and fuzzy.

If you are like me, and spend one days a week “updating” and adding new operating systems to your computer, and six days trying to fix how you just screwed it up, you will more than likely realize that you just overwrote your hard drive partition table with data from a week, or a month, or a year ago! Who knows how many times you have moved the partitions around since then? So unless you have been religiously making this backup, it is sure to wrong data in the MBR. Take gun, point at foot, pull trigger.

So you should think about what you are trying to do. If you are backing up the partition table, then go ahead and do all 512 bytes. But if you only want to backup the boot loader portion, then only do the first 446 bytes, using bs=446.

For many tons more information just Google ‘dd mbr’.

Or look here: http://www.dewassoc.com/kbase/hard_drives/master_boot_record.htm

An enigma – grub

Grand Unified Bootloader, that is grub. It can boot lots of operating systems on many different platforms. It is the default bootloader now for most, if not all, common linux distributions. Yet I say grub is brain-dead. That is not really a good description. What I should say is that grub is not well designed to keep your operating system boot code safe, secure, and reliable. Instead, it places it out in the middle of your hard drive, maybe in multiple places, only one of which is valid. It is commonly placed in the /boot/grub directory of the last operating system you install. This makes it very vulnerable. When I say ‘it’, I am mis-speaking, because it is really composed of about 3 separate pieces in a typical linux distribution.

I say grub is an enigma because although you can find tons of information on how to configure the grub configuration file /boot/grub/menu.lst, you will find much less information on the detailed sequence that grub follows when it boots. Normally you find something slightly more detailed than this:

run stage 1

run stage 1.5

run stage 2

That is not much help. Nor have I found any information on how to make grub work in a safe, reliable, secure manner. If you install 4 operating systems, one at a time, on your hard drive, then the later systems will contain grub boot information about the earlier systems, but the earlier systems won’t contain information about the later systems. And if you boot the the first system and edit the /boot/grub/menu.list file there to help fill in the blanks, you might as well be spitting into the wind. Unless you do something drastic to tell grub to go back and look at that file, it will never see it again, even though you edited it properly.

To my knowledge, this problem is unique to grub. Lilo does not have this problem. I have not seen a Windows system with the problem, although they have not worked in a similar manner until about Windows XP. But the real grand-daddy of modern bootloaders AFAIK is the OS-2 bootloader. I have been pondering why IBM’s OS-2 worked without fail, and grub crashes your system when you remove things.

The common problem with grub is that the data it needs to boot is at the end of a daisy chain of drive partition table entries scattered out across your hard drive. Break any link in the chain before the partition with the grub info, and you are dead in the water. So it is bad construction to put the data (the menu list) way out there. It should be held close to the Master Boot Record (MBR). But the way grub is designed, that is not possible for a disk with more than 3 operating systems.

As part of the MBR, there is a partition table that describes the location of 4 partitions on your hard disk. No more, fewer is OK. The partitions defined in the MBR are referred to as Primary partitions, as they are in the primary table in the MBR. So if you have 5 operating systems installed, one cannot be included in the MBR. And in a realistic setup, one of the 4 entries would point to the ‘extended’ partition table, leaving you only three entries to use. So now 3 operating systems max can have their location defined in the MBR, thus avoiding the daisy chaining issue. This would place them relatively close to the front of the hard drive.

But is that what the OS-2 boot loader did? Well, no. It put the bootloader in a small partition at the end of the hard drive, as far from the MBR as possible. So how did they do that? I never dug into it really. No need, it just worked. But in thinking about it in terms of what can be done with what we have, an obvious solution is to create a small primary partition at the end of the hard drive, and put grub there. Since is is still a primary drive, it is directly referred to by the MBR, and is not subject to daisy chain breakage. There is no rule that says an extended partition cannot be followed by a primary partition. It is true that this would put the partitions out of numerical order, but that should not matter. It only matters when one partition has to point backwards to the next partition. But only logical partitions in the extended partition point to another partition in the diasy chain. Primary partitions never piont to another partition, they are dead ends. So by definition they can’t need to point backwards down the drive, and being out of sequence should not matter.

So, what if we put create a device, call it /dev/hda3, at the very end of the hard drive, out of the way. When we install our first OS, we create a linux swap file at /dev/hda1, so it has quick access. We create another swap file at /dev/hda2, just to force the numbering scheme. We create a small partition at the end of the hard drive, it will be /dev/hda3. Then we create and extended partition in the rest of the disk space, it will be hda4.

Now, logical partition in the extended partition always start with the number 4, whether you use all 4 of the previous numbers or not.

For OS#1, we will create /dev/hda5 for it / (root) directory, and /dev/hda6 for its /home directory.

For OS#2, we will create /dev/hda7 for it / (root) directory, and /dev/hda8 for its /home directory.

For OS#3, we will create /dev/hda9 for it / (root) directory, and /dev/hda10 for its /home directory.

So our file system table for system 2, say would have entries that contain:

/dev/hda7 / (yes, I left out some more parameters)
/dev/hda8 /home

/dev/hda3 /boot/grub (we put the grub directory on the small partition at the end)

And our file system table for system 3 would have entries that contain:

/dev/hda9 /

/dev/hda10 /home

/dev/hda3 /boot/grub (It’s the same place as for OS#2!)

So, by doing this, OS#3, when we create it, will overwrite what OS#2 ut in /boot/grub. But maybe that is OK, because grub is grub. It will have newer entries, as it will have data for OS#3 that was not there before. And if we boot back into OS#2, and look at the grub menu list /boot/grub/menu.lst, we will see, and be able to edit, the list that is now one and the same file for all three systems. We no longer have to wonder which of the menu lists grub is really going to read. We see a consistent list regardless of which system we look at it from. And it is a primary partition, and not subject to the daisy chain vulnerabilities of the extended partition.

Will this work? I don’t know, I have not tried it. But think I will, as the present operation of grub is driving me crazy. It just does not work logically, when it works at all.

grub

Grub will/may/could/won’t leave you stranded like a young filly headed off to greener pastures.

Pop.

Hmm. Pop does not pop it up to the top.