Hi folks,
I've put together a script to create up-to-date F17 snapshot images and am storing the result on my people page. These are based on Peter's F17 alpha1 images with the following changes:
There is a tarball without any kernels included.
There is a tarball with uBoot-wrapped kernels included (should have everything you need without messy mkimage commands). The armhfp version includes tegra, omap and imx kernels. The arm version includes kirkwood.
There are bzcat+dd images for Tegra and OMAP- no partitioning necessary to get started. These decompress to 8GB- if you have a larger storage device resize2fs is your friend.
The files are currently uploading and will be entirely there in a few more minutes. You can get the latest at:
http://blc.fedorapeople.org/fedora-arm/f17/
This is very much a work in progress, completely unofficial, largely untested, but hopefully useful. Feel free to send me feedback. Enjoy,
On 03/29/2012 11:20 PM, Brendan Conoboy wrote:
There is a tarball with uBoot-wrapped kernels included (should have everything you need without messy mkimage commands). The armhfp version includes tegra, omap and imx kernels. The arm version includes kirkwood.
Oh, and the kernels are 2.6.4x.fc15 kernels which are known to work.
On 03/30/2012 02:20 PM, Somebody in the thread at some point said:
Hi folks,
I've put together a script to create up-to-date F17 snapshot images and am storing the result on my people page. These are based on Peter's F17 alpha1 images with the following changes:
There is a tarball without any kernels included.
There is a tarball with uBoot-wrapped kernels included (should have everything you need without messy mkimage commands). The armhfp version includes tegra, omap and imx kernels. The arm version includes kirkwood.
There are bzcat+dd images for Tegra and OMAP- no partitioning necessary to get started. These decompress to 8GB- if you have a larger storage device resize2fs is your friend.
It's great that you're doing this, but I don't think dding partition + filesystems is a good idea.
We found that various "8GB" SD cards have different absolute numbers of available sectors, it can lead to eventual filesystem corruption if your image is slightly large than someone else's card.
If someone's going to try this they're probably OK running fdisk and using tarballs.
The files are currently uploading and will be entirely there in a few more minutes. You can get the latest at:
http://blc.fedorapeople.org/fedora-arm/f17/
This is very much a work in progress, completely unofficial, largely untested, but hopefully useful. Feel free to send me feedback. Enjoy,
I've been using Peter's F17 alpha1 image and following progress with updates, it's been very good. It's stuck as of last week with gnome-shell problems though. But generally package completeness has been increasing really well last few weeks, great job.
-Andy
On 03/30/2012 05:35 PM, "Andy Green (林安廸)" wrote:
It's great that you're doing this, but I don't think dding partition + filesystems is a good idea.
It's definitely tricky to get right. The number of possible configurations makes it tricky to do an efficient selection of images. I may end up doing a combination tegra+omap+etc image to cut down the waste.
We found that various "8GB" SD cards have different absolute numbers of available sectors, it can lead to eventual filesystem corruption if your image is slightly large than someone else's card.
Well, the image is being created out of a sparse file with 8000 1048576 byte sectors. If that proves too many it would be little trouble to drop it down to 7900 or something. We'll see how it goes in practice.
If someone's going to try this they're probably OK running fdisk and using tarballs.
Yeah, the uboot enabled kernel tarball will probably be the most universally useful. I personally had plenty of trouble marking working uboot files so leveraging David Marlin's work on grubby will hopefully spare others that trouble. Meanwhile, a number of people have asked for images they can dd, so I'm trying to fulfill both needs.
I've been using Peter's F17 alpha1 image and following progress with updates, it's been very good. It's stuck as of last week with gnome-shell problems though. But generally package completeness has been increasing really well last few weeks, great job.
What are the gnome-shell problems? Perhaps they're well known but I'm not acquainted with them. If we're missing a package that will help things out let me know and I'll put it in the next snapshot.
On Sat, Mar 31, 2012 at 2:20 AM, Brendan Conoboy blc@redhat.com wrote:
On 03/30/2012 05:35 PM, "Andy Green (林安廸)" wrote:
It's great that you're doing this, but I don't think dding partition + filesystems is a good idea.
It's definitely tricky to get right. The number of possible configurations makes it tricky to do an efficient selection of images. I may end up doing a combination tegra+omap+etc image to cut down the waste.
We found that various "8GB" SD cards have different absolute numbers of available sectors, it can lead to eventual filesystem corruption if your image is slightly large than someone else's card.
Well, the image is being created out of a sparse file with 8000 1048576 byte sectors. If that proves too many it would be little trouble to drop it down to 7900 or something. We'll see how it goes in practice.
If someone's going to try this they're probably OK running fdisk and using tarballs.
Yeah, the uboot enabled kernel tarball will probably be the most universally useful. I personally had plenty of trouble marking working uboot files so leveraging David Marlin's work on grubby will hopefully spare others that trouble. Meanwhile, a number of people have asked for images they can dd, so I'm trying to fulfill both needs.
I've been using Peter's F17 alpha1 image and following progress with updates, it's been very good. It's stuck as of last week with gnome-shell problems though. But generally package completeness has been increasing really well last few weeks, great job.
What are the gnome-shell problems? Perhaps they're well known but I'm not acquainted with them. If we're missing a package that will help things out let me know and I'll put it in the next snapshot.
It'll be dep issues, I'm awaiting the reopening of mainline so we'll get updates.
Peter
On 03/31/2012 09:20 AM, Somebody in the thread at some point said:
On 03/30/2012 05:35 PM, "Andy Green (林安廸)" wrote:
It's great that you're doing this, but I don't think dding partition + filesystems is a good idea.
It's definitely tricky to get right. The number of possible configurations makes it tricky to do an efficient selection of images. I may end up doing a combination tegra+omap+etc image to cut down the waste.
We found that various "8GB" SD cards have different absolute numbers of available sectors, it can lead to eventual filesystem corruption if your image is slightly large than someone else's card.
Well, the image is being created out of a sparse file with 8000 1048576 byte sectors. If that proves too many it would be little trouble to drop it down to 7900 or something. We'll see how it goes in practice.
Just saying if the filesystem in there at the end doesn't all make it on the device, it will work for a while and die corrupted. It won't hurt to pare it back 100MB.
If someone's going to try this they're probably OK running fdisk and using tarballs.
Yeah, the uboot enabled kernel tarball will probably be the most universally useful. I personally had plenty of trouble marking working uboot files so leveraging David Marlin's work on grubby will hopefully spare others that trouble. Meanwhile, a number of people have asked for images they can dd, so I'm trying to fulfill both needs.
Yes working with U-Boot isn't pretty.
I've been using Peter's F17 alpha1 image and following progress with updates, it's been very good. It's stuck as of last week with gnome-shell problems though. But generally package completeness has been increasing really well last few weeks, great job.
What are the gnome-shell problems? Perhaps they're well known but I'm not acquainted with them. If we're missing a package that will help things out let me know and I'll put it in the next snapshot.
It's not deps afaict, a couple of weeks ago pieces were missing, but there now is enough to yum install @gnome-desktop sanely with --skip-broken; abrt, elfutils, gdb, libreport and xmlrpc-c are skipped. Here anyway the resulting gdm / gnome ends up showing "Oh no! Something has gone wrong." before gdm login.
Poking around in gdm logs shows a segfault after not being able to find org.gnome.SessionManager |not provided by any .service files". I had to mess with a javascript file in gnome to get that info, it was otherwise complaining that there were too many args sent to the logging api.
-Andy
On 03/31/2012 09:28 PM, Somebody in the thread at some point said:
What are the gnome-shell problems? Perhaps they're well known but I'm not acquainted with them. If we're missing a package that will help things out let me know and I'll put it in the next snapshot.
It's not deps afaict, a couple of weeks ago pieces were missing, but there now is enough to yum install @gnome-desktop sanely with --skip-broken; abrt, elfutils, gdb, libreport and xmlrpc-c are skipped. Here anyway the resulting gdm / gnome ends up showing "Oh no! Something has gone wrong." before gdm login.
Poking around in gdm logs shows a segfault after not being able to find org.gnome.SessionManager |not provided by any .service files". I had to mess with a javascript file in gnome to get that info, it was otherwise complaining that there were too many args sent to the logging api.
Now that gdb is available I can see the issue boils down to segfault in llvm. I installed the 1GB (installed size) of debuginfos and got this backtrace
#0 emitInstruction (MI=..., this=0x1394f8) at ARMCodeEmitter.cpp:576 #1 (anonymous namespace)::ARMCodeEmitter::runOnMachineFunction (this=0x1394f8, MF=...) at ARMCodeEmitter.cpp:391 #2 0xb3881960 in runOnFunction (this=0x1394f8, F=...) at MachineFunctionPass.cpp:33 #3 llvm::MachineFunctionPass::runOnFunction (this=0x1394f8, F=...) at MachineFunctionPass.cpp:26 #4 0xb366a204 in llvm::FPPassManager::runOnFunction (this=0x107620, F=...) at PassManager.cpp:1512 #5 0xb366a378 in llvm::FunctionPassManagerImpl::run (this=0x107468, F=...) at PassManager.cpp:1462 #6 0xb366a45c in llvm::FunctionPassManager::run (this=0x116340, F=...) at PassManager.cpp:1391 #7 0xb3b1fc88 in llvm::JIT::jitTheFunction (this=this@entry=0x105cb0, F=F@entry=0xc1ef30, locked=...) at JIT.cpp:639 #8 0xb3b1ff90 in llvm::JIT::runJITOnFunctionUnlocked (this=this@entry=0x105cb0, F=F@entry=0xc1ef30, locked=...) at JIT.cpp:618 #9 0xb3b200b4 in llvm::JIT::getPointerToFunction (this=0x105cb0, F=0xc1ef30) at JIT.cpp:675 #10 0xb359ef20 in llvm::ExecutionEngine::getPointerToGlobal (this=0x105cb0, GV=0xc1ef30) at ExecutionEngine.cpp:505 #11 0xb42daa5c in generate_fragment (lp=0xb455f3d4, lp@entry=0x235680, shader=0xc60744, shader@entry=0xc1c7c8, variant=0xc1c7c8, variant@entry=0xb93440, partial_mask=3025531860, partial_mask@entry=1) at lp_state_fs.c:812 #12 0xb42db410 in generate_variant (key=0xbeffd6ac, shader=0xc1c7c8, lp=0x235680) at lp_state_fs.c:968 #13 llvmpipe_update_fs (lp=lp@entry=0x235680) at lp_state_fs.c:1399 #14 0xb42d9258 in llvmpipe_update_derived (e=e@entry=0x235680) at lp_state_derived.c:155 #15 0xb42cb9d0 in llvmpipe_draw_vbo (pipe=0x235680, info=0xbeffd880) at lp_draw_arrays.c:64 #16 0xb4382874 in st_draw_vbo (ctx=0x0, arrays=<optimized out>, prims=<optimized out>, nr_prims=0, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=1, tfb_vertcount=0x0) at state_tracker/st_draw.c:1112 #17 0xb437be0c in vbo_draw_arrays (ctx=ctx@entry=0x1d50f8, mode=mode@entry=7, start=start@entry=0, count=count@entry=4, numInstances=numInstances@entry=1) at vbo/vbo_exec_array.c:600 #18 0xb437bef8 in vbo_exec_DrawArrays (mode=7, start=0, count=4) at vbo/vbo_exec_array.c:632 #19 0xb543585c in shared_dispatch_stub_310 (mode=7, first=<optimized out>, count=<optimized out>) at ../../../src/mapi/shared-glapi/glapi_mapi_tmp.h:14992 #20 0xb62f11ac in ?? () from /lib/libcogl.so.8 #21 0xb62ed198 in ?? () from /lib/libcogl.so.8 #22 0xb62ec3ac in ?? () from /lib/libcogl.so.8 #23 0xb62ecf4c in ?? () from /lib/libcogl.so.8 #24 0xb62ec3ac in ?? () from /lib/libcogl.so.8 #25 0xb62ecd00 in ?? () from /lib/libcogl.so.8 #26 0xb62ec3ac in ?? () from /lib/libcogl.so.8 #27 0xb62ec8f4 in ?? () from /lib/libcogl.so.8 #28 0xb62ec3ac in ?? () from /lib/libcogl.so.8 #29 0xb62ede70 in ?? () from /lib/libcogl.so.8 #30 0xb62c166c in cogl_flush () from /lib/libcogl.so.8 #31 0xb62ea9c0 in ?? () from /lib/libcogl.so.8 #32 0xb5760b00 in g_hook_list_invoke () from /lib/libglib-2.0.so.0 #33 0xb62e9bfc in _cogl_atlas_reserve_space () from /lib/libcogl.so.8 #34 0xb62ead50 in _cogl_atlas_texture_new_with_size () from /lib/libcogl.so.8 #35 0xb62eafc4 in ?? () from /lib/libcogl.so.8 #36 0xb62e40f0 in cogl_texture_new_from_bitmap () from /lib/libcogl.so.8 #37 0xb62e4190 in cogl_texture_new_from_data () from /lib/libcogl.so.8 #38 0xb6fac9c8 in st_theme_node_paint () from /usr/lib/gnome-shell/libgnome-shell.so #39 0xb6fb19ac in st_widget_paint_background () from /usr/lib/gnome-shell/libgnome-shell.so #40 0xb6fb19cc in ?? () from /usr/lib/gnome-shell/libgnome-shell.so #41 0xb5846488 in g_cclosure_marshal_VOID__VOIDv () from /lib/libgobject-2.0.so.0 #42 0xb5842658 in ?? () from /lib/libgobject-2.0.so.0 #43 0xb58445cc in ?? () from /lib/libgobject-2.0.so.0 #44 0xb585f3f4 in g_signal_emit_valist () from /lib/libgobject-2.0.so.0 #45 0xb585fa64 in g_signal_emit () from /lib/libgobject-2.0.so.0 #46 0xb6378d0c in clutter_actor_continue_paint () from /lib/libclutter-1.0.so.0 #47 0xb638a25c in ?? () from /lib/libclutter-1.0.so.0 #48 0xb6f8f84c in ?? () from /usr/lib/gnome-shell/libgnome-shell.so #49 0xb5846488 in g_cclosure_marshal_VOID__VOIDv () from /lib/libgobject-2.0.so.0 #50 0xb5842658 in ?? () from /lib/libgobject-2.0.so.0 #51 0xb58445cc in ?? () from /lib/libgobject-2.0.so.0 #52 0xb585f3f4 in g_signal_emit_valist () from /lib/libgobject-2.0.so.0 #53 0xb585fa64 in g_signal_emit () from /lib/libgobject-2.0.so.0 #54 0xb6378d0c in clutter_actor_continue_paint () from /lib/libclutter-1.0.so.0 #55 0xb638a25c in ?? () from /lib/libclutter-1.0.so.0 #56 0xb6f7c428 in ?? () from /usr/lib/gnome-shell/libgnome-shell.so #57 0xb5846488 in g_cclosure_marshal_VOID__VOIDv () from /lib/libgobject-2.0.so.0 #58 0xb5842658 in ?? () from /lib/libgobject-2.0.so.0 #59 0xb58445cc in ?? () from /lib/libgobject-2.0.so.0 #60 0xb585f3f4 in g_signal_emit_valist () from /lib/libgobject-2.0.so.0 #61 0xb585fa64 in g_signal_emit () from /lib/libgobject-2.0.so.0 #62 0xb6378d0c in clutter_actor_continue_paint () from /lib/libclutter-1.0.so.0 #63 0xb638a25c in ?? () from /lib/libclutter-1.0.so.0 #64 0xb63d456c in ?? () from /lib/libclutter-1.0.so.0 #65 0xb5846434 in g_cclosure_marshal_VOID__VOID () from /lib/libgobject-2.0.so.0 #66 0xb5842db8 in ?? () from /lib/libgobject-2.0.so.0 #67 0xb58443d4 in g_closure_invoke () from /lib/libgobject-2.0.so.0 #68 0xb5856bec in ?? () from /lib/libgobject-2.0.so.0 #69 0xb585f878 in g_signal_emit_valist () from /lib/libgobject-2.0.so.0 #70 0xb585fa64 in g_signal_emit () from /lib/libgobject-2.0.so.0 #71 0xb6378d0c in clutter_actor_continue_paint () from /lib/libclutter-1.0.so.0 #72 0xb638a25c in ?? () from /lib/libclutter-1.0.so.0 #73 0xb63d8764 in ?? () from /lib/libclutter-1.0.so.0 #74 0xb63732f8 in ?? () from /lib/libclutter-1.0.so.0 #75 0xb63da48c in ?? () from /lib/libclutter-1.0.so.0 #76 0xb63d7160 in ?? () from /lib/libclutter-1.0.so.0 #77 0xb63bf884 in ?? () from /lib/libclutter-1.0.so.0 #78 0xb576f68c in g_main_context_dispatch () from /lib/libglib-2.0.so.0 #79 0xb576fad0 in ?? () from /lib/libglib-2.0.so.0 #80 0xb576fef4 in g_main_loop_run () from /lib/libglib-2.0.so.0 #81 0xb6e4cd38 in meta_run () from /lib/libmutter.so.0 #82 0x000098a8 in main ()
Is llvm / gnome-shell expected to give a good result with framebuffer X driver at the moment (on hardfloat)? Or is it a problem with my background image (not sure what that is right now).
-Andy
On Sat, Apr 7, 2012 at 4:06 AM, "Andy Green (林安廸)" andy@warmcat.com wrote:
On 03/31/2012 09:28 PM, Somebody in the thread at some point said:
What are the gnome-shell problems? Perhaps they're well known but I'm not acquainted with them. If we're missing a package that will help things out let me know and I'll put it in the next snapshot.
It's not deps afaict, a couple of weeks ago pieces were missing, but there now is enough to yum install @gnome-desktop sanely with --skip-broken; abrt, elfutils, gdb, libreport and xmlrpc-c are skipped. Here anyway the resulting gdm / gnome ends up showing "Oh no! Something has gone wrong." before gdm login.
Poking around in gdm logs shows a segfault after not being able to find org.gnome.SessionManager |not provided by any .service files". I had to mess with a javascript file in gnome to get that info, it was otherwise complaining that there were too many args sent to the logging api.
Now that gdb is available I can see the issue boils down to segfault in llvm. I installed the 1GB (installed size) of debuginfos and got this backtrace
#0 emitInstruction (MI=..., this=0x1394f8) at ARMCodeEmitter.cpp:576 #1 (anonymous namespace)::ARMCodeEmitter::runOnMachineFunction (this=0x1394f8, MF=...) at ARMCodeEmitter.cpp:391 #2 0xb3881960 in runOnFunction (this=0x1394f8, F=...) at MachineFunctionPass.cpp:33 #3 llvm::MachineFunctionPass::runOnFunction (this=0x1394f8, F=...) at MachineFunctionPass.cpp:26 #4 0xb366a204 in llvm::FPPassManager::runOnFunction (this=0x107620, F=...) at PassManager.cpp:1512 #5 0xb366a378 in llvm::FunctionPassManagerImpl::run (this=0x107468, F=...) at PassManager.cpp:1462 #6 0xb366a45c in llvm::FunctionPassManager::run (this=0x116340, F=...) at PassManager.cpp:1391 #7 0xb3b1fc88 in llvm::JIT::jitTheFunction (this=this@entry=0x105cb0, F=F@entry=0xc1ef30, locked=...) at JIT.cpp:639 #8 0xb3b1ff90 in llvm::JIT::runJITOnFunctionUnlocked (this=this@entry=0x105cb0, F=F@entry=0xc1ef30, locked=...) at JIT.cpp:618 #9 0xb3b200b4 in llvm::JIT::getPointerToFunction (this=0x105cb0, F=0xc1ef30) at JIT.cpp:675 #10 0xb359ef20 in llvm::ExecutionEngine::getPointerToGlobal (this=0x105cb0, GV=0xc1ef30) at ExecutionEngine.cpp:505 #11 0xb42daa5c in generate_fragment (lp=0xb455f3d4, lp@entry=0x235680, shader=0xc60744, shader@entry=0xc1c7c8, variant=0xc1c7c8, variant@entry=0xb93440, partial_mask=3025531860, partial_mask@entry=1) at lp_state_fs.c:812 #12 0xb42db410 in generate_variant (key=0xbeffd6ac, shader=0xc1c7c8, lp=0x235680) at lp_state_fs.c:968 #13 llvmpipe_update_fs (lp=lp@entry=0x235680) at lp_state_fs.c:1399 #14 0xb42d9258 in llvmpipe_update_derived (e=e@entry=0x235680) at lp_state_derived.c:155 #15 0xb42cb9d0 in llvmpipe_draw_vbo (pipe=0x235680, info=0xbeffd880) at lp_draw_arrays.c:64 #16 0xb4382874 in st_draw_vbo (ctx=0x0, arrays=<optimized out>, prims=<optimized out>, nr_prims=0, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=1, tfb_vertcount=0x0) at state_tracker/st_draw.c:1112 #17 0xb437be0c in vbo_draw_arrays (ctx=ctx@entry=0x1d50f8, mode=mode@entry=7, start=start@entry=0, count=count@entry=4, numInstances=numInstances@entry=1) at vbo/vbo_exec_array.c:600 #18 0xb437bef8 in vbo_exec_DrawArrays (mode=7, start=0, count=4) at vbo/vbo_exec_array.c:632 #19 0xb543585c in shared_dispatch_stub_310 (mode=7, first=<optimized out>, count=<optimized out>) at ../../../src/mapi/shared-glapi/glapi_mapi_tmp.h:14992 #20 0xb62f11ac in ?? () from /lib/libcogl.so.8 #21 0xb62ed198 in ?? () from /lib/libcogl.so.8 #22 0xb62ec3ac in ?? () from /lib/libcogl.so.8 #23 0xb62ecf4c in ?? () from /lib/libcogl.so.8 #24 0xb62ec3ac in ?? () from /lib/libcogl.so.8 #25 0xb62ecd00 in ?? () from /lib/libcogl.so.8 #26 0xb62ec3ac in ?? () from /lib/libcogl.so.8 #27 0xb62ec8f4 in ?? () from /lib/libcogl.so.8 #28 0xb62ec3ac in ?? () from /lib/libcogl.so.8 #29 0xb62ede70 in ?? () from /lib/libcogl.so.8 #30 0xb62c166c in cogl_flush () from /lib/libcogl.so.8 #31 0xb62ea9c0 in ?? () from /lib/libcogl.so.8 #32 0xb5760b00 in g_hook_list_invoke () from /lib/libglib-2.0.so.0 #33 0xb62e9bfc in _cogl_atlas_reserve_space () from /lib/libcogl.so.8 #34 0xb62ead50 in _cogl_atlas_texture_new_with_size () from /lib/libcogl.so.8 #35 0xb62eafc4 in ?? () from /lib/libcogl.so.8 #36 0xb62e40f0 in cogl_texture_new_from_bitmap () from /lib/libcogl.so.8 #37 0xb62e4190 in cogl_texture_new_from_data () from /lib/libcogl.so.8 #38 0xb6fac9c8 in st_theme_node_paint () from /usr/lib/gnome-shell/libgnome-shell.so #39 0xb6fb19ac in st_widget_paint_background () from /usr/lib/gnome-shell/libgnome-shell.so #40 0xb6fb19cc in ?? () from /usr/lib/gnome-shell/libgnome-shell.so #41 0xb5846488 in g_cclosure_marshal_VOID__VOIDv () from /lib/libgobject-2.0.so.0 #42 0xb5842658 in ?? () from /lib/libgobject-2.0.so.0 #43 0xb58445cc in ?? () from /lib/libgobject-2.0.so.0 #44 0xb585f3f4 in g_signal_emit_valist () from /lib/libgobject-2.0.so.0 #45 0xb585fa64 in g_signal_emit () from /lib/libgobject-2.0.so.0 #46 0xb6378d0c in clutter_actor_continue_paint () from /lib/libclutter-1.0.so.0 #47 0xb638a25c in ?? () from /lib/libclutter-1.0.so.0 #48 0xb6f8f84c in ?? () from /usr/lib/gnome-shell/libgnome-shell.so #49 0xb5846488 in g_cclosure_marshal_VOID__VOIDv () from /lib/libgobject-2.0.so.0 #50 0xb5842658 in ?? () from /lib/libgobject-2.0.so.0 #51 0xb58445cc in ?? () from /lib/libgobject-2.0.so.0 #52 0xb585f3f4 in g_signal_emit_valist () from /lib/libgobject-2.0.so.0 #53 0xb585fa64 in g_signal_emit () from /lib/libgobject-2.0.so.0 #54 0xb6378d0c in clutter_actor_continue_paint () from /lib/libclutter-1.0.so.0 #55 0xb638a25c in ?? () from /lib/libclutter-1.0.so.0 #56 0xb6f7c428 in ?? () from /usr/lib/gnome-shell/libgnome-shell.so #57 0xb5846488 in g_cclosure_marshal_VOID__VOIDv () from /lib/libgobject-2.0.so.0 #58 0xb5842658 in ?? () from /lib/libgobject-2.0.so.0 #59 0xb58445cc in ?? () from /lib/libgobject-2.0.so.0 #60 0xb585f3f4 in g_signal_emit_valist () from /lib/libgobject-2.0.so.0 #61 0xb585fa64 in g_signal_emit () from /lib/libgobject-2.0.so.0 #62 0xb6378d0c in clutter_actor_continue_paint () from /lib/libclutter-1.0.so.0 #63 0xb638a25c in ?? () from /lib/libclutter-1.0.so.0 #64 0xb63d456c in ?? () from /lib/libclutter-1.0.so.0 #65 0xb5846434 in g_cclosure_marshal_VOID__VOID () from /lib/libgobject-2.0.so.0 #66 0xb5842db8 in ?? () from /lib/libgobject-2.0.so.0 #67 0xb58443d4 in g_closure_invoke () from /lib/libgobject-2.0.so.0 #68 0xb5856bec in ?? () from /lib/libgobject-2.0.so.0 #69 0xb585f878 in g_signal_emit_valist () from /lib/libgobject-2.0.so.0 #70 0xb585fa64 in g_signal_emit () from /lib/libgobject-2.0.so.0 #71 0xb6378d0c in clutter_actor_continue_paint () from /lib/libclutter-1.0.so.0 #72 0xb638a25c in ?? () from /lib/libclutter-1.0.so.0 #73 0xb63d8764 in ?? () from /lib/libclutter-1.0.so.0 #74 0xb63732f8 in ?? () from /lib/libclutter-1.0.so.0 #75 0xb63da48c in ?? () from /lib/libclutter-1.0.so.0 #76 0xb63d7160 in ?? () from /lib/libclutter-1.0.so.0 #77 0xb63bf884 in ?? () from /lib/libclutter-1.0.so.0 #78 0xb576f68c in g_main_context_dispatch () from /lib/libglib-2.0.so.0 #79 0xb576fad0 in ?? () from /lib/libglib-2.0.so.0 #80 0xb576fef4 in g_main_loop_run () from /lib/libglib-2.0.so.0 #81 0xb6e4cd38 in meta_run () from /lib/libmutter.so.0 #82 0x000098a8 in main ()
Is llvm / gnome-shell expected to give a good result with framebuffer X driver at the moment (on hardfloat)? Or is it a problem with my background image (not sure what that is right now).
I very much doubt gnome-shell will give a good result on any fbdev device as it needs 3D.
Peter
On 04/07/2012 11:52 PM, Somebody in the thread at some point said:
Is llvm / gnome-shell expected to give a good result with framebuffer X driver at the moment (on hardfloat)? Or is it a problem with my background image (not sure what that is right now).
I very much doubt gnome-shell will give a good result on any fbdev device as it needs 3D.
It does need to draw in 3D but AIUI that doesn't mean it needs 3D-capable device --->
http://lists.fedoraproject.org/pipermail/devel/2011-November/158976.html
-Andy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 30 Mar 2012 18:20:17 -0700 Brendan Conoboy blc@redhat.com wrote:
On 03/30/2012 05:35 PM, "Andy Green (林安廸)" wrote:
It's great that you're doing this, but I don't think dding partition + filesystems is a good idea.
It's definitely tricky to get right. The number of possible configurations makes it tricky to do an efficient selection of images. I may end up doing a combination tegra+omap+etc image to cut down the waste.
We found that various "8GB" SD cards have different absolute numbers of available sectors, it can lead to eventual filesystem corruption if your image is slightly large than someone else's card.
Well, the image is being created out of a sparse file with 8000 1048576 byte sectors. If that proves too many it would be little trouble to drop it down to 7900 or something. We'll see how it goes in practice.
i think we should only make the image 2 gb using domething like "dd if=/dev/zero of/raw/disk bs=1M count=2048" cound could be 2000 also then it should work everywhere.
If someone's going to try this they're probably OK running fdisk and using tarballs.
the idea is to get to a point where its simple to deploy lower the barrier of entry.
Yeah, the uboot enabled kernel tarball will probably be the most universally useful. I personally had plenty of trouble marking working uboot files so leveraging David Marlin's work on grubby will hopefully spare others that trouble. Meanwhile, a number of people have asked for images they can dd, so I'm trying to fulfill both needs.
I've been using Peter's F17 alpha1 image and following progress with updates, it's been very good. It's stuck as of last week with gnome-shell problems though. But generally package completeness has been increasing really well last few weeks, great job.
What are the gnome-shell problems? Perhaps they're well known but I'm not acquainted with them. If we're missing a package that will help things out let me know and I'll put it in the next snapshot.
there is gnome 3.4.0 in testing on primary now there is a change it will get pushed to stable for beta on monday if not its probably 2 weeks away. What we need to do is come up with a set of F17 beta deliverables and work really hard in the next 2 weeks to deliver a F17 Beta.
Dennis
On Sat, 2012-03-31 at 09:52 -0500, Dennis Gilmore wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 30 Mar 2012 18:20:17 -0700 Brendan Conoboy blc@redhat.com wrote:
On 03/30/2012 05:35 PM, "Andy Green (林安廸)" wrote:
It's great that you're doing this, but I don't think dding partition + filesystems is a good idea.
It's definitely tricky to get right. The number of possible configurations makes it tricky to do an efficient selection of images. I may end up doing a combination tegra+omap+etc image to cut down the waste.
We found that various "8GB" SD cards have different absolute numbers of available sectors, it can lead to eventual filesystem corruption if your image is slightly large than someone else's card.
Well, the image is being created out of a sparse file with 8000 1048576 byte sectors. If that proves too many it would be little trouble to drop it down to 7900 or something. We'll see how it goes in practice.
i think we should only make the image 2 gb using domething like "dd if=/dev/zero of/raw/disk bs=1M count=2048" cound could be 2000 also then it should work everywhere.
On the Raspberry Pi Fedora Remix I'm shrinking the image as much as possible by shortening the last (root) partition. The partition is resized to fill the SD card on first boot (fdisk, reboot, resize2fs). This results in a small image size, minimizes unnecessary writes to the SD card, works on any card size, and lets you take full advantage of the space on the card.
Perhaps we should adopt that approach for the images?
-Chris
On 03/31/2012 08:10 AM, Chris Tyler wrote:
On the Raspberry Pi Fedora Remix I'm shrinking the image as much as possible by shortening the last (root) partition. The partition is resized to fill the SD card on first boot (fdisk, reboot, resize2fs). This results in a small image size, minimizes unnecessary writes to the SD card, works on any card size, and lets you take full advantage of the space on the card.
Perhaps we should adopt that approach for the images?
Would be happy to add this- with that sort of functionality I'd have no reservation about creating a 1.990GB image. Send me a pointer to how you're doing this during the first boot and I'll integrate it into the rootfs image generator.
Hi everybody,
Based on the feedback on these images I've gone through a few more iterations of the build scripts and they've had some testing (thanks dmarlin, pbrobinson and smooge!).
There are now images for:
Trimslice (hard float, mmc and sda) Panda (hard float, mmc, and sda) Beagle (hard/soft, mmc)
To install the image a command just use a command like:
xzcat f17arm-latest-armhfp-trimslice-mmcblk0.img.xz > /dev/device
For reasons I'm not acquainted with using dd with a large bs value sometimes results in bad writes, so if you use dd keep bs small.
Each image decompresses to 1900MB. Upon first boot it will begin the process of auto-resize the / partition to its full capacity. A second boot will complete the process (This is done using a modified version of Chris Tyler's raspberry pi remix resize script).
All scripts used to generate the images is included in the same directory. Next up will likely be a unified trimslice/panda image. Fun!
-
Andy Green -
Brendan Conoboy -
Chris Tyler -
Dennis Gilmore -
Peter Robinson