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@xxxxxxxxxxxxxxxxxxxx> wrote:
Apologies Raphael - just waking up, didn't notice you said where you
got the kernel. Yes, it probably means that the kernel at:
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@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxx>:
>> 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@xxxxxxxxxxx>
>>>
>>> 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@xxxxxxxxxxx>
>>>>
>>>> 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@xxxxxxxxxxxxxxxxxxxx>
>>>> 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@xxxxxxxxxxxxxxxxxxxxxxx
>>>>> https://admin.fedoraproject.org/mailman/listinfo/cloud
>>>>>
>>>>
>>>
>>
>> _______________________________________________
>> cloud mailing list
>> cloud@xxxxxxxxxxxxxxxxxxxxxxx
>> https://admin.fedoraproject.org/mailman/listinfo/cloud
>>
>>
>
_______________________________________________
cloud mailing list
cloud@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/cloud
_______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud
