nars

Members
  • Posts

    356
  • Joined

  • Last visited

Everything posted by nars

  1. Yes, it sorts it Btw, note that the error lines only seems to show on pc display (I did see them testing on a VM), not on telnet, that's maybe why you could not see them.
  2. I did found that every time I browse an hdd on web interface ( i.e. /Main/Browse?dir=/mnt/disk1 ) I do get error lines printed on console like: /file_path.... user.LOCATION: No such attribute
  3. Thanks, will test it and post some feedback soon if any problem found.
  4. Seems related to your php... you will need to provide more details about how you got php, webserver, ... on your system.
  5. It's possible that realtek kernel driver disables wol by default, you may try something like ethtool -s eth0 wol g before power down (and obviously you will need to add it on go file if it works so that it enables it on every boot)
  6. That's community work And I did replied it that quick as I have been looking/researching before at how to compile vbox and some other things (some - other than vbox - didn't really compiled even on older kernels with these symlinks - and even vbox there was warnings about headers not proper for userspace app, you probably did always see that lainie? - that's why I searched a bit about that), but I'm not a linux guru at all, just reading over there, testing, etc Just for curiosity how much time you take to compile kernel and vbox lainie? It takes me about 10min each maybe, did not measure it exactly but near that... having all data stored at ram fs... not sure if it would be much different if storing at hdds but maybe some difference... Btw, I'm curious to test vbox usb sharing with latest kernel see if it continues damn slow as before, but I do not have rc13 yet on my server, I'm just a bit worried about the sync issue and the mysterious writes on it
  7. only cache drive writes increasing? I wonder if not related to sync issue... but that one seems to increase on all disks...
  8. It should also work, I did tried it before with older versions, and yes both worked... my doubt is just what is the more correct thing: use headers to match kernel or to match the ones glibc was compiled with? (as I said before I did read on a few sites recommendations to use ones glibc was compiled with, but I'm not a linux guru to know much further about that subject). Would be nice maybe to know what ones Tom uses to compile unraid kernel?
  9. I did just tried to build it on a test vm with rc13 and exactly as piotrasd stated it needs bc package. However piotrasd: why use latest kernel headers? In all pages I did read it said that we should have at /usr/src/linux/... the headers that have been used to compile our glibc, and we use glibc from slackware 13.1 packages then shouldn't we also use headers from it? Btw, I will edit my modded script above to get bc.
  10. I didn't tried it yet as I'm still not running rc13 on my server, waiting Tom comment the sync issue, make sure all ok, etc... as I have no backup of my data, need to care about it However I have an idea that maybe can help you on that problem... I guess you are linking /usr/include/asm-generic, /usr/include/linux and /usr/include/asm to /usr/src/linux/... as stated on the wiki page about compiling vbox, right? I did some research some time ago about that and from what I did read I don't think such procedure is the most correct... and it may be the cause of the problem you get with the new kernel... from what I did read you should always have at /usr/src/linux/... the kernel headers of the version that was used to compile your glibc and not the the ones from some new kernel... then instead of creating such symlinks as stated on the wiki, just try to install this package: http://slackware.osuosl.org/slackware-13.1/slackware/d/kernel-headers-2.6.33.4_smp-x86-1.txz (these are the kernel headers that have been used to to compile your glibc... I think these should be the ones to use? someone correct me if I'm wrong...) I do usually use the slightly modified script below to setup "development environment", compile kernel, ... always with no problem, but again didn't it yet with rc13. #!/bin/bash SDIR="$(dirname "$(readlink -f ${BASH_SOURCE[0]})")" KVER=`uname -r | cut -d"-" -f1` KDIR="/usr/src/linux-$(uname -r)" [ ! -d "$SDIR/packages" ] && mkdir $SDIR/packages cd $SDIR/packages [ ! -e "linux-$KVER.tar.gz" ] && wget --no-check-certificate http://www.kernel.org/pub/linux/kernel/v3.x/linux-$KVER.tar.gz [ ! -e "gcc-4.4.4-i486-1.txz" ] && wget http://slackware.osuosl.org/slackware-13.1/slackware/d/gcc-4.4.4-i486-1.txz [ ! -e "kernel-headers-2.6.33.4_smp-x86-1.txz" ] && wget http://slackware.osuosl.org/slackware-13.1/slackware/d/kernel-headers-2.6.33.4_smp-x86-1.txz [ ! -e "glibc-2.11.1-i486-3.txz" ] && wget http://slackware.osuosl.org/slackware-13.1/slackware/l/glibc-2.11.1-i486-3.txz [ ! -e "binutils-2.20.51.0.8-i486-1.txz" ] && wget http://slackware.osuosl.org/slackware-13.1/slackware/d/binutils-2.20.51.0.8-i486-1.txz [ ! -e "make-3.81-i486-1.txz" ] && wget http://slackware.osuosl.org/slackware-13.1/slackware/d/make-3.81-i486-1.txz [ ! -e "cxxlibs-6.0.13-i486-2.txz" ] && wget http://slackware.osuosl.org/slackware-13.1/slackware/a/cxxlibs-6.0.13-i486-2.txz [ ! -e "perl-5.10.1-i486-1.txz" ] && wget http://slackware.osuosl.org/slackware-13.1/slackware/d/perl-5.10.1-i486-1.txz [ ! -e "patch-2.5.4-i486-1.txz" ] && wget http://slackware.osuosl.org/slackware-13.1/slackware/a/patch-2.5.4-i486-1.txz [ ! -e "ncurses-5.7-i486-1.txz" ] && wget http://slackware.osuosl.org/slackware-13.1/slackware/l/ncurses-5.7-i486-1.txz [ ! -e "mpfr-2.4.2p03-i486-1.txz" ] && wget http://slackware.osuosl.org/slackware-13.1/slackware/l/mpfr-2.4.2p03-i486-1.txz [ ! -e "gcc-g++-4.4.4-i486-1.txz" ] && wget http://slackware.osuosl.org/slackware-13.1/slackware/d/gcc-g++-4.4.4-i486-1.txz [ ! -e "pkg-config-0.23-i486-2.txz" ] && wget http://slackware.osuosl.org/slackware-13.1/slackware/d/pkg-config-0.23-i486-2.txz [ ! -e "bc-1.06.95-i486-1.txz" ] && wget http://slackware.osuosl.org/slackware-13.1/slackware/ap/bc-1.06.95-i486-1.txz installpkg *.txz [ ! -e "${KDIR}_original" ] && mv $KDIR ${KDIR}_original [ -e "$KDIR" ] && rm -rf $KDIR [ -e "/usr/src/linux-$KVER" ] && rm -rf /usr/src/linux-$KVER tar -C /usr/src/ -zxf $SDIR/packages/linux-$KVER.tar.gz mv /usr/src/linux-$KVER $KDIR [ -e "/usr/src/linux" ] && rm -rf /usr/src/linux ln -sf $KDIR /usr/src/linux cp -rf ${KDIR}_original/. /usr/src/linux/ cd /usr/src/linux && yes "" | make oldconfig && make
  11. smb only on my test system, I did tested it with a clean config setup, no plugins and all defaults.
  12. Guys can someone answer this please? I am getting nervous. Nothing wrong afaik... updating latest versions have been always like that.
  13. Also found that it's suffice to stop array and start it again for it to stop these strange writes. Also I did downgraded on my test system to rc12a to test and can confirm that sync issue do not happen on rc12a.
  14. I think all things Barzija pointed are not new to latest RC except the sync issue, seems really strange that it will keep writing all disks forever, and I can also reproduce it on a test system, didn't installed it on my server (on my sig) yet.
  15. Please mention it, if it is something we should know... and don't forget realtek driver Edit: Oops, I see you don't need to "don't forget it" anymore, hope kernel one works fine for all chip variations
  16. johnodon: not sure if you noticed there was an update: Just finished testing everything I wanted to get into -rc13, so it will be tomorrow (or rather later today - Monday).
  17. I did tested it recently on my modest server and it was worst when NCQ on.
  18. GCC on slackware 13.1 is 4.4.4, guess Tom only updated kernel, for some good reason...
  19. I did refer about partition label for the case we don't want to use an usb flash at all (I did tried that before to run unraid on vmware for testing), but surely it would only work with free version as Joe said... Anyway, thinking a bit more, even with free version.. having unraid using usb flash to store configs, etc is probably more reliable really
  20. You may boot from an HDD, but you need a FAT32 partition with UNRAID label and syslinux installed on it... maybe you can have such partition on an hdd you may also use as cache disk, as from what I did read UNRAID will only use 1st partition for cache, but you will need to create such reiserfs partition manually as well... I did never tried to do it but if you search on forum you will find info on how to do it.
  21. Would be probably better you start a new topic for that problem. Btw, the syslog you posted is only last few lines on it... you need to get full syslog from Utils -> System Log also good posting hdd smart status (smartctl -a /dev/sdX where X=a,b,c,...) if the drive is detected else you can't. Btw also make sure all you power/sata connections are ok.
  22. Sorry, my bad, I did just a quick search for it and found that... and think the red text was not there (?) and that post shows last edit: today... guess probably Joe L. just added it after my bad advice Btw, I did just tested myself with lines similar to the ones you have to add new crontab lines from my go file and it works fine... and... when looking at your go file again I guess I did just found the cause of all your problem, you should have: #!/bin/bash # Start the Management Utility /usr/local/sbin/emhttp & crontab -l >/tmp/crontab echo "15 7 2 * * /mnt/user/settingshare/md5checker/scriptmd5sum" >>/tmp/crontab echo "15 7 17 * * /mnt/user/settingshare/md5checker/scriptmd5sum" >>/tmp/crontab crontab /tmp/crontab Note that you removed the & at the end of the line that runs emhttp then it will not load emhttp on background and will block your go script, no further commands would run until emhttp terminate... And don't forget Joe L. advice for not using /sbin/poweroff ... you should probably use /usr/local/sbin/powerdown script instead.
  23. See this: http://lime-technology.com/forum/index.php?topic=6593.0