[GLLUG] boot strap

STeve Andre' andres at msu.edu
Tue May 10 14:10:02 EDT 2005


On Monday 09 May 2005 18:37, tk3000 wrote:
> On Tuesday 10 May 2005 01:53 am, STeve Andre' wrote:
> > On Monday 09 May 2005 17:34, tk3000 wrote:
> > > Hello,
> > >
> > > I was in the process of doing backups of my hds in the form of images.
> > > But I am in doubt with respect to the area of the hd corresponding to
> > > the boot code/strap; I am extracting the boot code and partition table
> > > separately, which, for the boot strap, would be something like:
> > >
> > > A) dd if=/dev/hda of=/mnt/backup.MBRBOOTSTRAPONLY bs=446 count=1
> > > or
> > > B) dd if=/dev/hda of=/mnt/backup.MBRBOOTSTRAPONLY bs=448 count=1
> > >
> > > So, my question is: which is the correct, or more correct; or if the 2
> > > bytes are irrelevant (being one of those reserved areas defined at the
> > > time the xt was launched, and never being used...). I have some sources
> > > that indicate 446 and others that indicate 448; so, I am not quite
> > > sure.
> > >
> > > Thanks in advance,
> > > Pedro Wald
> >
> > I can't speak to the byte specifics of your machine and OS, but the
> > classic bootstrap loader is 446 bytes.  However, it isn't at the
> > beginning of the disk, is it?  Regardless of that, there is the partition
> > table in general to think of.  I'd make sure I have the software to
> > create a new set of partitions, and know the sizes of everything on the
> > disk, rather than make an image backup of it.  Know how to create it and
> > you can always do that. Make an image and you may (will?) have problems
> > using it anywhere else. For backups, I prefer good old plain stupid tar. 
> > You can then move things to a new disk and extract what you want, etc.
> >
> > --STeve Andre'
>
> I understand that it can be problematic to restore. tar is great tool, but
> star has more features (maybe modern distribuitions have tar as an
> alias to star; but I am just guessing). For me image is a good approach for
> fast and complete recovery but I am not relying only on images, I thinking
> that having a multitude of backup strategies can be handy. I believe that
> the main issue of recovery is the size of the partition, I understand (but
> I am not quite sure...) that the key is to define partition sizes using
> cylinders rather than bytes (fdisk, by default, shows the partition and
> allows you to define the partition in terms of bytes). My system is a x86,
> so the MBR is located at the very beginning of the disk. For most part the
> bootstrap is pretty generic, but in some circumstances it can be helpfull
> to have a separate backup. Maybe/sometimes the most problematic part is
> having to backup and restore logical partitions on extended partitions. tar
> has more options and is more flexible when dealing with file objects than
> dd; but in my case I have different boot managers even in different boot
> sectors all over my partition arrangement, so having images can be helpfull
> too. Well, I will take the 446 as the right one. Thks!
>
> Pedro Wald

Never confuse more features with a program being better; I think I could make
the case that most programs that have successive versions with "more features"
are train wrecks in terms of how to use them, and what they do.  This is not 
to say that software should not evolve, but one should always critical eye 
towards "improvements".

What I am trying to figure out is why you want to do the image save.  I'm
thinking back to a time when I helped write such software and those 
experiences taught me that it isn't worth it.  What happens is part of the
image save is damaged?  What happens if you the partition you are restoring
onto is accidently too small?  These are real world things that I have seen
rise up and nip people in their rear ends...

In terms of experimentation its a good thing to do.  I just hope you don't
rely on any form of backup where atomic elements (ie, files) can't be 
individually restored.

--STeve Andre'


More information about the linux-user mailing list