Re: Kickstart a Fedora (Anaconda) Install on EC2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Fedora General Discussion]     [Older Fedora Users Archive]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Big List of Linux Books]     [Yosemite News]     [Linux Apps]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]

  Powered by Linux