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 <[EMAIL PROTECTED]> wrote: > On Wed, Aug 20, 2008 at 7:44 AM, Michael DeHaan <[EMAIL PROTECTED]>wrote: > >> Andrew Brown wrote: >> > On Tue, Aug 19, 2008 at 6:16 PM, Michael DeHaan <[EMAIL PROTECTED] >> > <mailto:[EMAIL PROTECTED]>> 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 >> [email protected] >> https://fedorahosted.org/mailman/listinfo/cobbler >> > >
_______________________________________________ cobbler mailing list [email protected] https://fedorahosted.org/mailman/listinfo/cobbler
