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