Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <51641ECB.70802@barfooze.de>
Date: Tue, 09 Apr 2013 15:59:39 +0200
From: John Spencer <maillist-sabotage@...fooze.de>
To: sabotage@...ts.openwall.com
Subject: Re: Sabotage gone native...

sorry for the late reply... we've talked about the issues you 
encountered on irc, i'm sending this for documentation purposes.

On 02/27/2013 06:09 PM, Hugh Lavery wrote:
> Thank you for your work on the sabotage image files.  Wanted to let
> you know that I have the latest version up on both an x86_64 box and
> on an armv7 (Allwinner A10 Hackberry) device.  Sabotage works well,
> even in X once the mouse and keyboard events are sorted out (bit of an
> adventure, there).

glad to hear!

btw i've looked at what you suggested ( /proc/bus/input/devices )
but those ids seem to differ from what works.
if anyone knows a way to process this file correctly to get the proper 
mouse and kbd evdev ids please let me know.

>  There are some bugs to sort out on the arm device
> (tmux dies on "assertion ctx failed in evmap_io_active", as does
> transmission in gui; no such issues on x86_64).

yes, this is all fixed in git.
https://github.com/rofl0r/sabotage/issues/69

>
> What do you use to build the rofl0r/sabotage scripts?  I have tried to
> build these on the latest x86_64 releases (+/- a week or two of today)
> of Arch, Ubuntu (Q.Q) and Crux3.0 but only get (at best) as far as the
> kernel-headers in Stage 0 before  the build dies.  Since I have your
> image/rootfs to work with this is just a matter of interest....
>

there seem to be some kernel bugs related to vfork on 32bit platforms 
that affect butch.
once the error happens, there's no way to get butch working again in the 
current session.
the only known solution is to reboot the host, and then resume the 
stage0 build using utils/resume-stage0.sh.
there's another bug in debian testing (they've made some headers only 
available in an arch-specific subdir) that prevents the stage0 gcc from 
building correctly. i have to look into that.
however, debian stable works.
known-good platforms to build sabotage on are debian stable, suse, and 
aboriginal (with some minor tweaks, see
https://github.com/rofl0r/sabotage/wiki/bootstrapping-from-aboriginal-linux
  ). basically any distribution should work, unless they have some ugly 
distro-specific toolchain hacks in place (like debian testing).

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.