New Releases of Ubuntu Images for Amazon EC2 (Kernels, Security, Tools, PPA, runurl) - ec2ubuntu

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion New Releases of Ubuntu Images for Amazon EC2 (Kernels, Security, Tools, PPA, runurl)
Received-SPF: pass (google.com: domain of rjharmon0...@gmail.com designates 209.85.210.164 as permitted sender) client-ip=209.85.210.164;
MIME-Version: 1.0
Date: Tue, 15 Dec 2009 09:58:37 -0800 (PST)
In-Reply-To: <4ADDEF01.8010703@thinksome.com>
References: <bc0b2267-5e80-4fb2-9ccf-3c3082209049@a39g2000pre.googlegroups.com> 
	<c671ecde-65a6-430d-abad-f5b130b2f826@q40g2000prh.googlegroups.com> 
	<c5097ac40910141657g30f9496epe1fce859fd08775d@mail.gmail.com> 
	<4AD6DB8F.3040409@thinksome.com> <84191a8a-adf3-4911-9919-dec95f4b3fb7@x6g2000prc.googlegroups.com> 
	<362a8d86-ae29-4968-8d07-77c1d936efb5@v37g2000prg.googlegroups.com> 
	<4ADD0F86.8030400@thinksome.com> <b1df6bef-2bbf-4969-ace9-7fba1a08ce72@x5g2000prf.googlegroups.com> 
	<4ADDEF01.8010703@thinksome.com>
User-Agent: G2/1.0
Message-ID: <47b2f45f-b668-407c-8a4d-ea32428e7...@u36g2000prn.googlegroups.com>
Subject: Re: New Releases of Ubuntu Images for Amazon EC2 (Kernels, Security, 
	Tools, PPA, runurl)
From: Randy Harmon <rjharmon0...@gmail.com>
To: ec2ubuntu <ec2ubuntu@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Nearly 2 months without clear closure on this topic is fairly
worrisome.  Did I miss an update that actually resolves the reported
XFS-related kernel instability?

Randy


On Oct 20, 9:10=A0am, Eric Hammond <ehamm...@thinksome.com> wrote:
> Gorism:
>
> Thanks for the reminder. =A0I've posted an update on the forum thread.
>
> --
> Eric Hammond
>
> Gorism wrote:
> > Thank for the follow up, Eric.
>
> > I saw that you reached out to Amazon with a request for help. =A0In tha=
t
> > request you indicated that XFS worked fine with Jaunty with the 2.6.21
> > kernel, which wasn't the case when I tried it. =A0That's why I did the
> > follow up post; in case you weren't aware of that.
>
> > Sounds like you are aware of the problems with Jaunty + 2.6.21 + XFS,
> > though.
>
> > Have you heard anything back from Amazon regarding your suggestion to
> > compile a new xfs driver? =A0I didn't see any replies to your original
> > post, so I'm guessing not.
>
> > Mark
>
> > On Oct 19, 6:16 pm, Eric Hammond <ehamm...@thinksome.com> wrote:
> >> Mark:
>
> >> Yep, just be aware that reverting to the previous AMI downgrades the
> >> kernel to one which includes the security hole where users on the syst=
em
> >> can gain root.
>
> >> At the moment we're stuck with two kernel choices from Amazon for
> >> 2.6.21, both of which have problems (XFS vs. security).
>
> >> If your application has any chance of running on Karmic, then I
> >> recommend trying out the Beta AMIs from Canonical which run on 2.6.31.
>
> >> There has been a little movement on Hardy from Canonical, but I don't
> >> expect a lot to get done there in the short term since Karmic is
> >> launching in a couple weeks.
>
> >> I have also heard some folks having success running the Alestic.com
> >> Jaunty on the 2.6.27 kernel from Canonical, but that kernel was built =
a
> >> while back and I don't know how reliable or secure it is.
>
> >> --
> >> Eric Hammond
>
> >> Gorism wrote:
> >>> Quick follow up: going back to ami-ed46a784 (the 20090804 32 bit
> >>> Jaunty image from Eric) doesn't exhibit this behavior. =A0XFS seems t=
o
> >>> behave fine using that image.
> >>> Mark
> >>> On Oct 19, 2:46 pm, Gorism <mark.go...@gmail.com> wrote:
> >>>> I'm getting a crash with the base 32 bit image (ami-ccf615a5) by
> >>>> simply:
> >>>> 1. Starting a fresh one
> >>>> 2. Either mounting an existing -or- creating a new XFS based volume
> >>>> 3. Unmounting the volume
> >>>> At that point the instance is unresponsive and must be terminated. =
=A0No
> >>>> reboot required.
> >>>> This doesn't occur with ext3 based volumes.
> >>>> A kernel bug shows up in the console, same one as Robert provided
> >>>> above.
> >>>> Mark
> >>>> ------------[ cut here ]------------
> >>>> kernel BUG at arch/i386/mm/hypervisor.c:185!
> >>>> invalid opcode: 0000 [#1]
> >>>> SMP
> >>>> last sysfs file: /block/sda1/uevent
> >>>> Modules linked in: ipv6(F)(U) xfs(F)(U) xennet(F)(U) xenblk(F)(U) ex=
t3
> >>>> (F)(U) jbd(F)(U) mbcache(F)(U)
> >>>> CPU: =A0 =A00
> >>>> EIP: =A0 =A00061:[<c101bf0e>] =A0 =A0Tainted: GF =A0 =A0 =A0VLI
> >>>> EFLAGS: 00210282 =A0 (2.6.21.7-2.fc8xen-ec2-v1.0 #2)
> >>>> EIP is at xen_pgd_pin+0x54/0x5e
> >>>> eax: ffffffea =A0 ebx: c143eef8 =A0 ecx: 00000001 =A0 edx: 00000000
> >>>> esi: 00007ff0 =A0 edi: 00000000 =A0 ebp: c19cef70 =A0 esp: c143eef8
> >>>> ds: 007b =A0 es: 007b =A0 fs: 00d8 =A0gs: 0033 =A0ss: 0069
> >>>> Process bash (pid: 1200, ti=3Dc143e000 task=3Dc140cef0 task.ti=3Dc14=
3e000)
> >>>> Stack: 00000002 0020aa88 016f6000 0002dec0 00000000 c101816d c14b048=
0
> >>>> c1018196
> >>>> =A0 =A0 =A0 =A0c15e31d4 c102250e c15e38d0 c143efb8 c106e111 c143efb8=
 bfd0a71c
> >>>> 01200011
> >>>> =A0 =A0 =A0 =A000000000 c19cef70 c14b0480 c1346640 c15e31e0 c15e31f4=
 c15e31f0
> >>>> c14b0480
> >>>> Call Trace:
> >>>> =A0[<c101816d>] __pgd_pin+0x2f/0x3c
> >>>> =A0[<c1018196>] mm_pin+0x1c/0x23
> >>>> =A0[<c102250e>] copy_process+0xac3/0x10bc
> >>>> =A0[<c106e111>] kmem_cache_alloc+0x23/0x98
> >>>> =A0[<c1022b58>] do_fork+0x51/0x13a
> >>>> =A0[<c100321e>] sys_clone+0x36/0x3b
> >>>> =A0[<c1005688>] syscall_call+0x7/0xb
> >>>> =A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
> >>>> Code: eb fe a1 24 c2 38 c1 8b 14 90 81 e2 ff ff ff 7f 89 54 24 04 89
> >>>> e3 b9 01 00 00 00 31 d2 be f0 7f 00 00 e8 36 54 fe ff 85 c0 79 04 <0=
f>
> >>>> 0b eb fe 83 c4 0c 5b 5e c3 56 89 c2 53 83 ec 0c c1 ea 0c 80
> >>>> EIP: [<c101bf0e>] xen_pgd_pin+0x54/0x5e SS:ESP 0069:c143eef8
> >>>> ------------[ cut here ]------------
> >>>> kernel BUG at arch/i386/mm/hypervisor.c:185!
> >>>> invalid opcode: 0000 [#2]
> >>>> SMP
> >>>> last sysfs file: /block/sda1/uevent
> >>>> Modules linked in: ipv6(F)(U) xfs(F)(U) xennet(F)(U) xenblk(F)(U) ex=
t3
> >>>> (F)(U) jbd(F)(U) mbcache(F)(U)
> >>>> CPU: =A0 =A00
> >>>> EIP: =A0 =A00061:[<c101bf0e>] =A0 =A0Tainted: GF =A0 =A0 =A0VLI
> >>>> EFLAGS: 00210282 =A0 (2.6.21.7-2.fc8xen-ec2-v1.0 #2)
> >>>> EIP is at xen_pgd_pin+0x54/0x5e
> >>>> eax: ffffffea =A0 ebx: c1411ef8 =A0 ecx: 00000001 =A0 edx: 00000000
> >>>> esi: 00007ff0 =A0 edi: 00000000 =A0 ebp: c140f490 =A0 esp: c1411ef8
> >>>> ds: 007b =A0 es: 007b =A0 fs: 00d8 =A0gs: 0033 =A0ss: 0069
> >>>> Process syslogd (pid: 1031, ti=3Dc1411000 task=3Dc140d450
> >>>> task.ti=3Dc1411000)
> >>>> Stack: 00000002 002916f9 2d176000 005a2ec0 00000000 c101816d c14b028=
0
> >>>> c1018196
> >>>> =A0 =A0 =A0 =A0c15f10cc c102250e c15f15b8 c1411fb8 c106e111 c1411fb8=
 bff296b4
> >>>> 01200011
> >>>> =A0 =A0 =A0 =A000000000 c140f490 c14b0280 c14b0080 c15f10d8 c15f10ec=
 c15f10e8
> >>>> c14b0280
> >>>> Call Trace:
> >>>> =A0[<c101816d>] __pgd_pin+0x2f/0x3c
> >>>> =A0[<c1018196>] mm_pin+0x1c/0x23
> >>>> =A0[<c102250e>] copy_process+0xac3/0x10bc
> >>>> =A0[<c106e111>] kmem_cache_alloc+0x23/0x98
> >>>> =A0[<c1022b58>] do_fork+0x51/0x13a
> >>>> =A0[<c10e48a8>] copy_to_user+0x3c/0x50
> >>>> =A0[<c100321e>] sys_clone+0x36/0x3b
> >>>> =A0[<c1005688>] syscall_call+0x7/0xb
> >>>> =A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
> >>>> Code: eb fe a1 24 c2 38 c1 8b 14 90 81 e2 ff ff ff 7f 89 54 24 04 89
> >>>> e3 b9 01 00 00 00 31 d2 be f0 7f 00 00 e8 36 54 fe ff 85 c0 79 04 <0=
f>
> >>>> 0b eb fe 83 c4 0c 5b 5e c3 56 89 c2 53 83 ec 0c c1 ea 0c 80
> >>>> EIP: [<c101bf0e>] xen_pgd_pin+0x54/0x5e SS:ESP 0069:c1411ef8
> >>>> On Oct 15, 1:21 am, Eric Hammond <ehamm...@thinksome.com> wrote:
> >>>>> Robert:
> >>>>> Thanks for providing such an easy way to reproduce this problem.
> >>>>> In retrospect, I guess we should have seen this coming. =A0With Ama=
zon's
> >>>>> previous 2.6.21 kernel, the original xfs kernel module worked fine =
with
> >>>>> Hardy and Intrepid, but caused problems with Jaunty. =A0Because of =
this,
> >>>>> Amazon build a special xfs.ko which I installed with Jaunty images.
> >>>>> With Amazon's newest 2.6.21 kernel and kernel modules, XFS seems to=
 work
> >>>>> fine on Jaunty but breaks with Hardy and Intrepid (after reboot).
> >>>>> I've posted a request for help from Amazon:
> >>>>>http://developer.amazonwebservices.com/connect/thread.jspa?threadID=
=3D3...
> >>>>> --
> >>>>> Eric Hammond
> >>>>> Robert Coup wrote:
> >>>>>> Hey folks,
> >>>>>> On Wed, Oct 14, 2009 at 11:14 PM, Eric Hammond <ehamm...@thinksome=
.com
> >>>>>> <mailto:ehamm...@thinksome.com>> wrote:
> >>>>>> =A0 =A0 In the 20091011 batch of AMIs published on Alestic.com I s=
witched to
> >>>>>> =A0 =A0 Amazon's kernel modules instead of building my own from so=
urce.
> >>>>>> I'm getting kernel crashes with XFS on the newest Alestic Intrepid=
 images:
> >>>>>> =A0 ami-c0f615a9
> >>>>>> =A0 32bit/m1.small instance
> >>>>>> =A0 default aki/ari, reported as 2.6.21.7-2.fc8xen-ec2-v1.0
> >>>>>> Boot with the following user-data script:
> >>>>>> =A0 #!/bin/bash
> >>>>>> =A0 apt-get update
> >>>>>> =A0 apt-get install xfsprogs
> >>>>>> =A0 umount /mnt
> >>>>>> =A0 mkfs.xfs /dev/sda2 -f
> >>>>>> =A0 FSTAB_ENTRY=3D'/dev/sda2 /mnt xfs defaults,relatime 0 0'
> >>>>>> =A0 perl -pi -e "s%^.* /mnt .*%${FSTAB_ENTRY}%" /etc/fstab
> >>>>>> =A0 mount /mnt
> >>>>>> =A0 touch /mnt/some-file
> >>>>>> =A0 reboot
> >>>>>> kapow! kernel oops every time when the system starts up 2nd time (=
and
> >>>>>> subsequently)
> >>>>>> I guess it's related to one of the other recent threads, but i tho=
ught
> >>>>>> they were all 2.6.18 related...
> >>>>>> Console log (initial + reboot):http://pastebin.com/fc54044b
> >>>>>> Should i be running a different aki/ari?
> >>>>>> Rob :)
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
