http://blueturtles.co.uk/Leek_Wooten_2006/work.php?wear1.png
[Non-text portions of this message have been removed]
I'm trying to help a friend with a P3 mobile 800 MHz with maximum RAM of 384 MB, it's a Compaq Presario 18XL4. When they gave it to me it only had 128 MB, I finally found an 8 chip 256 MB PC100 So-Dimm out of a Dell P4 laptop that would work in it.
So I found a few Linux Live CDs that would work, but some gave a vertical line down the screen including Lubuntu and Puppy based off Ubuntu files, my guess is the ATI card, but the latest LinuxMint LXDE 13 RC didn't have that problem. At least, Mint with it's hard disk tool let me know the hard drive may eventually fail, now it has WinXP Pro Sp3 and the M$ Security Essentials, which take up about half the 10 GB hard disk, so I put on Firefox, and the smallest word processor and spreadsheet from the Linux world to get them ready for Linux.
However, it would be nice if I could install Linux on an external hard drive without Grub putting on a boot manager on the internal hard drive...I use PLop from Hiren's Boot CD on mine, but is there another way? Most Linux Live CDs take so long to load on a computer this old, but if you're short on cash you learn to make do.
Thanks,
Joan in Reno
[Non-text portions of this message have been removed]
Hello,
The version of mpd segfaults when it comes across ogg/flac files. So I wanted to upgrade to a newer version. I checked out optware from subversion and made the following changes...
This works for me, but may not be perfect. Who would I work with to get proper fixes upstream?
[bpeck@localhost optware]$ svn diff
Index: make/ffmpeg.mk
===================================================================
--- make/ffmpeg.mk (revision 12824)
+++ make/ffmpeg.mk (working copy)
@@ -21,9 +21,11 @@
#
# Check http://svn.mplayerhq.hu/ffmpeg/trunk/
# Take care when upgrading for multiple targets
+FFMPEG_GIT=git://source.ffmpeg.org/ffmpeg.git
+FFMPEG_GIT_TAG=n0.8.11
FFMPEG_SVN=svn://svn.mplayerhq.hu/ffmpeg/trunk
FFMPEG_SVN_DATE=20080409
-FFMPEG_VERSION=0.svn$(FFMPEG_SVN_DATE)
+FFMPEG_VERSION=1.git$(FFMPEG_GIT_TAG)
FFMPEG_DIR=ffmpeg-$(FFMPEG_VERSION)
FFMPEG_SOURCE=$(FFMPEG_DIR).tar.bz2
FFMPEG_UNZIP=bzcat
@@ -90,12 +92,14 @@
$(DL_DIR)/$(FFMPEG_SOURCE):
( cd $(BUILD_DIR) ; \
rm -rf $(FFMPEG_DIR) && \
- svn co -r '{$(FFMPEG_SVN_DATE)}' $(FFMPEG_SVN) $(FFMPEG_DIR) && \
- tar -cjf $@ $(FFMPEG_DIR) --exclude .svn && \
+ git clone $(FFMPEG_GIT) $(FFMPEG_DIR) && \
+ pushd $(FFMPEG_DIR) && \
+ git checkout $(FFMPEG_GIT_TAG) && \
+ popd && \
+ tar -cjf $@ $(FFMPEG_DIR) --exclude .git && \
rm -rf $(FFMPEG_DIR) \
)
-
#
# The source code depends on it existing within the download directory.
# This target will be called by the top level Makefile to download the
@@ -144,6 +148,7 @@
--enable-cross-compile \
--cross-prefix=$(TARGET_CROSS) \
--arch=$(FFMPEG_ARCH) \
+ --target-os=linux \
$(FFMPEG_CONFIG_OPTS) \
--disable-encoder=snow \
--disable-decoder=snow \
@@ -188,15 +193,15 @@
rm -f $@
rm -rf $(STAGING_INCLUDE_DIR)/ffmpeg $(STAGING_INCLUDE_DIR)/postproc
$(MAKE) -C $(@D) install \
- mandir=$(STAGING_DIR)/opt/man \
- bindir=$(STAGING_DIR)/opt/bin \
- prefix=$(STAGING_DIR)/opt \
+ mandir=/opt/man \
+ bindir=/opt/bin \
+ prefix=/opt \
DESTDIR=$(STAGING_DIR)
install -d $(STAGING_INCLUDE_DIR)/ffmpeg $(STAGING_INCLUDE_DIR)/postproc
- cp -p $(STAGING_INCLUDE_DIR)/libavcodec/* \
- $(STAGING_INCLUDE_DIR)/libavformat/* \
- $(STAGING_INCLUDE_DIR)/libavutil/* \
- $(STAGING_INCLUDE_DIR)/ffmpeg/
+# cp -p $(STAGING_INCLUDE_DIR)/libavcodec/* \
+# $(STAGING_INCLUDE_DIR)/libavformat/* \
+# $(STAGING_INCLUDE_DIR)/libavutil/* \
+# $(STAGING_INCLUDE_DIR)/ffmpeg/
cp -p $(STAGING_INCLUDE_DIR)/libpostproc/* \
$(STAGING_INCLUDE_DIR)/postproc/
sed -i -e 's|^prefix=.*|prefix=$(STAGING_PREFIX)|' \
@@ -241,14 +246,14 @@
#
$(FFMPEG_IPK): $(FFMPEG_BUILD_DIR)/.built
rm -rf $(FFMPEG_IPK_DIR) $(BUILD_DIR)/ffmpeg_*_$(TARGET_ARCH).ipk
- $(MAKE) -C $(FFMPEG_BUILD_DIR) mandir=$(FFMPEG_IPK_DIR)/opt/man \
- bindir=$(FFMPEG_IPK_DIR)/opt/bin libdir=$(FFMPEG_IPK_DIR)/opt/lib \
- prefix=$(FFMPEG_IPK_DIR)/opt DESTDIR=$(FFMPEG_IPK_DIR) \
+ $(MAKE) -C $(FFMPEG_BUILD_DIR) mandir=/opt/man \
+ bindir=/opt/bin libdir=/opt/lib \
+ prefix=/opt DESTDIR=$(FFMPEG_IPK_DIR) \
LDCONFIG='$$(warning ldconfig disabled when building package)' install
$(TARGET_STRIP) $(FFMPEG_IPK_DIR)/opt/bin/ffmpeg
$(TARGET_STRIP) $(FFMPEG_IPK_DIR)/opt/bin/ffserver
$(TARGET_STRIP) $(FFMPEG_IPK_DIR)/opt/lib/*.so
- $(TARGET_STRIP) $(FFMPEG_IPK_DIR)/opt/lib/vhook/*.so
+# $(TARGET_STRIP) $(FFMPEG_IPK_DIR)/opt/lib/vhook/*.so
$(MAKE) $(FFMPEG_IPK_DIR)/CONTROL/control
cd $(BUILD_DIR); $(IPKG_BUILD) $(FFMPEG_IPK_DIR)
Index: make/mpd.mk
===================================================================
--- make/mpd.mk (revision 12824)
+++ make/mpd.mk (working copy)
@@ -24,7 +24,7 @@
MPD_SITE=http://$(SOURCEFORGE_MIRROR)/sourceforge/musicpd
#MPD_SVN_REPO=https://svn.musicpd.org/mpd/trunk
#MPD_SVN_REV=5324
-MPD_VERSION=0.15.15
+MPD_VERSION=0.16.8
MPD_SOURCE=mpd-$(MPD_VERSION).tar.bz2
MPD_DIR=mpd-$(MPD_VERSION)
MPD_UNZIP=bzcat
Hi
Thank you for this information, I have had some success, I have installed
centos 5 onto A 2GB CF card, the problem is it does not have a GUI, so I'm
now stuck with trying to find out how to install software, anyhow first
problem now overcome.
I used a bit of software called physdiskwrite to get the image onto the CF
CARD.
Alan
-------Original Message-------
From: catbit_1999
Date: 26/05/2012 02:32:04
To: LINUX_Newbies@yahoogroups.com
Subject: [LINUX_Newbies] Re: alix 3d3 thin client
--- In LINUX_Newbies@yahoogroups.com, "Alan" <alanm0aqc@...> wrote:
>
> hi guys
>
> can anyone please help me.
>
> i have an astrix 3d3 thin client pc, its a small alix board.
>
> i have been trying to get a working copy of linux ubuntu or centos
installed onto a flash card to run on this board, i have tried now for 4
weeks and ive got no where.
I know nothing about Alix boards, but a friend who was browsing this group
suggested I post this link for you.
http://pcengines.ch/alix.htm
It seems to have some preconfigured images as well as some install
instructions.
[Non-text portions of this message have been removed]
--- In LINUX_Newbies@yahoogroups.com, "Alan" <alanm0aqc@...> wrote:
>
> hi guys
>
> can anyone please help me.
>
> i have an astrix 3d3 thin client pc, its a small alix board.
>
> i have been trying to get a working copy of linux ubuntu or centos installed onto a flash card to run on this board, i have tried now for 4 weeks and ive got no where.
I know nothing about Alix boards, but a friend who was browsing this group suggested I post this link for you.
http://pcengines.ch/alix.htm
It seems to have some preconfigured images as well as some install instructions.
hi guys
can anyone please help me.
i have an astrix 3d3 thin client pc, its a small alix board.
i have been trying to get a working copy of linux ubuntu or centos installed onto a flash card to run on this board, i have tried now for 4 weeks and ive got no where.
i've gone into ubuntu on my laptop, downloaded various versions of linux, i have used the dd in terminal window but have not been successful in getting my alix board functional.
i'm new to linux and don't have much hair left.
can anyone help please, i need an idiots walk through guide on how to do it.
thanks alan
If not too concerned about the postmaster sending address - you can just
filter them to trash. I did.
gerald philly pa usa
On 5/18/2012 10:05 PM, Paul wrote:
>
> --- In LINUX_Newbies@yahoogroups.com, "G.Linuxducks"<g.linuxducks@...> wrote:
>> Apparently, is a list/group member and group emails are bouncing as full
>> inbox on their side or a discontinued account even as maybe discontinued
>> ISP subscription etc.
>>
>> my guess....
>>
>> gerald philly pa usa
>>
> Probably All I know is I got another one. I'll probably get one after I post this too.
--- In nslu2-linux@yahoogroups.com, David Given <dg@...> wrote:
>
> On 18/05/12 23:09, clerew5 wrote:
> [...]
> > Ah! I had thought that all signals would be passed to all threads (which is indeed the case for signals arising from outside).
>
> This is definitely getting out of my comfort zone (signals and threads
> mix like oil and cats), but I was under the impression that outside
> signals to sent to a single thread *at random* that had the signal
> unblocked? So you control which thread you want to receive the signals
> by blocking them from everywhere else.
Yes, that is what I thought, and the thread in question was the only one allowed to see the signals (the prime purpose off that thread is to catch people who suddenly press buttons). But it seems that SIGSEGV (unless generated externally) is only sent to the thread it happened in, or maybe its parents.
> > But the stack it prints bears no resemblance to what I get from 'bt' in gdb. It seems to start from errHandler, but after that it bears no resemblance to anything recognizable; and it is not just because it arises within a handler, because I have manually invoked it from elsewhere in the program, and it still does not work.
>
> I've tried the test program in the backtrace man page on my armhf box,
> and it doesn't work. I'm afraid that it's possible that backtrace simply
> doesn't work on ARM.
Actually, it is doing better than I thought. Here is some actual output:
./heat(pthread_create+0x710)[0x9da0]
/lib/libc.so.6(__default_rt_sa_restorer_v2+0x0)[0x4010bcf0]
/lib/libc.so.6(_IO_printf+0x34)[0x40120dfc]
./heat[0x14a18]
./heat[0x17274]
./heat(pthread_create+0x680)[0x9d10]
The addresses within [...] are indeed the addresses of code being obeyed all down the stack. But [0x9da0] is NOT within pthread_create (nm shows it is actually within my handler). Likewise [0x9d10] is within 'main', and [0x14a18] and [0x17274] are at identifiable places which gave me the clue as to where the fault was happening (though there appears to be one stack frame which does not appear at all).
BUT I then assumed that the claimed routines shown within /lib/libc.so.6 would be equally bogus, whereas research using /proc/<pid>/maps and nm showed that they were in fact correct, and the fault was indeed in printf (I had mistyped '%d' as '%n').
So there is definitely a bug in backtrace which is causing wrong identification within code compiled by myself, but which which operates fine within the system libraries.
>
> > My plan is to embed the whole program (which has to run 24/7) within a shell script which observes the failures, records what it can in a suitable file, and then restarts the program. But it is important that things should be cleaned up before the program is removed...
>
> You may be treading on thin ice here. Depending on what causes the seg
> fault, it's quite possible that the system will be in a bad state ---
> for example, if you call fwrite(), and the buffer is unreadable, then
> it's entirely likely that the signal will be thrown while it's in the
> middle of modifying the stdio state. Which means that trying to use
> stdio again will hang, crash, etc. The magic keyword to search for is
> 'async signal safe'.
Yes, you have to be aware of what code you are going to obey, and what exit() is likely to do, and there is a risk that these might trigger the same fault again. But in my case the system is controlling a heating system and turning real boilers on and off, and it is absolutely essential that, upon a crash, the boiilers are most definitely left OFF. Also, there are a few variables that ought to be preserved in permanent storage.
But so far it all seems to be working fine. The system crashed, restarted itself within one second, and crashed again shortly after - until eventually the temperatures had risen to a point where the offending piece of code did not need to be called anymore.
--- In LINUX_Newbies@yahoogroups.com, "G.Linuxducks" <g.linuxducks@...> wrote:
>
> Apparently, is a list/group member and group emails are bouncing as full
> inbox on their side or a discontinued account even as maybe discontinued
> ISP subscription etc.
>
> my guess....
>
> gerald philly pa usa
>
Probably All I know is I got another one. I'll probably get one after I post this too.
--- In nslu2-linux@yahoogroups.com, David Given <dg@...> wrote:
> I'm not quite sure what you're trying to do here --- AIUI sigwait()
> blocks until a signal *for the blocked thread* is received, so no code
> that can generate the signal will be run... (unless you send it manually
> from another thread).
Ah! I had thought that all signals would be passed to all threads (which is indeed the case for signals arising from outside).
>
> If you're trying to catch a signal thrown by code in a different thread,
> then I don't think that will work.
>
> The simplest approach is to just register a SIGSEGV signal handler in
> the thread that's going to be doing the work. Then, when the signal is
> thrown, your handler will run. If you want to do the work in a different
> thread, then you'll need some sort of IPC between threads (but beware
> that you can only run a small subset of functions safely from inside a
> signal handler).
Yes, I have now set up a sigaction-type handler in main(), and it seems to be inherited by processes created subsequently to that. It sort of works, but I need to know where the SIGSEGV came from, in order to know where to look for the bug. Here is my current handler:
void errHandler(int signum, siginfo_t *info, void *ptr) {
int count = backtrace( tracePtrs, 100 );
backtrace_symbols_fd(tracePtrs, count, 2);
fatal("Heat failed with %s: si_code=%d",
strsignal(signum), info->si_code);
}
errAction.sa_sigaction = errHandler;
errAction.sa_flags = SA_SIGINFO;
sigaction(SIGSEGV, &errAction, NULL);
sigaction(SIGBUS, &errAction, NULL);
sigaction(SIGILL, &errAction, NULL);
sigaction(SIGFPE, &errAction, NULL);
sigaction(SIGSYS, &errAction, NULL);
The call to 'fatal' seems to work fine (given that it has to deal with all those signals, that is as much information as I can extract from info).
But, for tracing the bug, I need to know where the signal came from. Slugos 5.3 doesn't do core dumps (for good reason), so I have tried to generate a backtrace (#include <execinfo.h> - note that tracePtrs is declared globally). But the stack it prints bears no resemblance to what I get from 'bt' in gdb. It seems to start from errHandler, but after that it bears no resemblance to anything recognizable; and it is not just because it arises within a handler, because I have manually invoked it from elsewhere in the program, and it still does not work.
So does anybody have any experience of using 'backtrace' in Slugos?
My plan is to embed the whole program (which has to run 24/7) within a shell script which observes the failures, records what it can in a suitable file, and then restarts the program. But it is important that things should be cleaned up before the program is removed, which is why the call of 'fatal' is used - it then calls exit, which in turn calls all my 'atexit' functions, and calls the cleanup functions on those classes which have them.
And indeed it caught several SIGSEGVs this morning (but they appear to occur randomly when noone is looking, and obviously I need to find the cause).
Apparently, is a list/group member and group emails are bouncing as full
inbox on their side or a discontinued account even as maybe discontinued
ISP subscription etc.
my guess....
gerald philly pa usa
On 05/16/2012 11:48 PM, Paul wrote:
> All email addys were changed to protect the guilty. I honestly don't think cox has anything to do with this nonsense. So I'm not going to reply to them about it. Maybe someone here knows what this means?
>
> Your message was rejected by mx00.1and1.com for the following reason:
>
> Loop detected
>
> The following recipients did not receive this message:
>
> <jon attheswav.com>
>
> Please reply to<Pxstmixer@cox.net>
> if you feel this message to be in error.
>
>
>
> Forwarded Message: [SPAM (Non-existent user)] - [LINUX_Newbies] Re: Ubuntu 12.04LTS Problem - Local recipient does not exist
> [SPAM (Non-existent user)] - [LINUX_Newbies] Re: Ubuntu 12.04LTS Problem - Local recipient does not exist
> Wednesday, May 16, 2012 7:46 PM
> From:
> "Paul"<xxxxxxxx@yahoo.com>
> To:
> LeiNUX_Newbies@yahoogroups.com
>
>
I have optware on my router with 32mb and I got perl but the module I wanted wasn't available via ipkg so I went to use CPAN to find it wouldn't work...
Even if I did configure it correctly (i'm 99% sure i did since i had expert help) it would have taken days to do anything as using swap made it slooooooow) I started off with this site http://www.nslu2-linux.org/wiki/HowTo/ConfigureCPAN and that didn't cut it.
I moved over to using cpanm - https://github.com/miyagawa/cpanminus
but that gave an error so i did this
https://github.com/shadowcat-mst/cpanminus/commit/9eba7dd0af9e63a4cadde8b0f5483a43a5e63deb **** credit goes to wtf911(myself) and mst*****
With that cpanm works good and you just need the proper ipkgs prior to using it...
i can't say what if all of these you need:
binutils
expat
glib
grep
gzip
less
libc6-unslung
libdb
libgcc
libxml2
lynx
man
ncftp
ncursesw
openssh
openssl-dev
readline
sqlite
tz
unslung-devel
unslung-feeds
update-modules
which
zlib
but on top of those you want:
tar
wget
make
inetutils
xz-utils
at that point you want to have this file: https://raw.github.com/miyagawa/cpanminus/master/cpanm
downloaded somewhere accesible
to use it: perl cpanm [option] [module]
and there you have simpler, faster, and working cpan and installing modules for perl on optware!
again credit to wtf911 and mst :D
i advise changing this page:http://www.nslu2-linux.org/wiki/HowTo/ConfigureCPAN
I am trying to trap a SIGSEGV (also SIGBUS, SIGILL and SIGFPE, but I have not even managed to generate those yet :-( ).
I can easily get the program to produce a message "Segmentation Violation" on stderr, but noway can I catch it before getting that message.
I have written
sigemptyset(&set);
sigaddset(&set, SIGUSR1);
sigaddset(&set, SIGUSR2);
sigaddset(&set, SIGTERM);
sigaddset(&set, SIGINT);
sigaddset(&set, SIGSEGV);
sigaddset(&set, SIGBUS);
sigaddset(&set, SIGILL);
sigaddset(&set, SIGFPE);
sigaddset(&set, SIGSYS);
and I have created a pthread which contains
sigwait(&set, &signal);
printf("Display signal %d\n", signal);
switch (signal) {
case SIGSEGV:
case SIGBUS:
case SIGILL:
case SIGFPE:
case SIGSYS:
fatal("Heat failed: %s", strerror(errno));
case SIGTERM:
case SIGINT:
warn("Heat terminated");
exit(0);
default:
fatal("Unanticipated signal %d", signal);
}
but the SIGSEGV is never caught (though SIGTERM is caught fine, as is an explicit "kill -s SEGV").
How can I fix this? 'warn' and 'fatal' do what you would expect, and 'fatal' calls 'exit(-1).
Note also that arms tend not to raise SIGFPE even if you do the most terrible divisions by zero. Apparently there is now a linux patch to fix this.
