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