On Tue, Aug 19, 2008 at 6:16 PM, Michael DeHaan <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?
 


>
> 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?

Again, I'm following the procedure that xcat uses as closely as possible.  I'm not against making changes of course, but I'm wondering what I'm doing differently since I didn't see any calls to grub-install in the xcat scripts.
-Andrew
 



>
> Anyone have any ideas?
>
> -Andrew
>
> On Mon, Aug 18, 2008 at 1:39 PM, Andrew Brown <ambrown4@ncsu.edu
> <mailto:ambrown4@ncsu.edu>> wrote:
>
>     Hi All,
>     I thought I'd give an update on where I am.  I've been working on
>     a live cd image that will boot up and take/restore an image to an
>     nfs export and then reboot.
>
>     Attached are the base.cfg kickstart file and build.py script to
>     build the live cd.  It is somewhat untested at the moment.  Taking
>     images works but I haven't yet tried restoring them (I plan to do
>     that shortly).
>
>     The process for saving an image is as follows, and this is mostly
>     identical to how xcat does it:
>     0) mounts remote nfs export at /mnt/nfs
>     1) saves off the mbr with e.g. "dd if=/dev/sda
>     of=/mnt/nfs/imagename/mbr bs=512 count=1"
>     2) Saves off extended partition image information with "sfdisk
>     /dev/sda -d > /mnt/nfs/imagename/sfdisk"
>     3) Loops for each partition listed in the output of "sfdisk -l
>     /dev/sda"
>      3.a) If the partition type (last column) is "Empty", skip it
>      3.b) Save the partition with e.g. "dd if=/dev/sda1
>     of=/mnt/nfs/imagename/1 conv=sync,noerror"
>
>     Eventually we can use the partition type to determine if we can
>     use partimage on it (for ext/ntfs partitions) or if we can do
>     something else (swap partitions, mkswap to restore).  For now,
>     everything is copied with dd.
>
>
>     The script expects arguments to be passed through the kernel
>     command line.  Here are the arguments it needs:
>     nfs=  the nfs path to mount.  e.g. 10.10.10.1:/export
>     image=  the name of the image to save/restore.  This translates to
>     the folder name under the nfs path where files will be saved.
>     drive=  the local drive where things will be saved
>     save|load  either one of these is specified and the image is
>     either saved or loaded
>
>
>     And to make a long post even longer, I was wondering if anyone
>     could shed some light on an odd problem.  It seems that while in
>     the live environment, the one and only hard drive appears as
>     /dev/sdb instead of the expected /dev/sda.  I was trying this on
>     an IBM bladecenter blade, and found that /dev/sda was something
>     else and the hard drive was assigned /dev/sdb.  It's not like this
>     in a non-live environment.  Anyone have any ideas?
>     -Andrew
>
>
>     On Thu, Aug 7, 2008 at 8:39 AM, Michael DeHaan <mdehaan@redhat.com
>     <mailto:mdehaan@redhat.com>> wrote:
>
>         Andrew Brown wrote:
>         >
>         >     I'm assuming you are building this on F9?
>         >
>         >
>         > I wasn't, I was using the script and kickstart in the koan
>         source
>         > which was fc8.  I've switched to the development branch
>         which is fc9
>         > and re-built it.
>         >
>         > The cd image that comes out of that works, as in, it boots
>         and starts
>         > executing the scripts.  I believe I can modify things to do
>         what we need.
>         >
>         > I also tried using the livecd-iso-to-pxe script to convert
>         the iso
>         > into a pxe boot kernel/initrd and pxelinux config file.
>          That also
>         > worked as far as I could tell booting an actual machine
>         using the
>         > generated /tftpboot tree (it generates a kernel, initrd, and
>         pxelinux
>         > config file)
>         >
>         > However, I tried booting the kernel and initrd with qemu
>         using its
>         > -kernel and -initrd options, and it wouldn't work.  I'd like
>         to get
>         > this to work if possible so I can rapidly try new images without
>         > booting up actual hardware.
>         > It's actually not that big of a deal because qemu boots the
>         iso just
>         > fine.  I'm just curious why it wouldn't boot the kernel/initrd
>         > directly.  The command line looks like this:
>         >
>         >     qemu -m 256 -hda ~/disk.qcow2 -kernel vmlinuz0 -initrd
>         initrd0.img
>         >     -append "root=/koan-live-cd.iso rootfstype=iso9660
>         rootflags=loop"
>         >
>
>         This is what koan is for.
>
>         If using a VM:
>
>         # on cobbler server
>         cobbler image add --name=livecd
>         --path=nfs://server/path/to/livecd.iso
>
>         # on host system
>         koan --virt --virt-type=qemu --image=livecd
>
>         This all goes through the virtinst libraries to make sure the
>         correct
>         arguments are used.  If that /still/ fails, we can debug this.
>
>         The process for PXEbooting that still involves "cobbler distro
>         add" and
>         not "image add" based on the Wiki link "AllAboutImages" I posted
>         yesterday.
>
>         > It errors with a kernel panic being unable to mount the root
>         > filesystem.  The append line was copied from the generated
>         pxe config
>         > from the livecd-iso-to-pxe script.  /koan-live-cd.iso is a
>         file in the
>         > initrd.
>         >
>         >
>         > Anyways, if that's a dead end, I won't worry about it.  I'm
>         going to
>         > try and modify the koan live cd to be a cloner live cd.  I'm
>         first
>         > going to get it working with dd, since partimage isn't in
>         the repos
>         > and I'll have to build it myself.
>
>         Yep, we're going to want to get partimage packaged for Fedora.
>
>
>
>         > -Andrew
>         >
>         > On Tue, Aug 5, 2008 at 2:58 PM, Michael DeHaan
>         <mdehaan@redhat.com <mailto:mdehaan@redhat.com>
>         > <mailto:mdehaan@redhat.com <mailto:mdehaan@redhat.com>>> wrote:
>         >
>         >     Andrew Brown wrote:
>         >     > So I've started looking at the script that builds a
>         koan live cd
>         >     (the
>         >     > 'live' directory in the koan source) to modify it to
>         do what we
>         >     need,
>         >     > but I'm having trouble getting the code to produce a
>         bootable iso.
>         >     >
>         >     > I'm just trying to run the build.py script as is, and
>         it produces a
>         >     > koan-live-cd.iso.  But when I boot it, it gets several
>         errors about
>         >     > mounting the root filesystem, as well as several other
>         errors that I
>         >     > can type up here if you want.  The last line looks
>         like "switchroot:
>         >     > mount failed: No such file or directory"
>         >     >
>         >     > I need to get this working before I can move on to
>         editing it
>         >     for the
>         >     > cloner imaging.  Any idea what's going on with this?
>         >     > -Andrew
>         >
>         >     Sure.  Perhaps you can take a picture of the actual
>         error, so we
>         >     can run
>         >     it by the livecd-tools folks?
>         >
>         >     I'm assuming you are building this on F9?
>         >
>         >     --Michael
>         >
>         >
>         >     _______________________________________________
>         >     cobbler mailing list
>         >     cobbler@lists.fedorahosted.org
>         <mailto:cobbler@lists.fedorahosted.org>
>         <mailto:cobbler@lists.fedorahosted.org
>         <mailto:cobbler@lists.fedorahosted.org>>
>         >     https://fedorahosted.org/mailman/listinfo/cobbler
>         >
>         >
>         >
>         ------------------------------------------------------------------------
>         >
>         > _______________________________________________
>         > cobbler mailing list
>         > cobbler@lists.fedorahosted.org
>         <mailto:cobbler@lists.fedorahosted.org>
>         > https://fedorahosted.org/mailman/listinfo/cobbler
>         >
>
>         _______________________________________________
>         cobbler mailing list
>         cobbler@lists.fedorahosted.org
>         <mailto:cobbler@lists.fedorahosted.org>
>         https://fedorahosted.org/mailman/listinfo/cobbler
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> cobbler mailing list
> cobbler@lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/cobbler
>

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