[sf-lug] MBR/partition table/sfdisk/use dd to copy the mbr

[jim stockford]

i was working on a red hat 6 box (the one
just before red hat 7, 8, and 9). the CDs
were long gone (probably around 1999,
just after the machine was built). I was
charged with doing something, anything,
to provide backup of the OS. I put in a
new hard drive and partitioned it exactly
as the original, copied all files in all
filesystems to the appropriate partitions
on the new drive, and had the problem
of duplicating the boot loader without
disturbing the partition table on the new
drive (it had room for an extra partition,
which i made).
    so i copied the first 446 bytes from
/dev/hda to /dev/hdb and am hopeful.

    turns out i later found a complete red
hat 6 box, with manuals and CDs, in my
garage, but after the fact.




On Nov 23, 2007, at 6:51 PM, Michael Paoli wrote:

>> Date: Mon, 19 Nov 2007 21:35:32 -0800
>> From: Rick Moen <rick at linuxmafia.com>
>> Subject: Re: [sf-lug] use dd to copy the mbr
>> To: sf-lug at linuxmafia.com
>>
>> Quoting jim stockford (jim at well.com):
>>
>>> # dd if=/boot/mbr_backup of=/dev/sda bs=446 count=1
>>> # # or, copy from the primary master to primary slave:
>>> # dd if=/dev/hda of=/dev/hdb bs=446 count=1
>>>
>>> note the bs=446 rather than bs=512 lets you copy the
>>> bootstrap loader code without copying the partition table
>>> (if you use bs=512 you copy the partition table from the
>>> source and overwrite that of the target).
>>
>> I frankly cannot fathom why people think the inital 446 bytes' 
>> contents
>> are so valuable.  It's dead-easy to rebuild from a Linux maintenance 
>> CD
>> whatever you had there.  I'd have though possessing a reference copy 
>> of
>> the partition table would be more valuable.
>
> Well, ... at least *sometimes*, backing up the MBR and/or partition
> table can be highly useful or convenient ... if not downright 
> important.
>
> E.g. if one might not easily be able to otherwise restore the MBR as it
> was, then backing it up may be highly useful.  For example, x86
> hardware, at least per legacy design, can quite easily support 4
> distinct and separate operating systems - with a multi-boot
> configuration.  If one wants/needs to keep a particular type of MBR in
> place, ... there are no guarantees that that particular MBR is easily
> restored from whatever foo operating system or boot loader may be
> responsible for having initially set it up.
>
> And on backing up partition tables - I *really* like sfdisk; *however*
> sfdisk can be exceedingly dangerous if one doesn't know what one is
> doing (or even worse, if one doesn't, but thinks one does).  I would
> *not* recommend sfdisk for systems administrators that aren't rather to
> quite experienced and careful (e.g. it's real easy to type sfdisk, not
> know what one's doing or feed it not precisely the correct data, and
> trash one's partition table).  Nevertheless sfdisk can do some highly
> cool and useful stuff.  E.g.:
> * the -l and -d options can be used to output a very handy listing of
>   how the partition table is configured.  If one includes the -x option
>   with -l and -uS, one can really see at quite low level how all the
>   partitioning details are configured.
> * the -d option can be highly useful for partition table 
> backup/restore,
>   particularly when combined with -uS, as the output format with -d can
>   be used as input to (re)create/restore a partition table.  (This type
>   of data is also some of the metadata that my backup scripts create
>   and backup early on the backup media - so it can be easily extracted
>   from backup media and consulted or used quite directly in creating
>   partition table prior to moving on to higher level data restore
>   tasks).
> * the -O and -I options are highly useful for backing up, and if need 
> be
>   restoring, partition table changes.  Note that this is highly
>   superior to merely backing up the partition table - as some partition
>   table changes cannot be undone and things restored on the hard drive
>   as they were before the change by merely restoring the earlier
>   partition table (most notably with extended partitions, one also
>   alters other sectors on the hard drive; with -O and -I one can save
>   and undo those changes, whereas a mere backup and restore of the
>   partition table will not undo changes to data in sectors beyond that
>   containing the partition table).
> * if it would be a legitimate partition table, sfdisk will let you
>   create it.  One can do very low level fine grain control of how the
>   partition table is set up - many other partitioning utilities won't
>   allow one that level of control.  It will still (at least generally?)
>   prevent you from creating a partition table that wouldn't be
>   legitimate at all, and by default it will also prevent one from doing
>   at least some things that in general may not be a good idea.
>
> And some random examples of where I've found backing up the partition
> table, partition table and related data changes, and/or MBR to be
> rather to quite useful:
> * Once upon a time, initial setup of a laptop.  It included a
>   proprietary OS (had to purchase it with the laptop) with a sucky
>   filesystem - but one with which various open source tools well
>   understood and could deal with, ... and which would get instantly
>   converted into an even much suckier filesystem type - which would be
>   more problematic for dealing with via open source tools - if the
>   installed OS was booted (it would convert filesystem type upon
>   initial boot).  I didn't want to completely get rid of that sucky OS
>   (maybe I wanted the occasional reminder of how sucky it was ... and
>   besides, it was already bought and paid for) ... but I sure did want
>   to both shrink and relocate its filesystem/partition.  I didn't want
>   to change the MBR (though I did want to configure it so that by
>   default, that bootloader would chainload GRUB).  I didn't yet have
>   CD/DVD burn capabilities, and other than the hard drive (which I
>   didn't yet want to boot from due to aforementioned reasons), the only
>   things I had available to boot from were floppy, or one single
>   relatively old LinuxCare rescue CD (which while useful, was rather
>   limiting - e.g. the laptop's Ethernet was far too new of hardware for
>   that CD to know how to deal with).  Anyway, with careful backups
>   along the way (typically to floppy, or some other "safe" area removed
>   or away from stuff being changed or dependent upon stuff being
>   changed), I was able to make all the manipulations and file shuffling
>   and repartitioning I wanted to do, without ever booting off of the
>   hard drive.  If I recall correctly, one goof somewhere along all that
>   hairy manipulation process, would have been a major pain had I not
>   also done that tiny little backup of critical data - so I was able to
>   undo the goof, and pick up again from where I was right before I'd
>   made that goof.
> * hairy disk partitioning / MBR / boot loader configuration changes.
>   Sometimes I do a major repartitioning of a hard drive - with the data
>   mostly all in place - and with no data losses.  Careful well planned
>   changes, along with use of sfdisk including -O option often make this
>   a significantly more goof resistant operation (and on at least some
>   rare occasions, I've had need or desire to go back a step in the
>   change process - and sfdisk with -I option made that quite easy, and
>   guaranteed to get me back where I was before (at least as long as I
>   didn't manage to do something incredibly stupid)).  Likewise, when
>   doing some major bootloader reconfigurations - involving all of some
>   proprietary hardware manufacturer (pre)bootloader, the NT bootloader,
>   GRUB *and* LILO ... all on the same system :-) careful backups of the
>   relevant pieces being altered can be rather to quite important (and I
>   may have saved myself from major issue to fix by doing such careful
>   backup bits ... it was either that occasion, or some of the initial
>   laptop partitioning reconfiguration where I did save myself from
>   quite a mess by having a careful backup of just the right critical
>   bits of data).
>
> So, yeah, ... "nowadays" with lots of (e.g. CD/DVD) bootable operating
> systems and recovery utilities, generally much more capable hardware,
> and when dealing with systems that have only (or mostly) open source
> operating system (e.g. Linux), MBR and bootloader installed, backing up
> those critical little bits often isn't as important, as fixing such is
> typically much easier now.  Nevertheless, still, having just the right
> critical little bits backed up - and in a manner that they can be
> usefully and properly restored, can still - at least occasionally -
> save one's tail.  While merely "fixing" things, such as via some
> bootable CD/DVD and reloading MBR and reconfiguring the partition table
> as it was, ... may not quite fix things adequately (e.g. that may not
> undo other changes on disk due to extended partition changes).
>
> Also, for what it's worth, there's *excellent* documentation on the
> details of partitioning, structure, various partition "gottchas"
> (particularly with multiboot configurations, and where some other
> operating systems might not fully and properly "play by the rules" as
> they should), which can be found in - oddly enough - the LILO
> documentation.  Anyway, best partitioning documentation I ever stumbled
> across (though since I found that some years ago, there might be better
> information out there somewhere else).
>
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
>