Kickstart a Fedora (Anaconda) Install on EC2

Mon Mar 21 13:37:29 UTC 2011

Well, it seems that the "mmu_update" issue is related to instances memory
size . Micro instances' memory is too low to handle that kernel. Same kernel
boots on a small (or greater) instance. One of the AWS folks suggested to
prune down the kernel so it works on low memory instances.

So XSAVE is probably disabled in recent kernels.

The dbus issue seems to be Xen related with i386 kernels : EC2 small
instance uses the version 3.0.3-rc5-8.1.14.f and sometimes randomly uses the
good one, which is 3.4.3-2.6.18 (preserve-AD) that does fail on dbus.

So, the only one that's working is F14 x86_64 kernel on large instances and
anaconda is now loading properly (but hangs on kickstart's package
installation).

On Fri, Mar 18, 2011 at 5:45 PM, Brian LaMere <brian at cukerinteractive.com>wrote:

> Apologies Raphael - just waking up, didn't notice you said where you
> got the kernel.  Yes, it probably means that the kernel at:
>
>
> http://ftp.esat.net/mirrors/download.fedora.redhat.com/pub/fedora/linux/releases/test/15-Alpha/Fedora/i386/os/images/pxeboot/
>
> doesn't have the XSAVE patch.  It probably doesn't work in to what
> they consider their target audience for that kernel ;)  Whether they'd
> take a bug report on that...I don't know.
>
> On Fri, Mar 18, 2011 at 9:31 AM, Brian LaMere
> <brian at cukerinteractive.com> wrote:
> > Raphael - there's more than just a memory difference between micro and
> > small; micros are 64bit, smalls are 32bit.  If you try the same thing
> > on a large, do you have the same problem?  Small and medium are both
> > 32bit, micro, large, and every other size are all 64bit.
> >
> > The initial error of "base is 0x26617ba8 caller is 0x45c87" looks like
> > something calling a 32 against a 64.  Someone smarter than me
> > suggested this means that XSAVE isn't disabled in the kernel; that
> > would mean the anaconda kernel itself, which is pre-built.  Maybe get
> > with the anaconda folks to verify whether the CD kernel has the XSAVE
> > patch?  The kernel in the distro does, otherwise we wouldn't be able
> > to use it ;)  But that doesn't mean the kernel in CDHOME/isolinux
> > does.
> >
> > Does what I'm asking/suggesting make sense?
> >
> > Brian
> >
> > 2011/3/18 Raphaël De GIUSTI <raphael.degiusti at guardis.com>:
> >> It seems to be happening when launching micro instances, as memory is
> low
> >> (about 600M)
> >> Launching it as a small instance, anaconda is executed, but there seems
> to
> >> be a problem related with dbus :
> >> Greetings.
> >> anaconda installer init version 15.20.1 starting
> >> mounting /proc filesystem... done
> >>
> >> (process:1): GLib-CRITICAL **: g_hash_table_lookup_extended: assertion
> >> `hash_table != NULL' failed
> >> creating /dev filesystem... done
> >> starting udev...done
> >> mounting /dev/pts (unix98 pty) filesystem... done
> >> mounting /sys filesystem... done
> >>
> >> (process:1): GLib-CRITICAL **: g_hash_table_lookup_extended: assertion
> >> `hash_table != NULL' failed
> >> anaconda installer init version 15.20.1 using /dev/hvc0 as console
> >> trying to remount root filesystem read write... done
> >> mounting /tmp as tmpfs... done
> >>
> >> (process:1): GLib-CRITICAL **: g_hash_table_lookup_extended: assertion
> >> `hash_table != NULL' failed
> >> running install...
> >> running /sbin/loader
> >>
> >> %Gdetecting hardware...
> >> waiting for hardware to initialize...
> >> detecting hardware...
> >> waiting for hardware to initialize...
> >>
> >> ** (loader:49): WARNING **: Couldn't connect to system bus: Failed to
> >> connect to socket /var/run/dbus/system_bus_socket: No such file or
> directory
> >>
> >> ** (loader:49): WARNING **: Couldn't connect to system bus: Failed to
> >> connect to socket /var/run/dbus/system_bus_socket: No such file or
> directory
> >>
> >> ** (loader:49): WARNING **: Couldn't connect to system bus: Failed to
> >> connect to socket /var/run/dbus/system_bus_socket: No such file or
> directory
> >>
> >> ** (loader:49): WARNING **: Couldn't connect to system bus: Failed to
> >> connect to socket /var/run/dbus/system_bus_socket: No such file or
> directory
> >>
> >> ** (loader:49): WARNING **: Couldn't connect to system bus: Failed to
> >> connect to socket /var/run/dbus/system_bus_socket: No such file or
> directory
> >>
> >> ** (loader:49): WARNING **: Couldn't connect to system bus: Failed to
> >> connect to socket /var/run/dbus/system_bus_socket: No such file or
> directory
> >>
> >> ** (loader:49): WARNING **: Couldn't connect to system bus: Failed to
> >> connect to socket /var/run/dbus/system_bus_socket: No such file or
> directory
> >>
> >> ** (loader:49): WARNING **: Couldn't connect to system bus: Failed to
> >> connect to socket /var/run/dbus/system_bus_socket: No such file or
> directory
> >>
> >> 2011/3/10 Raphaël De GIUSTI <raphael.degiusti at guardis.com>
> >>>
> >>> Hi,
> >>> I simply tried to boot on the fedora 15 alpha kernel from there :
> >>>
> >>>
> http://ftp.esat.net/mirrors/download.fedora.redhat.com/pub/fedora/linux/releases/test/15-Alpha/Fedora/i386/os/images/pxeboot/
> >>> and I'm getting this error :
> >>>>
> >>>> root (hd0,0)
> >>>>
> >>>> Filesystem type is ext2fs, partition type 0x83
> >>>> kernel /boot/vmlinuz-PAE
> >>>> initrd /boot/initrd-PAE.img
> >>>> ERROR: mmu_update failed with rc=-22
> >>>> Do_exit called!
> >>>> base is 0x26617ba8 caller is 0x45c87
> >>>> base is 0x26617bd8 caller is 0x50336
> >>>> base is 0x26617c38 caller is 0x504c0
> >>>> base is 0x26617c88 caller is 0x506a3
> >>>> base is 0x2661fd08 caller is 0x479d7
> >>>> base is 0x2661fd48 caller is 0x5613b
> >>>> base is 0x2661fd58 caller is 0x54698
> >>>> base is 0x2661fd98 caller is 0x55a79
> >>>> base is 0x2661fde8 caller is 0x55811
> >>>> base is 0x2661fe08 caller is 0x3b0c
> >>>> base is 0x2661fe38 caller is 0x3bc4
> >>>> base is 0x2661fe48 caller is 0x7af7
> >>>> base is 0x2661fe58 caller is 0xa243
> >>>> base is 0x2661fe78 caller is 0xfe69
> >>>> base is 0x2661fef8 caller is 0x10489
> >>>> base is 0x2661ff68 caller is 0x3eb2
> >>>> base is 0x2661ff78 caller is 0x4729d
> >>>> base is 0x2661fff0 caller is 0x31ad
> >>>
> >>> I just wondered where it does come from ?
> >>> Any idea ?
> >>>
> >>> 2011/2/8 Raphaël De GIUSTI <raphael.degiusti at guardis.com>
> >>>>
> >>>> So if we put aside how the kickstart would be generated, what would be
> >>>> the starting point in all of this ?
> >>>> I was working with Centos55 when I made it to the partitioning phase
> (and
> >>>> I don't really know why it went wrong), but I couldn't even get the
> F14
> >>>> kernel to load.
> >>>> In other words :
> >>>> - Which fedora kernel / initrd combination should I use in my
> grub.conf ?
> >>>> - Should any of those two be altered in any way ?
> >>>> I'm also willing to put some time in it if I may be useful... but like
> I
> >>>> said I'm no expert.
> >>>> On Wed, Feb 2, 2011 at 9:48 PM, Brian LaMere <
> brian at cukerinteractive.com>
> >>>> wrote:
> >>>>>>
> >>>>>> Maybe I'm missing something:  why would you ever want an instance to
> >>>>>> kickstart at boot time?  You should create an image for every role
> you
> >>>>>> care about and then boot the appropriate one for every instance you
> >>>>>> need.
> >>>>>
> >>>>> roles change, updates happen frequently, and I'd rather a machine
> spin
> >>>>> up with the latest packages.  I've always found that updating a
> pre-built
> >>>>> machine is slower, sometimes substantially so, than just building a
> fresh
> >>>>> image with the newest rpms.
> >>>>> That said, some roles can (and often should) be fairly rigid and slow
> to
> >>>>> be updated.  But there's not much less of a need for flexible,
> dynamic
> >>>>> builds in the cloud than there is in a local server room; do you
> build all
> >>>>> new local servers based on a pre-built image that you just replicate?
>  Would
> >>>>> seem to negate the purpose of a kickstart server ;)
> >>>>> Brian
> >>>>> _______________________________________________
> >>>>> cloud mailing list
> >>>>> cloud at lists.fedoraproject.org
> >>>>> https://admin.fedoraproject.org/mailman/listinfo/cloud
> >>>>>
> >>>>
> >>>
> >>
> >> _______________________________________________
> >> cloud mailing list
> >> cloud at lists.fedoraproject.org
> >> https://admin.fedoraproject.org/mailman/listinfo/cloud
> >>
> >>
> >
> _______________________________________________
> cloud mailing list
> cloud at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/cloud
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/cloud/attachments/20110321/93269586/attachment.html>