Running "grub-install /dev/sda" in a live environment "fixes" the machine so it will boot.

Unless there's a good reason not to though, I'd like to know why the current method doesn't work, and find a general solution that will work for any setup.  See my last email.

And also, I can't seem to find "grubby".  It's not included on the fedora rescue cd or ubuntu live cd, and the fedora live cd keeps giving me a kernel panic when I try to boot it.  But that's a separate issue for now.
-Andrew

On Wed, Aug 20, 2008 at 2:25 PM, Andrew Brown <ambrown4@ncsu.edu> wrote:
On Wed, Aug 20, 2008 at 7:44 AM, Michael DeHaan <mdehaan@redhat.com> wrote:
Andrew Brown wrote:
> On Tue, Aug 19, 2008 at 6:16 PM, Michael DeHaan <mdehaan@redhat.com
> <mailto:mdehaan@redhat.com>> wrote:
>
>     Andrew Brown wrote:
>     > Okay, a few things since yesterday:
>     > I'm not worrying about the hard drive device issue for the
>     moment, it
>     > seems to be related to whether the bladecenter media tray is
>     assigned
>     > to that blade or not.
>     >
>     > I've also edited the code to ignore listed partitions of type
>     "Empty"
>     > or "Extended"
>
>     Is there a new attachment we can look at for this?
>
>
> I've attached the most recent base.cfg which contains the code.  Keep
> in mind that today I did things manually though, not using the script.


>
>
>
>     >
>     > But somehow the process isn't working.  I followed the process very
>     > closely of xcat, a similar provisioning engine.  After taking and
>     > restoring an image, it doesn't boot.
>     >
>     >
>     > I tried the process manually today.  That is, I booted with a
>     live cd
>     > and ran each command myself.  Saved the mbr, saved the partition
>     table
>     > with sfdisk, and saved the contents of each partition of a freshly
>     > installed linux installation.
>     >
>     > Then I went to the next blade, identical hardware and setup, and
>     > booted the live cd up.
>     > -Restored partition entries with sfdisk
>     > -Restored mbr with dd
>     > -Restored partitions again with sfdisk.  I don't fully
>     understand why
>     > it's done again,  this was just following the xcat process (for
>     which
>     > I can post the exact code if anyone's curious).
>     > -And of course restore all partitions one at a time
>     >
>     > When I tried to boot it back up, it got as far as printing
>     "GRUB" and
>     > hung there.  I need some help here, I'm not sure what's going on.
>
>     One thing to check is to stop before rebooting and see if grub is
>     installed correctly, or if any errors happen during grub-install.
>       For
>     that, it may be worth running through the script line by line or at
>     least logging the output of each step w/ debug output printed before
>     each command as needed.
>
>
> Like I said, I did the entire procedure manually... entered each
> command myself so I knew exactly what was running.  Once I get it
> working manually, I can easily find out if my script is doing things
> any differently.
>
> How do I tell if grub is installed correctly?

"grubby" has some probe options that should do this.   See "man grubby"?

>
>
>
>
>     >
>     > I tried a different order to restoring partition/mbr info: Restore
>     > partition stuff with sfdisk, and then the mbr with dd.  I was
>     thinking
>     > sfdisk may have overwritten the mbr or something, but I got the same
>     > results.
>
>     Grub lives in the MBR, though are you calling grub-install after
>     all of
>     that?
>
>
> Right.  I'm not calling grub-install.  I didn't think it was
> necessary.  Grub lives in the mbr, which is the first 512 bytes of the
> drive.  I'm saving the mbr to a file and restoring it back.  Shouldn't
> that be sufficient?

In theory, assuming it's not a GPT partition /and/ grub lives in the MBR
(both of which can't really be assumed), yes.

It's best to use grubby, the command line tool, for manipulating
grub.    As a bonus it also knows how to manipulate lilo and elilo.
There is some code in koan that references a few common grubby commands,
though you'll probably want to change this around.

--bad-image-ok does not work, but otherwise what you see koan using for
the live CD is close.

Also there are some bits of the live config script that are using
grub-install.

So I suppose I'm wrong in assuming that saving the mbr+partition layout and each partitions' contents, and then restoring each component is not sufficient for perfectly duplicating a hard drive.  Where else could data lie?

I'll look into using grubby to make sure grub is installed, but I still don't know why this doesn't work as is, things should be restored exactly as they were, right?

And further, what about systems that don't use grub, such as windows?  How are we going to do this so that it's still cross platform?

-Andrew
 


_______________________________________________
cobbler mailing list
cobbler@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler