Re: sabotage linux X86_64 image with LXDE desktop released

Re: sabotage linux X86_64 image with LXDE desktop released

[Rich Felker]

On Sat, Jul 21, 2012 at 10:59:11PM +0200, John Spencer wrote:
> the desktop works, but is not polished at all - there's no
> background image and the icon paths seem to be misconfigured.
> this can be considered a technoloy preview.
> here is a screenshot: http://i.imgur.com/Lz7Ov.png

Something seems very wrong with those task manager vm sizes...
Is this indicative of a bug on musl's side?

Rich

sabotage linux X86_64 image with LXDE desktop released

[John Spencer]

I uploaded an image file of my latest sabotage build from

https://github.com/rofl0r/sabotage

it comes with tinyx and LXDE installed. start X server with "startx" (if 
it fails to start, try to launch it again, there are some timing issues)

the desktop works, but is not polished at all - there's no background 
image and the icon paths seem to be misconfigured.
this can be considered a technoloy preview.
here is a screenshot: http://i.imgur.com/Lz7Ov.png

feel free to tweak the desktop and the X11 settings and file pull 
requests on github.
additional packages can be installed as on the sabotage chroot  - cd 
/src ; vi config ; . config ; butch install packagename (i.e. luajit)

the base system itself can be considered quite stable and moderately 
well tested at the moment.
there are likely some security patches missing, but the kernel used is 
grsec patched.
so if you intend to use gdb you may have to override some ptrace 
settings using paxctl.
(or build your own kernel with grsec disabled, see /src/pkg/kernel)

root password is sabotage

dont forget to read README in github repo

Image files are available athttp://mirror.wzff.de/sabotage/

http://mirror.wzff.de/sabotage/sabotage-0.9.2-x86_64_5e7eda8.img.xz

sha512 checksum 
442aa4d8fca1516e8ede95265eb62ef8cb9a78f674ae466c312b244c94179eb481d484911d52a8856d70f8026bac9048395c3a89237d9ce6cded4be93abab48e

unpack using xzcat (extracts to a 10GB imagefile)

launch using qemu-system-x86_64 imagefile

or alternatively convert to virtualbox format using

|VBoxManage convertfromraw $IMG $VDI
|

if you use virtual box, you may have to change /bin/X to use different 
device ids (currently commented out)

you can also loopmount the image and copy the rootfs from there

there's also a rootfs for armv7l/softfp available. kernel is not 
included, because the kernel has to be carefully adapted to each 
specific ARM device its intended to run on.

Re: sabotage linux X86_64 image with LXDE desktop released

[Rich Felker]

On Sun, Jul 22, 2012 at 01:10:59AM +0200, John Spencer wrote:
> >>here is a screenshot: http://i.imgur.com/Lz7Ov.png
> >Something seems very wrong with those task manager vm sizes...
> >Is this indicative of a bug on musl's side?
> 
> here's what it's doing (note that PAGE_SIZE was originally an
> external variable which got once filled with sc_sysconf values,
> i needed to patch it away because of the conflict with the macro of
> the same name)

That shouldn't break anything..

> void get_task_details(gint pid,struct task *task)
> {
>         task->size=0;
> 
>         sprintf(line,"/proc/%d/statm",pid);
>         fd=open(line,O_RDONLY);
>         if(fd==-1) return;
>         read(fd,line,256);
>         sscanf(line,"%d %d",&task->size,&task->rss);
>         close(fd);
>         if(!task->size) return;
>         task->size*=PAGE_SIZE;
>         task->rss*=PAGE_SIZE;
> 
> struct task
> {
> // ...
>     gint size;
>     gint rss;
> };

gint is not large enough to store memory sizes on 64-bit machines
(though I doubt you're overflowing it here...) and %d may not be the
right scanf conversion for gint unless gint is defined as int...

Otherwise, I don't see what's wrong...

Rich

Re: sabotage linux X86_64 image with LXDE desktop released

[John Spencer]

On 07/21/2012 10:50 PM, Rich Felker wrote:
> On Sat, Jul 21, 2012 at 10:59:11PM +0200, John Spencer wrote:
>> the desktop works, but is not polished at all - there's no
>> background image and the icon paths seem to be misconfigured.
>> this can be considered a technoloy preview.
>> here is a screenshot: http://i.imgur.com/Lz7Ov.png
> Something seems very wrong with those task manager vm sizes...
> Is this indicative of a bug on musl's side?
>
> Rich
>

here's what it's doing (note that PAGE_SIZE was originally an external 
variable which got once filled with sc_sysconf values,
i needed to patch it away because of the conflict with the macro of the 
same name)

lxtask-0.1.4/src/xfce-taskmanager-linux.c:
reading the values ...

void get_task_details(gint pid,struct task *task)
{
         task->size=0;

         sprintf(line,"/proc/%d/statm",pid);
         fd=open(line,O_RDONLY);
         if(fd==-1) return;
         read(fd,line,256);
         sscanf(line,"%d %d",&task->size,&task->rss);
         close(fd);
         if(!task->size) return;
         task->size*=PAGE_SIZE;
         task->rss*=PAGE_SIZE;

struct task
{
// ...
     gint size;
     gint rss;
};

displayed using
gtk_tree_store_set(GTK_TREE_STORE(list_store), iter, COLUMN_RSS, 
size_to_string(buf, task->rss*1024), -1);

where
char* size_to_string( char* buf, guint64 size )
{
     char * unit;
     /* guint point; */
     gfloat val;

     /*
        FIXME: Is floating point calculation slower than integer division?
               Some profiling is needed here.
     */
     if ( size > ( ( guint64 ) 1 ) << 30 )
     {
         if ( size > ( ( guint64 ) 1 ) << 40 )
         {
             /*
             size /= ( ( ( guint64 ) 1 << 40 ) / 10 );
             point = ( guint ) ( size % 10 );
             size /= 10;
             */
             val = ((gfloat)size) / ( ( guint64 ) 1 << 40 );
             unit = "TB";
         }
         else
         {
             /*
             size /= ( ( 1 << 30 ) / 10 );
             point = ( guint ) ( size % 10 );
             size /= 10;
             */
             val = ((gfloat)size) / ( ( guint64 ) 1 << 30 );
             unit = "GB";
         }
     }
     else if ( size > ( 1 << 20 ) )
     {
         /*
         size /= ( ( 1 << 20 ) / 10 );
         point = ( guint ) ( size % 10 );
         size /= 10;
         */
         val = ((gfloat)size) / ( ( guint64 ) 1 << 20 );
         unit = "MB";
     }
     else if ( size > ( 1 << 10 ) )
     {
         /*
         size /= ( ( 1 << 10 ) / 10 );
         point = size % 10;
         size /= 10;
         */
         val = ((gfloat)size) / ( ( guint64 ) 1 << 10 );
         unit = "KB";

     }
     else
     {
         unit = size > 1 ? "Bytes" : "Byte";
         sprintf( buf, "%u %s", ( guint ) size, unit );
         return buf;
     }
     /* sprintf( buf, "%llu.%u %s", size, point, unit ); */
     sprintf( buf, "%.1f %s", val, unit );

     return buf;
}

Re: sabotage linux X86_64 image with LXDE desktop released

[John Spencer]

On 07/22/2012 01:05 AM, Rich Felker wrote:
> On Sun, Jul 22, 2012 at 01:10:59AM +0200, John Spencer wrote:
>>>> here is a screenshot: http://i.imgur.com/Lz7Ov.png
>>> Something seems very wrong with those task manager vm sizes...
>>> Is this indicative of a bug on musl's side?
>> here's what it's doing (note that PAGE_SIZE was originally an
>> external variable which got once filled with sc_sysconf values,
>> i needed to patch it away because of the conflict with the macro of
>> the same name)
> That shouldn't break anything..
>
it was doing
PAGE_SIZE=sysconf(_SC_PAGESIZE)>>10;
in the original code and i didnt see the counter-intuitive bitshift.

its properly fixed in git now.

Re: sabotage linux X86_64 image with LXDE desktop released

[Daniel Cegiełka]

2012/7/21 John Spencer <maillist-musl@barfooze.de>:
> I uploaded an image file of my latest sabotage build from
>
> https://github.com/rofl0r/sabotage



> Image files are available athttp://mirror.wzff.de/sabotage/
>
> http://mirror.wzff.de/sabotage/sabotage-0.9.2-x86_64_5e7eda8.img.xz
>
> sha512 checksum
> 442aa4d8fca1516e8ede95265eb62ef8cb9a78f674ae466c312b244c94179eb481d484911d52a8856d70f8026bac9048395c3a89237d9ce6cded4be93abab48e
>
> unpack using xzcat (extracts to a 10GB imagefile)
>
> launch using qemu-system-x86_64 imagefile
>
> or alternatively convert to virtualbox format using
>
> |VBoxManage convertfromraw $IMG $VDI
> |

and if you want chroot etc.

# file -s sabotage-0.9.2-x86_64_5e7eda8.img
sabotage-0.9.2-x86_64_5e7eda8.img: x86 boot sector; partition 1:
ID=0x83, active, starthead 32, startsector 2048, 204800 sectors;
partition 2: ID=0x83, starthead 223, startsector 206848, 20764672
sectors, code offset 0x31

# mkdir /mnt/sdb1
# mkdir /mnt/sdb2

# mount sabotage-0.9.2-x86_64_5e7eda8.img /mnt/sdb1 -o offset=$((2048*512))
# mount sabotage-0.9.2-x86_64_5e7eda8.img /mnt/sdb2 -o offset=$((206848*512))

Have fun! :)
Daniel

Re: sabotage linux X86_64 image with LXDE desktop released

[Roy]

John Spencer <maillist-musl <at> barfooze.de> writes:

> 
> I uploaded an image file of my latest sabotage build from
> 
> https://github.com/rofl0r/sabotage
> 
> Image files are available at http://mirror.wzff.de/sabotage/
> 
> 

is thare a new build for 0.9.3?

Re: Re: sabotage linux X86_64 image with LXDE desktop released

[John Spencer]

On 08/08/2012 01:06 AM, Roy wrote:
> John Spencer<maillist-musl<at>  barfooze.de>  writes:
>
>> I uploaded an image file of my latest sabotage build from
>>
>> https://github.com/rofl0r/sabotage
>>
>> Image files are available at http://mirror.wzff.de/sabotage/
>>
>>
> is thare a new build for 0.9.3?
>
>
not yet. the latest build is mostly equivalent though, it has about 5 
patches applied that fix the major issues in 0.9.2.
there are no other known bugs fixed which would affect the statically 
linked binaries, so its sufficient to rebuild musl to get the new libc.so:

[get new pkg/musl from git and put it into /src/pkg ]
butch rebuild musl
butch rebuild relocate_toolchain (required to get the toolchain in tune 
again)

and you're up to date.

next thing on my TODO list is getting an i386 image out, so i'll 
postpone and update amd64 img file till the next release of musl or 
something significant in the X11 setup gets fixed.

(yup, X11 config is still the major TODO for sabotage. i somehow can't 
overcome my aversion against this topic and start to read up about it.)