Hello,

I use wput in a cron job to copy daily backups on another server. The wput
package for syno machines is not built with SSL, which is a feature I miss as I
promised myself not to use unsecure FTP connection. So if you guys find it easy,
it would be a great thing to have!

Best,
Charles

What are the chances someone could add visor kernel module to the wl-500g ipkg
tree?

I don't know if you have seen it but it's popping up some quite
interesting things using Optware all over the place. First off B-Rad
ported Optware to Western Digital TV HD
http://b-rad.cc/optware-for-wdtv/ and is working on a version for the
Western Digital TV HD Live. And then someone found out that the Asus
O!Play was binary compatible with the Asus Wl500G router
http://www.avforums.com/forums/streamers-network-media-players/1007863-asus-o-pl\
ay-119-a-14.html

/M

Thanks a lot, it worked!!!!

--- In nslu2-linux@yahoogroups.com, "Brian" <b88zhou@...> wrote:
>
> cups depends on openldap-libs
> openldap-libs depends on cyrus-sasl-libs which should provide
/opt/lib/libsasl2.so.2
>
> You might want to try "ipkg update; ipkg -force-reinstall install
openldap-libs cyrus-sasl-libs".
>
> -Brian
>
> --- In nslu2-linux@yahoogroups.com, "vi_sharan" <vi_sharan@> wrote:
> >
> > Hi All! Whenever I try starting the CUPS on my nslu2 I get this error.....If
you can help me to resolve this .... I will immensely thank you.
> >
> > Device:NSLU2
> > Welcome to Unslung V2.3R63-uNSLUng-6.10-beta
> > BusyBox v1.3.1 (2007-12-29 03:38:35 UTC) Built-in shell (ash)
> >
> >
> >
> > # /opt/etc/init.d/S88cups start
> > /opt/sbin/cupsd: error while loading shared libraries: libsasl2.so.2: cannot
open shared object file: No such file or directory
> >
>

cups depends on openldap-libs
openldap-libs depends on cyrus-sasl-libs which should provide
/opt/lib/libsasl2.so.2

You might want to try "ipkg update; ipkg -force-reinstall install openldap-libs
cyrus-sasl-libs".

-Brian

--- In nslu2-linux@yahoogroups.com, "vi_sharan" <vi_sharan@...> wrote:
>
> Hi All! Whenever I try starting the CUPS on my nslu2 I get this error.....If
you can help me to resolve this .... I will immensely thank you.
>
> Device:NSLU2
> Welcome to Unslung V2.3R63-uNSLUng-6.10-beta
> BusyBox v1.3.1 (2007-12-29 03:38:35 UTC) Built-in shell (ash)
>
>
>
> # /opt/etc/init.d/S88cups start
> /opt/sbin/cupsd: error while loading shared libraries: libsasl2.so.2: cannot
open shared object file: No such file or directory
>

Hi All! Whenever I try starting the CUPS on my nslu2 I get this error.....If you
can help me to resolve this .... I will immensely thank you.

Device:NSLU2
Welcome to Unslung V2.3R63-uNSLUng-6.10-beta
BusyBox v1.3.1 (2007-12-29 03:38:35 UTC) Built-in shell (ash)



# /opt/etc/init.d/S88cups start
/opt/sbin/cupsd: error while loading shared libraries: libsasl2.so.2: cannot
open shared object file: No such file or directory

--- In nslu2-linux@yahoogroups.com, "perror@..." <perror@...> wrote:
>
>
>
> --- In nslu2-linux@yahoogroups.com, "perror@" <perror@> wrote:
> >
> >
> >
> > --- In nslu2-linux@yahoogroups.com, jasoncraneuk@ wrote:
> > >
> > > Hello
> > >
> > > I'm having a problem running Perl that I've installed via ipkg from the
optware/ts101/cross/ feed onto my Qnap TS-101.
> > >
> > > Firstly, I hope this is this the right forum for asking this, nslug1-linux
is listed as the package maintainer in the feed.
> > >
> > > The actual problem is that when I try to run perl I get this:
> > >  [~] # perl -v
> > >  R_PPC_REL24: Compile shared libraries with -fPIC!
> > >
> > >  perl: symbol 'malloc': can't handle reloc type 0xa
> > >
> > >
> >
> > I've just installed the latest package, perl_5.8.8-22_powerpc.ipk and get
the same error.
> > This is my first attempt at using OptWare and I would really like to get
Perl working! I've tried to find older packages but without any luck.
> >
>
> Just for the record, In perl_5.8.8-23_powerpc.ipk this have been fixed!
>

Thanks for the heads up. I've just upgraded from 22 to 23 and it works a treat.
:)

Thank you,

Jörg

--- In nslu2-linux@yahoogroups.com, "Brian" <b88zhou@...> wrote:
>
> Done.
>
> Cheers,
>
> -Brian
>
> --- In nslu2-linux@yahoogroups.com, "linuxnutzer1" <joerg_kuehne@> wrote:
> >
> > Hi,
> >
> > recently I missed a small, but very useful program on my NAS and
unfortunately I did not found it in the ipgk list, so I compiled it by myself.
But maybe other user may not go this way and need a ipkg.
> > It is a really simple program, compared with the programs from the wish list
with no other dependencies, a small binary, a man page and some doc-files.
> >
> > Homepage:
> > http://pcal.sourceforge.net/
> >
> > PCAL is a multi-platform (Unix/Linux, DOS, DOS+DJGPP, Windows+Cygwin, Amiga)
program which generates annotated PostScript or HTML calendars in a monthly or
yearly format.
> >
> > I use it for automatic printing my calendar events from google-calendar by a
weekly cron job. This is pretty good solution for a NAS/server.
> > Short summary:
> > 1) Get google calendar file in ical format with wget <Private-Link>
> > 2) Convert it to pcal-text-file with ical2pcal.sh
> > 3) generate a postscript calendar page for the current/next month
> > 4) print it with cups
> >
> > If anyone is interested, I can tell more details.
> >
> > Linuxnutzer
> >
>

--- In nslu2-linux@yahoogroups.com, "perror@..." <perror@...> wrote:
>
>
>
> --- In nslu2-linux@yahoogroups.com, jasoncraneuk@ wrote:
> >
> > Hello
> >
> > I'm having a problem running Perl that I've installed via ipkg from the
optware/ts101/cross/ feed onto my Qnap TS-101.
> >
> > Firstly, I hope this is this the right forum for asking this, nslug1-linux
is listed as the package maintainer in the feed.
> >
> > The actual problem is that when I try to run perl I get this:
> >  [~] # perl -v
> >  R_PPC_REL24: Compile shared libraries with -fPIC!
> >
> >  perl: symbol 'malloc': can't handle reloc type 0xa
> >
> >
>
> I've just installed the latest package, perl_5.8.8-22_powerpc.ipk and get the
same error.
> This is my first attempt at using OptWare and I would really like to get Perl
working! I've tried to find older packages but without any luck.
>

Just for the record, In perl_5.8.8-23_powerpc.ipk this have been fixed!

Done.

Cheers,

-Brian

--- In nslu2-linux@yahoogroups.com, "linuxnutzer1" <joerg_kuehne@...> wrote:
>
> Hi,
>
> recently I missed a small, but very useful program on my NAS and unfortunately
I did not found it in the ipgk list, so I compiled it by myself. But maybe other
user may not go this way and need a ipkg.
> It is a really simple program, compared with the programs from the wish list
with no other dependencies, a small binary, a man page and some doc-files.
>
> Homepage:
> http://pcal.sourceforge.net/
>
> PCAL is a multi-platform (Unix/Linux, DOS, DOS+DJGPP, Windows+Cygwin, Amiga)
program which generates annotated PostScript or HTML calendars in a monthly or
yearly format.
>
> I use it for automatic printing my calendar events from google-calendar by a
weekly cron job. This is pretty good solution for a NAS/server.
> Short summary:
> 1) Get google calendar file in ical format with wget <Private-Link>
> 2) Convert it to pcal-text-file with ical2pcal.sh
> 3) generate a postscript calendar page for the current/next month
> 4) print it with cups
>
> If anyone is interested, I can tell more details.
>
> Linuxnutzer
>

use mediatomb

--- In nslu2-linux@yahoogroups.com, "Ian" <ian@...> wrote:
>
> Not sure if it works with the PS3 but I had Wizd installed on my Slug for a
while and it streamed iso DVD images of across my wireless network to a
ShowCenter 200 just fine. I only abandoned this method because of the amount of
on-line storage capacity it required. I had 3 * 500GB connected and it wasn't
enough. So have now converted some 500+ DVD's to DivX, sure the quality isn't as
good but its good enough for watching on a 720p TV and means that my slug is
able to manage all my music, video and photos 24X7.
>
> The only time it struggles is if I have 3 or more clients trying to access
media at the same time.
>
> --- In nslu2-linux@yahoogroups.com, "slackline" <nshephard@> wrote:
> >
> >
> >
> > --- In nslu2-linux@yahoogroups.com, "kristoffer_pettersson"
<kristoffer_pettersson@> wrote:
> > >
> > > Hi!
> > >
> > > I have successfully installed uShare and it works like a charm for
pictures and mp3.
> > >
> > > Is there a way to convert/stream iso formats so that the ps3 can see them?
> >
> > You won't be able to do this on the fly as the NSLU2 just doesn't have the
oomph required, even if you've added more RAM.  Your best bet is to rip the ISO
on your computer into a format that the PS3 supports then up it to your NSLU2,
since usuallly (well at least the way I do it) I will actually mount an ISO that
I've got on my hard-drive (as though it were a physical DVD) and then watch it.
> >
>

Recently I had a hicup in the sytem and I had to unsling my disk1 again.
Unforunately after that I am unable to access my USB Disk 1 or Disk 2 from the
WebGUI or any of the windows Client.

"\\nslu2\disk 1" throws error in the windows client

and if I click on the USB Disk 1 on the web gui get error there too.

Also not able to create any share or anything....through the GUI
my mounts are correct, verified doing a df

Hi,

recently I missed a small, but very useful program on my NAS and unfortunately I
did not found it in the ipgk list, so I compiled it by myself. But maybe other
user may not go this way and need a ipkg.
It is a really simple program, compared with the programs from the wish list
with no other dependencies, a small binary, a man page and some doc-files.

Homepage:
http://pcal.sourceforge.net/

PCAL is a multi-platform (Unix/Linux, DOS, DOS+DJGPP, Windows+Cygwin, Amiga)
program which generates annotated PostScript or HTML calendars in a monthly or
yearly format.

I use it for automatic printing my calendar events from google-calendar by a
weekly cron job. This is pretty good solution for a NAS/server.
Short summary:
1) Get google calendar file in ical format with wget <Private-Link>
2) Convert it to pcal-text-file with ical2pcal.sh
3) generate a postscript calendar page for the current/next month
4) print it with cups

If anyone is interested, I can tell more details.

Linuxnutzer

Finally, I found out that the problem persists only with USB flash
disks!!!  When I connect an ext3 USB hard disk everything is working fine.

Strange, isn't it?

Thanks, anyway.



vasanag wrote:
> Gurus,
>
> I am experiencing very slow writing speed on my NFS share on my UNSLUNG.
>
> To write a file of 40 MB from my UBUNTU machine to the NSLU2 I need 3
> min 15 sec.
>
> To read back the same file to UBUNTU, I need only 15 secs!!!!!!
>
> What is going on here?  Am I missing something?
>
>
> ************
>
> On my NSLU2 running UNSLUNG 6.10
>
> # mount
> ......
> /dev/sdb1 on /share/hdd/data/USB_D1 type ext3 (rw,noatime)
>
>
> # cat /etc/exports
> /share/hdd/data/USB_D1 192.168.2.*(rw,sync,no_root_squash)
>
>
> ***********
>
> On UBUNTU
>
> To mount the share
>
> sudo mount 192.168.2.2:/share/hdd/data/USB_D1 /home/anagnost/mnt/nfs_nslu
>
>
> TIA
> vasanag
>
>
>
> ------------------------------------
>

The original message was received at 2009-12-02 19:49:46 -0700
from postoffice.home [10.0.0.1]

    ----- The following addresses had permanent fatal errors -----
<robuu@...>

    -----Transcript of session follows -----
... while talking to postoffice.home.:
>>> RCPT To:<robuu@...>
<<< 550 5.1.1 unknown or illegal alias: robuu@...
550 <robuu@...>... User unknown

tlhackque wrote:
> As I noted, renaming the config file directory did allow the install.
>
> But shouldn't '-force-downgrade' prevent {i,o}pkg from mis-using it's
"intelligence"?  Or -f /dev/null?  Seems to me that there needs to be a way to
get it to "Do Exactly What I Said".
>
Of course the bad behavior is a bug.
> Is there a bug reporting system for {i,o}pkg?
>
Google says http://code.google.com/p/opkg/issues/list

Keep in mind that the opkg version used in the last SlugOS release is
rather old, though -- with any luck this issue has been long ago fixed.
Since attempts to move up to more recent opkg versions pretty much
failed for one reason or another, SlugOS remains with that rather old
version -- the philosophy of "better the devil you know" prevails. :)

> --- In nslu2-linux@yahoogroups.com, "Mike Westerhof (mwester)" <mwester@...>
wrote:
>
>> Yeah, it does that when it thinks it has "better" information in the
>> package feed databases.
>>
>> If you go to the ipkg/opkg feed configuration file directory, and just
>> rename the feed config files to something that ipkg/opkg doesn't
>> recognize, that'll disable the feeds effectively.  You can then install
>> using "./<filename>.ipk" -- only problem is that without any feeds,
>> ipkg/opkg can't resolve dependencies, so you'll have to install those
>> manually in advance...
>>
>> Don't forget to rename the feed config files back again when you're done.
>>
>> -Mike (mwester)
>>
>> tlhackque wrote:
>>
>>> I tried ./ as well as the absolute path to the package.  ipkg still tries to
download the v2 pkg specified by the feed instead of using the file...
>>>
>>> I don't have this problem when I build a newer version of a package; I have
private versions of bind, dhcp, openssl that all use the file when I specify it.
>>>
>>> The strange behavior seems to be unique to the down-rev kit.
>>>
>>> --- In nslu2-linux@yahoogroups.com, "Brian" <b88zhou@> wrote:
>>>
>>>
>>>> You can try "ipkg install ./freeradius_1.1.7-2_armeb.ipk" This makes it
clear that you want to install from file.
>>>>
>>>> For building optware/nslu2 (unslung) toolchain, it's probably easier just
use latest make/crosstool.mk and sources/crosstool.
>>>>
>>>> Cheers,
>>>>
>>>> -Brian
>>>>
>>>> --- In nslu2-linux@yahoogroups.com, "tlhackque" <tlhackque@> wrote:
>>>>
>>>>
>>>>> Thanks for the clues.  I built the package - details below.
>>>>>
>>>>> But ipkg now refuses to install it!  If I say:
>>>>>   $ ipkg install freeradius_1.1.7-2_armeb.ipk
>>>>> ipkg starts downloading the 2.0.5-2 package from the unslung/cross feed!
>>>>>
>>>>> I've tried -force-downgrade, even -f /dev/null.  But (as demonstrated with
strace) ipkg goes and reads the /etc/ipkg feed files & then downloads the
2.0.5-2 package.
>>>>>
>>>>> I note that this package has a 'recommends' for freeradius-doc; putting
that kit in the same directory doesn't help.
>>>>>
>>>>> The only way to persuade it to use the file specified on the command line
is to
>>>>>   $ mv /etc/ipkg /etc/ipkg-x; ipkg install freeradius_1.1.7-2_armeb.ipk;
mv /etc/ipkg-x /etc/ipkg
>>>>>
>>>>> This seems excessively hard - if I explicitly specify a file, that's what
I want.
>>>>>
>>>>> Is there an option that I'm missing?  If not this seems like a (moderately
serious) bug.
>>>>>
>>>>> Other thoughts?
>>>>>
>>>>> Thanks.
>>>>>
>>>>> T
>>>>>
>>>>> Here's what it took to build this package - I'll make a wiki HOWTO when
I've dug out of the current crisis...meantime, perhaps this will help someone
else.
>>>>>
>>>>> $ svn co https://svn.nslu2-linux.org/svnroot/optware/trunk optware
>>>>> $ svn log make/freeradius.mk | less
>>>>> # r8749 is the rev that upgraded from 1.1.7
>>>>> $ svn up -r8748 <-- We want the rev BEFORE the upgrading commit!
>>>>> $ cd optware; make <platform>-target
>>>>> $ cd <platform>; make directories toolchain ipkg-utils
>>>>>
>>>>> Build fails because crosstool 0.38 isn't available.
>>>>> Visit http://kegel.com/crosstool/ and find 0.43 is.
>>>>>
>>>>> Edit optware/make/crosstool.mk to get the newer crosstools
>>>>>
>>>>> $ make toolchain ipkg-utils
>>>>> Ignore lots of glib doesn't build unoptimized errors...
>>>>>
>>>>> $ make freeradius
>>>>>
>>>>> Depends on openssl, site is down.  Modify optware/make/openssl.mk to use a
mirror:
>>>>>
>>>>> OPENSSL_SITE=http://www.mirrorservice.org/sites/ftp.openssl.org/source
>>>>>
>>>>> Depends on mysql - for some reason, the kit downloads into '.' rather than
'downloads/'.
>>>>>
>>>>> $ mv mysql downloads/
>>>>> $ make freeradius
>>>>>
>>>>> Curses! ncurses-5.6.tar.gz isn't on the distribution site.  ncurses.tar.gz
has 5.7.  Fetch it, put it in downloads/ and update make/ncurses (which mysql
wants).
>>>>>
>>>>> $ make mysql
>>>>>
>>>>> $ make freeradius
>>>>> $ make freeradius-ipk
>>>>>
>>>>> and freeradius_1.1.7-2_armeb.ipk is in builds/
>>>>>
>>>>> --- In nslu2-linux@yahoogroups.com, "Brian" <b88zhou@> wrote:
>>>>>
>>>>>
>>>>>> Optware package changes are all recorded in subversion.
>>>>>>
>>>>>> 1) Follow the instruction on
>>>>>>   http://www.nslu2-linux.org/wiki/Optware/AddAPackageToOptware
>>>>>> to get optware subversion checkout;
>>>>>>
>>>>>> 2) Then do "svn log make/freeradius.mk | less" look for the commit that
upgrades it from 1.1.7, in this case it's 8749;
>>>>>>
>>>>>> 3) You'd want to "turn back the clock"
>>>>>> The command probably is "svn up -r8749"
>>>>>>
>>>>>> 4) Build toolchain, and try to build the package
>>>>>>
>>>>>> I think I've noticed that in order to build unslung toolchain, you'd need
host gcc 3.x
>>>>>>
>>>>>> Good luck,
>>>>>>
>>>>>> -Brian
>>>>>>
>>>>>> --- In nslu2-linux@yahoogroups.com, "tlhackque" <tlhackque@> wrote:
>>>>>>
>>>>>>
>>>>>>> I'm rebuilding an unslung system from a disk failure, looking for
freeradius 1.1.7-2 - not quite ready to update to freeradius V2 - which is the
current feed.
>>>>>>>
>>>>>>> Is the old .ipk file available somewhere?  If not, is there a way to
build it from the source repository?
>>>>>>>
>>>>>>> It would be good to have a HOWTO that describes how to get the build
system to to build a specific version of any package - if someone can give me
the necessary clues, I'll be happy to add to the wiki.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>>>
>>> ------------------------------------
>>>
>>> Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>>
>>>

Hi Brian,

excellent work!!! Thank you very, very much. I upgraded the perl package and now
my test script and the rsnapshot-diff script are working perfectly.

Best wishes,

Jörg

--- In nslu2-linux@yahoogroups.com, "Brian" <b88zhou@...> wrote:
>
> Sorry, by "user space" I mean it's at level above syscall.
>
> I think I've found the problem, sources/perl/5.10/config.sh-cs08q1armel got
transformed into builds/perl/config.sh by
> Cross/generate_config_sh. And the transformation will use CFLAGS if it is set.
For some reason CFLAGS is set, so ccflags supplied in config.sh-cs08q1armel
never got to builds/perl/config.sh. This results that ccflags does not contain
'-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', these options never got applied
during build.
>
> A patch is on the way (for all optware platforms).
>
> -Brian
>
> --- In nslu2-linux@yahoogroups.com, "linuxnutzer1" <joerg_kuehne@> wrote:
> >
> >
> >
> >
> >
> >
> > Hi Brian,
> >
> > thank you for the very fast answer!
> > Unfortunately it seems that the issue remains, so can you explain what you
mean with "so the problem is in user space"?
> > Is it a perl bug or a glibc issue from the qnap firmware?
> > I found an old discussion by googling this issue. See
> > http://www.justskins.com/forums/about-stat-problem-49666.html
> > A "perl -V" did not show any -D_FILE_OFFSET_BITS=64 string on my QNAP, but
"uselargefiles=define". On all my other linux boxes this command shows
-D_FILE_OFFSET_BITS=64 as ccflags. But if stat64() is called from perl binary
than it seems that this option have applied.
> > Very mysterious.
> >
> > Thank you in advance
> >
> > Jörg
> >
> > --- In nslu2-linux@yahoogroups.com, "Brian" <b88zhou@> wrote:
> > >
> > > Doing a strace on a file > 2GB clearly shows that stat64 call has
succeeded, so the problem is in user space.
> > >
> > > stat64("big-file", {st_mode=S_IFREG|0777, st_size=2200331748, ...}) = 0
> > >
> > > -Brian
> > >
> > > --- In nslu2-linux@yahoogroups.com, "joerg_kuehne" <joerg_kuehne@> wrote:
> > > >
> > > > Hi,
> > > >
> > > > I hope, that anyone in this group can give me a hint about the
maintainer of the perl ipkg-package of the cs08q1armel branch.
> > > > I found an issue with the pert stat() function, that fails for files
larger than 2GByte on my QNAP TS119. This function is used from the
rsnapshot-diff script to get all informations about a certain file for comparing
different backup snapshots. It seems that perl is compiled without 64Bit support
for file sizes, with 32Bit one can only store size numbers up to 2GByte. Here a
little test script to verify this issue.
> > > >
> > > > test.pl
> > > > --- cut here ---
> > > > #! /opt/bin/perl
> > > >
> > > > @mystat = stat($ARGV[0]);
> > > > print "$ARGV[0]: file size: $mystat[7]\n";
> > > > --- cut here ---
> > > >
> > > > Run test.pl FILE
> > > >
> > > > If file is smaller than 2GByte it will display the right file size, if
it is larger then the file size will be empty caused by the failed stat().
> > > > Can anyone tell me why perl is compiled without the
> > > > -D_FILE_OFFSET_BITS=64 option? Is it a restriction of the ARM
architecture or glibc? Or has the usage of this option unwanted side effects or
was it simply forgotten?
> > > > Thank you in advance
> > > >
> > > > Jörg
> > > >
> > >
> >
>

Sorry, by "user space" I mean it's at level above syscall.

I think I've found the problem, sources/perl/5.10/config.sh-cs08q1armel got
transformed into builds/perl/config.sh by
Cross/generate_config_sh. And the transformation will use CFLAGS if it is set.
For some reason CFLAGS is set, so ccflags supplied in config.sh-cs08q1armel
never got to builds/perl/config.sh. This results that ccflags does not contain
'-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', these options never got applied
during build.

A patch is on the way (for all optware platforms).

-Brian

--- In nslu2-linux@yahoogroups.com, "linuxnutzer1" <joerg_kuehne@...> wrote:
>
>
>
>
>
>
> Hi Brian,
>
> thank you for the very fast answer!
> Unfortunately it seems that the issue remains, so can you explain what you
mean with "so the problem is in user space"?
> Is it a perl bug or a glibc issue from the qnap firmware?
> I found an old discussion by googling this issue. See
> http://www.justskins.com/forums/about-stat-problem-49666.html
> A "perl -V" did not show any -D_FILE_OFFSET_BITS=64 string on my QNAP, but
"uselargefiles=define". On all my other linux boxes this command shows
-D_FILE_OFFSET_BITS=64 as ccflags. But if stat64() is called from perl binary
than it seems that this option have applied.
> Very mysterious.
>
> Thank you in advance
>
> Jörg
>
> --- In nslu2-linux@yahoogroups.com, "Brian" <b88zhou@> wrote:
> >
> > Doing a strace on a file > 2GB clearly shows that stat64 call has succeeded,
so the problem is in user space.
> >
> > stat64("big-file", {st_mode=S_IFREG|0777, st_size=2200331748, ...}) = 0
> >
> > -Brian
> >
> > --- In nslu2-linux@yahoogroups.com, "joerg_kuehne" <joerg_kuehne@> wrote:
> > >
> > > Hi,
> > >
> > > I hope, that anyone in this group can give me a hint about the maintainer
of the perl ipkg-package of the cs08q1armel branch.
> > > I found an issue with the pert stat() function, that fails for files
larger than 2GByte on my QNAP TS119. This function is used from the
rsnapshot-diff script to get all informations about a certain file for comparing
different backup snapshots. It seems that perl is compiled without 64Bit support
for file sizes, with 32Bit one can only store size numbers up to 2GByte. Here a
little test script to verify this issue.
> > >
> > > test.pl
> > > --- cut here ---
> > > #! /opt/bin/perl
> > >
> > > @mystat = stat($ARGV[0]);
> > > print "$ARGV[0]: file size: $mystat[7]\n";
> > > --- cut here ---
> > >
> > > Run test.pl FILE
> > >
> > > If file is smaller than 2GByte it will display the right file size, if it
is larger then the file size will be empty caused by the failed stat().
> > > Can anyone tell me why perl is compiled without the
> > > -D_FILE_OFFSET_BITS=64 option? Is it a restriction of the ARM architecture
or glibc? Or has the usage of this option unwanted side effects or was it simply
forgotten?
> > > Thank you in advance
> > >
> > > Jörg
> > >
> >
>

I tried them but the behavior was the same.

I am afraid that somewhere else is the problem. I mounted also to my
NSLU2, a FAT32 formatted flash disk and I shared it through SAMBA and
again I had similar writing speed problems.  (more than 6 min for a 60
MB file)

As I noticed on a previous email, sometimes the writing speed becomes
zero for more than a minute.  It's like the NSLU2 is struggling to write
to the flash disk!!!

Do you have any ideas?



stanley_p_miller_qaz wrote:
> Try this set of options in your Ubuntu /etc/fstab file.
>
> noatime,rsize=8192,wsize=8192
>
>
> --- In nslu2-linux@yahoogroups.com, vasanag <vasanag@...> wrote:
>> Gurus,
>>
>> I am experiencing very slow writing speed on my NFS share on my UNSLUNG.
>>
>> To write a file of 40 MB from my UBUNTU machine to the NSLU2 I need 3
>> min 15 sec.
>>
>> To read back the same file to UBUNTU, I need only 15 secs!!!!!!
>>
>> What is going on here?  Am I missing something?
>>
>>
>> ************
>>
>> On my NSLU2 running UNSLUNG 6.10
>>
>> # mount
>> ......
>> /dev/sdb1 on /share/hdd/data/USB_D1 type ext3 (rw,noatime)
>>
>>
>> # cat /etc/exports
>> /share/hdd/data/USB_D1 192.168.2.*(rw,sync,no_root_squash)
>>
>>
>> ***********
>>
>> On UBUNTU
>>
>> To mount the share
>>
>> sudo mount 192.168.2.2:/share/hdd/data/USB_D1 /home/anagnost/mnt/nfs_nslu
>>
>>
>> TIA
>> vasanag
>>
>
>
>
>
> ------------------------------------
>

Hi Brian,

thank you for the very fast answer!
Unfortunately it seems that the issue remains, so can you explain what you mean
with "so the problem is in user space"?
Is it a perl bug or a glibc issue from the qnap firmware?
I found an old discussion by googling this issue. See
http://www.justskins.com/forums/about-stat-problem-49666.html
A "perl -V" did not show any -D_FILE_OFFSET_BITS=64 string on my QNAP, but
"uselargefiles=define". On all my other linux boxes this command shows
-D_FILE_OFFSET_BITS=64 as ccflags. But if stat64() is called from perl binary
than it seems that this option have applied.
Very mysterious.

Thank you in advance

Jörg

--- In nslu2-linux@yahoogroups.com, "Brian" <b88zhou@...> wrote:
>
> Doing a strace on a file > 2GB clearly shows that stat64 call has succeeded,
so the problem is in user space.
>
> stat64("big-file", {st_mode=S_IFREG|0777, st_size=2200331748, ...}) = 0
>
> -Brian
>
> --- In nslu2-linux@yahoogroups.com, "joerg_kuehne" <joerg_kuehne@> wrote:
> >
> > Hi,
> >
> > I hope, that anyone in this group can give me a hint about the maintainer of
the perl ipkg-package of the cs08q1armel branch.
> > I found an issue with the pert stat() function, that fails for files larger
than 2GByte on my QNAP TS119. This function is used from the rsnapshot-diff
script to get all informations about a certain file for comparing different
backup snapshots. It seems that perl is compiled without 64Bit support for file
sizes, with 32Bit one can only store size numbers up to 2GByte. Here a little
test script to verify this issue.
> >
> > test.pl
> > --- cut here ---
> > #! /opt/bin/perl
> >
> > @mystat = stat($ARGV[0]);
> > print "$ARGV[0]: file size: $mystat[7]\n";
> > --- cut here ---
> >
> > Run test.pl FILE
> >
> > If file is smaller than 2GByte it will display the right file size, if it is
larger then the file size will be empty caused by the failed stat().
> > Can anyone tell me why perl is compiled without the
> > -D_FILE_OFFSET_BITS=64 option? Is it a restriction of the ARM architecture
or glibc? Or has the usage of this option unwanted side effects or was it simply
forgotten?
> > Thank you in advance
> >
> > Jörg
> >
>

I tried without the sync option but again with no success.

After a more careful look in the progress bar, on my UBUNTU machine,
while writing a file, I noticed that file transfer speed is not
constant.  The progress bar stops, sometimes for more 1 minute in the
same position.  Seems that is struggling to write but something goes
wrong!!!

Any ideas?

vasanag


tlhackque wrote:
>> # cat /etc/exports
>> /share/hdd/data/USB_D1 192.168.2.*(rw,sync,no_root_squash)
>
> Try removing the 'sync' option.
>
> --- In nslu2-linux@yahoogroups.com, vasanag <vasanag@...> wrote:
>> Gurus,
>>
>> I am experiencing very slow writing speed on my NFS share on my UNSLUNG.
>>
>> To write a file of 40 MB from my UBUNTU machine to the NSLU2 I need 3
>> min 15 sec.
>>
>> To read back the same file to UBUNTU, I need only 15 secs!!!!!!
>>
>> What is going on here?  Am I missing something?
>>
>>
>> ************
>>
>> On my NSLU2 running UNSLUNG 6.10
>>
>> # mount
>> ......
>> /dev/sdb1 on /share/hdd/data/USB_D1 type ext3 (rw,noatime)
>>
>>
>> # cat /etc/exports
>> /share/hdd/data/USB_D1 192.168.2.*(rw,sync,no_root_squash)
>>
>>
>> ***********
>>
>> On UBUNTU
>>
>> To mount the share
>>
>> sudo mount 192.168.2.2:/share/hdd/data/USB_D1 /home/anagnost/mnt/nfs_nslu
>>
>>
>> TIA
>> vasanag
>>
>
>
>
>
> ------------------------------------
>

Thanks for reporting the problem. I've corrected the conffile problem in
subversion.

If dhcpd is supposed to support -4, report to the upstream and help them fix the
problem.

For synology NAS, another possible workaround is to get ipv6 kernel module from
optware syno... feed at
   http://ipkg.nslu2-linux.org/feeds/optware/

-Brian

--- In nslu2-linux@yahoogroups.com, "diazeeeee" <diazeeeee@...> wrote:
>
> Hello,
>
> i recently made an upgrade of my isc-dhcp server and i think i messed up.
>
> First of all my dhcpd.conf was overwritten by the default config file provided
with the package. I had a backup but this is surprising.
>
> And then the new DHCP server refuses to starts, since it asks for the ipv6
kernel module to be enabled (which is not enabled in Synology kernel):
>
> Here's the output :
>
> <<
> servebox> dhcpd -4
> Internet Systems Consortium DHCP Server 4.1.0p1
> Copyright 2004-2009 Internet Systems Consortium.
> All rights reserved.
> For info, please visit http://www.isc.org/sw/dhcp/
> Wrote 0 leases to leases file.
> Error opening '/proc/net/if_inet6' to list IPv6 interfaces; No such file or
directory
> Can't get list of interfaces.
>
> If you did not get this software from ftp.isc.org, please
> get the latest from ftp.isc.org and install that before
> requesting help.
>
> If you did get this software from ftp.isc.org and have not
> yet read the README, please read it before requesting help.
> If you intend to request help from the dhcp-server@...
> mailing list, please read the section on the README about
> submitting bug reports and requests for help.
>
> Please do not under any circumstances send requests for
> help directly to the authors of this software - please
> send them to the appropriate mailing list as described in
> the README file.
>
> exiting.
> servebox>
> >>
>
> I obviously tried the -4 option to force ipv4-only but it seems dhcpd has a
bug on it.
>
> Is there a way or a workaround ? My LAN is running with another "emergency"
dhcp server, but this is still annoying...
>
> At least i would like to roll-back to the previous working archive package
(ipk) but I can't find a "Archive" directory in the NSLU2 feeds.
>
> Thanks !
>

Doing a strace on a file > 2GB clearly shows that stat64 call has succeeded, so
the problem is in user space.

stat64("big-file", {st_mode=S_IFREG|0777, st_size=2200331748, ...}) = 0

-Brian

--- In nslu2-linux@yahoogroups.com, "joerg_kuehne" <joerg_kuehne@...> wrote:
>
> Hi,
>
> I hope, that anyone in this group can give me a hint about the maintainer of
the perl ipkg-package of the cs08q1armel branch.
> I found an issue with the pert stat() function, that fails for files larger
than 2GByte on my QNAP TS119. This function is used from the rsnapshot-diff
script to get all informations about a certain file for comparing different
backup snapshots. It seems that perl is compiled without 64Bit support for file
sizes, with 32Bit one can only store size numbers up to 2GByte. Here a little
test script to verify this issue.
>
> test.pl
> --- cut here ---
> #! /opt/bin/perl
>
> @mystat = stat($ARGV[0]);
> print "$ARGV[0]: file size: $mystat[7]\n";
> --- cut here ---
>
> Run test.pl FILE
>
> If file is smaller than 2GByte it will display the right file size, if it is
larger then the file size will be empty caused by the failed stat().
> Can anyone tell me why perl is compiled without the
> -D_FILE_OFFSET_BITS=64 option? Is it a restriction of the ARM architecture or
glibc? Or has the usage of this option unwanted side effects or was it simply
forgotten?
> Thank you in advance
>
> Jörg
>

optware perl is maintained collectively. Initially gda and I made it cross
compilable, and I was responsible for adding a few targets. Recently I've been
busy with lot of other things, so have not been able to spend as much time on
optware as I'd like.

Perl is not the easiest thing to cross compile and maintain.

Regarding this particular issue, I can only say that as far as I can see,

$ grep =64 sources/perl/5.10/config.sh-cs08q1armel
ccflags='-fno-strict-aliasing -pipe -I/opt/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64'
ccflags_uselargefiles='-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'
cppsymbols='_FILE_OFFSET_BITS=64 _LARGEFILE_SOURCE=1 _POSIX_C_SOURCE=200112L
_POSIX_SOURCE=1 __APCS_32__=1 __ARMEL__=1 __ARM_ARCH_4T__=1 __ARM_EABI__=1
__CHAR_BIT__=8 ... unix=1'

I have to look at the build log to see if the option is being applied. Anyone is
welcome to dig deeper and find the issue. We have too many issue finders and too
few problem solvers.

-Brian

--- In nslu2-linux@yahoogroups.com, "joerg_kuehne" <joerg_kuehne@...> wrote:
>
> Hi,
>
> I hope, that anyone in this group can give me a hint about the maintainer of
the perl ipkg-package of the cs08q1armel branch.
> I found an issue with the pert stat() function, that fails for files larger
than 2GByte on my QNAP TS119. This function is used from the rsnapshot-diff
script to get all informations about a certain file for comparing different
backup snapshots. It seems that perl is compiled without 64Bit support for file
sizes, with 32Bit one can only store size numbers up to 2GByte. Here a little
test script to verify this issue.
>
> test.pl
> --- cut here ---
> #! /opt/bin/perl
>
> @mystat = stat($ARGV[0]);
> print "$ARGV[0]: file size: $mystat[7]\n";
> --- cut here ---
>
> Run test.pl FILE
>
> If file is smaller than 2GByte it will display the right file size, if it is
larger then the file size will be empty caused by the failed stat().
> Can anyone tell me why perl is compiled without the
> -D_FILE_OFFSET_BITS=64 option? Is it a restriction of the ARM architecture or
glibc? Or has the usage of this option unwanted side effects or was it simply
forgotten?
> Thank you in advance
>
> Jörg
>

Hi,

I hope, that anyone in this group can give me a hint about the maintainer of the
perl ipkg-package of the cs08q1armel branch.
I found an issue with the pert stat() function, that fails for files larger than
2GByte on my QNAP TS119. This function is used from the rsnapshot-diff script to
get all informations about a certain file for comparing different backup
snapshots. It seems that perl is compiled without 64Bit support for file sizes,
with 32Bit one can only store size numbers up to 2GByte. Here a little test
script to verify this issue.

test.pl
--- cut here ---
#! /opt/bin/perl

@mystat = stat($ARGV[0]);
print "$ARGV[0]: file size: $mystat[7]\n";
--- cut here ---

Run test.pl FILE

If file is smaller than 2GByte it will display the right file size, if it is
larger then the file size will be empty caused by the failed stat().
Can anyone tell me why perl is compiled without the
-D_FILE_OFFSET_BITS=64 option? Is it a restriction of the ARM architecture or
glibc? Or has the usage of this option unwanted side effects or was it simply
forgotten?
Thank you in advance

Jörg

Try this set of options in your Ubuntu /etc/fstab file.

noatime,rsize=8192,wsize=8192


--- In nslu2-linux@yahoogroups.com, vasanag <vasanag@...> wrote:
>
> Gurus,
>
> I am experiencing very slow writing speed on my NFS share on my UNSLUNG.
>
> To write a file of 40 MB from my UBUNTU machine to the NSLU2 I need 3
> min 15 sec.
>
> To read back the same file to UBUNTU, I need only 15 secs!!!!!!
>
> What is going on here?  Am I missing something?
>
>
> ************
>
> On my NSLU2 running UNSLUNG 6.10
>
> # mount
> ......
> /dev/sdb1 on /share/hdd/data/USB_D1 type ext3 (rw,noatime)
>
>
> # cat /etc/exports
> /share/hdd/data/USB_D1 192.168.2.*(rw,sync,no_root_squash)
>
>
> ***********
>
> On UBUNTU
>
> To mount the share
>
> sudo mount 192.168.2.2:/share/hdd/data/USB_D1 /home/anagnost/mnt/nfs_nslu
>
>
> TIA
> vasanag
>

> # cat /etc/exports
> /share/hdd/data/USB_D1 192.168.2.*(rw,sync,no_root_squash)

Try removing the 'sync' option.

--- In nslu2-linux@yahoogroups.com, vasanag <vasanag@...> wrote:
>
> Gurus,
>
> I am experiencing very slow writing speed on my NFS share on my UNSLUNG.
>
> To write a file of 40 MB from my UBUNTU machine to the NSLU2 I need 3
> min 15 sec.
>
> To read back the same file to UBUNTU, I need only 15 secs!!!!!!
>
> What is going on here?  Am I missing something?
>
>
> ************
>
> On my NSLU2 running UNSLUNG 6.10
>
> # mount
> ......
> /dev/sdb1 on /share/hdd/data/USB_D1 type ext3 (rw,noatime)
>
>
> # cat /etc/exports
> /share/hdd/data/USB_D1 192.168.2.*(rw,sync,no_root_squash)
>
>
> ***********
>
> On UBUNTU
>
> To mount the share
>
> sudo mount 192.168.2.2:/share/hdd/data/USB_D1 /home/anagnost/mnt/nfs_nslu
>
>
> TIA
> vasanag
>

As I noted, renaming the config file directory did allow the install.

But shouldn't '-force-downgrade' prevent {i,o}pkg from mis-using it's
"intelligence"?  Or -f /dev/null?  Seems to me that there needs to be a way to
get it to "Do Exactly What I Said".

Is there a bug reporting system for {i,o}pkg?

--- In nslu2-linux@yahoogroups.com, "Mike Westerhof (mwester)" <mwester@...>
wrote:
>
> Yeah, it does that when it thinks it has "better" information in the
> package feed databases.
>
> If you go to the ipkg/opkg feed configuration file directory, and just
> rename the feed config files to something that ipkg/opkg doesn't
> recognize, that'll disable the feeds effectively.  You can then install
> using "./<filename>.ipk" -- only problem is that without any feeds,
> ipkg/opkg can't resolve dependencies, so you'll have to install those
> manually in advance...
>
> Don't forget to rename the feed config files back again when you're done.
>
> -Mike (mwester)
>
> tlhackque wrote:
> > I tried ./ as well as the absolute path to the package.  ipkg still tries to
download the v2 pkg specified by the feed instead of using the file...
> >
> > I don't have this problem when I build a newer version of a package; I have
private versions of bind, dhcp, openssl that all use the file when I specify it.
> >
> > The strange behavior seems to be unique to the down-rev kit.
> >
> > --- In nslu2-linux@yahoogroups.com, "Brian" <b88zhou@> wrote:
> >
> >> You can try "ipkg install ./freeradius_1.1.7-2_armeb.ipk" This makes it
clear that you want to install from file.
> >>
> >> For building optware/nslu2 (unslung) toolchain, it's probably easier just
use latest make/crosstool.mk and sources/crosstool.
> >>
> >> Cheers,
> >>
> >> -Brian
> >>
> >> --- In nslu2-linux@yahoogroups.com, "tlhackque" <tlhackque@> wrote:
> >>
> >>>
> >>> Thanks for the clues.  I built the package - details below.
> >>>
> >>> But ipkg now refuses to install it!  If I say:
> >>>   $ ipkg install freeradius_1.1.7-2_armeb.ipk
> >>> ipkg starts downloading the 2.0.5-2 package from the unslung/cross feed!
> >>>
> >>> I've tried -force-downgrade, even -f /dev/null.  But (as demonstrated with
strace) ipkg goes and reads the /etc/ipkg feed files & then downloads the
2.0.5-2 package.
> >>>
> >>> I note that this package has a 'recommends' for freeradius-doc; putting
that kit in the same directory doesn't help.
> >>>
> >>> The only way to persuade it to use the file specified on the command line
is to
> >>>   $ mv /etc/ipkg /etc/ipkg-x; ipkg install freeradius_1.1.7-2_armeb.ipk;
mv /etc/ipkg-x /etc/ipkg
> >>>
> >>> This seems excessively hard - if I explicitly specify a file, that's what
I want.
> >>>
> >>> Is there an option that I'm missing?  If not this seems like a (moderately
serious) bug.
> >>>
> >>> Other thoughts?
> >>>
> >>> Thanks.
> >>>
> >>> T
> >>>
> >>> Here's what it took to build this package - I'll make a wiki HOWTO when
I've dug out of the current crisis...meantime, perhaps this will help someone
else.
> >>>
> >>> $ svn co https://svn.nslu2-linux.org/svnroot/optware/trunk optware
> >>> $ svn log make/freeradius.mk | less
> >>> # r8749 is the rev that upgraded from 1.1.7
> >>> $ svn up -r8748 <-- We want the rev BEFORE the upgrading commit!
> >>> $ cd optware; make <platform>-target
> >>> $ cd <platform>; make directories toolchain ipkg-utils
> >>>
> >>> Build fails because crosstool 0.38 isn't available.
> >>> Visit http://kegel.com/crosstool/ and find 0.43 is.
> >>>
> >>> Edit optware/make/crosstool.mk to get the newer crosstools
> >>>
> >>> $ make toolchain ipkg-utils
> >>> Ignore lots of glib doesn't build unoptimized errors...
> >>>
> >>> $ make freeradius
> >>>
> >>> Depends on openssl, site is down.  Modify optware/make/openssl.mk to use a
mirror:
> >>>
> >>> OPENSSL_SITE=http://www.mirrorservice.org/sites/ftp.openssl.org/source
> >>>
> >>> Depends on mysql - for some reason, the kit downloads into '.' rather than
'downloads/'.
> >>>
> >>> $ mv mysql downloads/
> >>> $ make freeradius
> >>>
> >>> Curses! ncurses-5.6.tar.gz isn't on the distribution site.  ncurses.tar.gz
has 5.7.  Fetch it, put it in downloads/ and update make/ncurses (which mysql
wants).
> >>>
> >>> $ make mysql
> >>>
> >>> $ make freeradius
> >>> $ make freeradius-ipk
> >>>
> >>> and freeradius_1.1.7-2_armeb.ipk is in builds/
> >>>
> >>> --- In nslu2-linux@yahoogroups.com, "Brian" <b88zhou@> wrote:
> >>>
> >>>> Optware package changes are all recorded in subversion.
> >>>>
> >>>> 1) Follow the instruction on
> >>>>   http://www.nslu2-linux.org/wiki/Optware/AddAPackageToOptware
> >>>> to get optware subversion checkout;
> >>>>
> >>>> 2) Then do "svn log make/freeradius.mk | less" look for the commit that
upgrades it from 1.1.7, in this case it's 8749;
> >>>>
> >>>> 3) You'd want to "turn back the clock"
> >>>> The command probably is "svn up -r8749"
> >>>>
> >>>> 4) Build toolchain, and try to build the package
> >>>>
> >>>> I think I've noticed that in order to build unslung toolchain, you'd need
host gcc 3.x
> >>>>
> >>>> Good luck,
> >>>>
> >>>> -Brian
> >>>>
> >>>> --- In nslu2-linux@yahoogroups.com, "tlhackque" <tlhackque@> wrote:
> >>>>
> >>>>> I'm rebuilding an unslung system from a disk failure, looking for
freeradius 1.1.7-2 - not quite ready to update to freeradius V2 - which is the
current feed.
> >>>>>
> >>>>> Is the old .ipk file available somewhere?  If not, is there a way to
build it from the source repository?
> >>>>>
> >>>>> It would be good to have a HOWTO that describes how to get the build
system to to build a specific version of any package - if someone can give me
the necessary clues, I'll be happy to add to the wiki.
> >>>>>
> >>>>> Thanks.
> >>>>>
> >>>>>
> >
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
>