• Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About toobueller

  • Rank
    Junior Member
  1. toobueller

    Thank You

    I have to chime in on this one as well. Since using Xpenology at home, I have purchased 1 high end and 2 mid grade Synology devices at work. Were it not for Xpenology, I would not have considered anything other than something like FreeNas, which really would not have met my needs the way Synology does. Were the hardware not so expensive, I would replace my xpenology box with a Synology one.
  2. If I understand correctly, there used to be a complete distro called "Xpenology," but for whatever reason, it is no longer released as such. Now we have Xpenoboot which allows us to boot the actual Synology distribution, thus negating the need for "xpenology" as a distro and relegating it to a definition of "A state of running Synology on 3rd party hardware with the assistance of a boot loader" Thus, asking for the latest version of xpenology is basically asking what's the latest Synology vesrsion supported by the latest bootloader? Semantics aside, I would like to see an up to date full distro that can support non-pc hardware and other devices. As OP indicated, it seems the newest version is based on a much older DSM version.
  3. Getting onto the second USB stick might be a problem if the installer doesn't see it as a usable destination. Having said that, if you have an old hard small hard drive (40GB-120GB) that you can install it to, you may be able to use dd to copy it to a USB drive, but you will likely have to edit which drives are marked as 'internal' and 'external' by DSM. Search for topics on hiding the USB drive from DSM or changing ESATA from being seen as external, and that will get you in the ballpark for what you need to do. Best case, you may not need to do any of that. It will have to be a separate thumb drive. DSM wont let you install into all that unused partition space on your USB drive. I can see this being useful as a mini-appliance that has low storage requirements, and low energy foot print requirements.
  4. I have had issues with booting after attempting to write the image with dd. This should work, so I must have done something wrong. I haven't found a definite answer on exactly what to write to... dd if=xpenology-latest.img of=/dev/sdg or dd if=xpenology-latest.img of=/dev/sdg1 using the comand: fdisk -l and searching for FAT16 I think would work for determining the boot partition of the USB stick Searching the lines above it for "MB" would qualify as a secondary confirmation that this is a small partition. if the 8011 size is a constant, you could throw that in to the search, too. I don't trust that will remain a constant. The search should not stop on the first occurrence, just in case someone has more than one small USB drive attached, but should return a list of the likely candidates that someone can use on the command line for the next run to complete the update. which goes back to my question. is it /dev/sdX or /dev/sdX1 for the destination (your X may vary) Please post your script when complete. I may work on a basic one this weekend, since I hate having to take my box apart to pull the stick for the update. Also don't like having it plugged in on the outside, so a script would be a good solution. There may be other commands you can use to determine the correct volume (Like using "ls" on the matched volumes found by "fdisk -l" filtered for "FAT16" and "MB" to find xpenoboot files) my fdisk -l returns this: (truncated to the relevant partitions) Disk /dev/sdg: 8011 MB, 8011120640 bytes 4 heads, 32 sectors/track, 122240 cylinders Units = cylinders of 128 * 512 = 65536 bytes Device Boot Start End Blocks Id System /dev/sdg1 * 1 256 16352+ e Win95 FAT16 (LBA)
  5. does wget http://YourIpaddress:5000 return anything (From the xpen command line) or Not sure on the exact command to get it to use port 5000, and no access to test it at the moment, but the idea is to see if maybe it's some kind of new firewall or security setting.
  6. Many have upgraded and are running again. Your best bet is to read the threads and determine what's best for you. Without exact information on your setup you can't reliably expect a definite yes or no that will apply to you. Is yours bare metal or a VM? what hardware are you using? You said yours stops working, but didn't specify what that means? does it hard lock? Is it just the network connection that seems to stop working?
  7. Are you asking if it is possible to boot ubuntu and chroot DSM? (I was wondering this myself, a few days ago.) If not, I think you need to clarify. the debian chroot package looks like what you might want, based on your description.
  8. Try repeating again, after a reboot. examine the contents of /var/log/messages for clues. I think there is another log file that may have some more messages, but I don't remember where it is and don't have access at to find it the moment. I hope this isn't a bug in the patch.
  9. I had a similar problem with 5.0 and resorted to writing a script that was chronned to run every 5 minutes. If interested, I'll post it later. as root... ifconfig eth0 down ifconfig eth1 down ifconfig eth0 up ifconfig eth1 up Mine was dropping IPv4, but IPv6 was still up, which didn't help me trying to connect to it via an ipv4 address. I only needed the eth0 up/down commands for my single interface. Not sure how this will work on the bonded interface, but it's worth a shot. use ifconfig and see what kind of errors you get. That will help in determining what is going on. It may be a similar problem. ex: use this when the problem is happening ifconfig > /tmp/linkdown and this when it's working fine. ifconfig > /tmp/linkup Compare the results. This helped me discover that the link was still up, but that IPv4 had dropped for some reason. EDIT: Added script and text below. This is a script I wrote. Originally I ran a version of it in one of my newznab scripts, but then just sourced it and chronned it for every 5 minutes. You'll need to edit it for your bonded link and change it to look for your particular problem, but it if resetting eth0 and eth1 fixes it for you, this might work. One more item. I just realized that the bonded link might create something like eth2. If that's the case, try resetting only that or if that doesn't work, a combination of the three. Again, compare what ifconfig reports when it is down and when it is up. I don't really have a lot of experience writing shell scripts, so this may look a little amateur-ish If it detects a problem (ifconfig says I don't have an IP address), it bounces eth0 and then checks again and logs the reported ip to a log file. #!/bin/sh # testing for connectivity and bouncing link if there is a problem #replace below with your ip address export MY_IP="" lc_LOGFILE=/var/log/linkcheck.log # set to /dev/null for no logging checkEthx() { export lc_ETH="eth0" export lc_IP_ADDR="" export lc_REPORTED_IP=`ifconfig $ETH|grep "$lc_IP_ADDR"|awk -F':+| +' '{print $4}'` export LOGGER_CMD="/usr/bin/logger" # echo Reported: $REPORTED_IP # echo Actual: $IP_ADDR if [ -z $lc_REPORTED_IP ] then echo "Problem detected at `date`: IPV4 is down ">>$lc_LOGFILE ifconfig $lc_ETH down sleep 1 ifconfig $lc_ETH up # run again to (hopefully) set the variable to a reported IP that matches with our known working IP export lc_REPORTED_IP=`ifconfig $lc_ETH|grep "$lc_IP_ADDR"|awk -F':+| +' '{print $4}'` echo "Logging results of ping: `ping -c1 -q $lc_IP_ADDR`">>$lc_LOGFILE echo "logging last result or lc_REPORTED_IP ** $lc_REPORTED_IP ** ">>$lc_LOGFILE $LOGGER_CMD -t LINKCHECK "REPORTED_IP was $lc_REPORTED_IP" $LOGGER_CMD -t LINKCHECK "lc_IP_ADDR is $lc_IP_ADDR" $LOGGER_CMD -t LINKCHECK "PING RESULT was `ping -c1 -q $lc_IP_ADDR`" #else # $LOGGER_CMD -t LINKCHECK "Link OK at `date` " # echo "LINK OK `date` $lc_REPORTED_IP">>$lc_LOGFILE fi } # call once - also added for command line compatibility, since this is sourced into another script for the function. # checkEthx
  10. I have not had that problem. See my previous post. One or more of your feeds are bad and that is what is causing the hang. Either replace your feeds with the contents I posted above, or you could manually go through your list to check which ones are bad. My list is fairly complete and I've removed bad repos. Mine loads in seconds and that's on a slow day. If you want to do it yourself and you're confident your list is complete, manually go through your list, edit each one and change the name/description slightly (No need to change the url portion). When you save it your box will check if the site is valid and responding. If any have problems with one, remove it or try to find the new url, if it has changed. When you're done going through your list you will see that yours now loads more quickly. Also remember to adjust the trust level in settings general. Remove any edit to your host file for
  11. I've Trimmed down feeds file for package sources. If I received errors from a site or could not add a site manually, it was removed from my list. This list loads much faster than before, with bad and unresponsive repos removed. Some of these may require you to set "Any publisher" under Settings ... General in the package center backup your feeds file /usr/syno/etc/packages/feeds and replace the contents with the below. [{"feed":"","name":""},{"feed":"","name":""},{"feed":"","name":""},{"feed":"","name":""},{"feed":"","name":""},{"feed":"","name":""},{"feed":"","name":""},{"feed":"","name":""},{"feed":"","name":""},{"feed":"","name":" beta"},{"feed":"","name":""},{"feed":"","name":""},{"feed":"","name":""},{"feed":"","name":""},{"feed":"","name":""},{"feed":"","name":" beta"},{"feed":"","name":""},{"feed":"","name":""},{"feed":"","name":""},{"feed":"","name":""},{"feed":"","name":""},{"feed":"","name":""},{"feed":"","name":""}] If you find any missing that you know to work, please post it here.
  12. For those editing the host file(see below) to get volumes to work, echo >> /etc/hosts a possible temporary solution for updating packages is: mv /etc/hosts /etc/nohosts perform your package installs or updates and then mv /etc/nohosts /etc/hosts afterward. This is untested, but based on some feedback I'm seeing, it looks like it would work on a temporary basis. Also, Completely disable any automatic update checking in the control panel, just in case, and also adjust the settings in package manager to allow packages other than the official synology spks to be installed.
  13. Just curious what's different in this version, if it is legitimate. I'm going to guess that it fixes some bugs for booting into DSM 5.0, but doesn't yet boot 5.1. (click the download link at the top of the page) I don't trust the colafile download page. Malwarebytes blocks several things on that page and blocks my download. The Dropbox file names indicate version 5.04.1, but the main page (updated January 6th) doesn't mention this version as of today (January 8th). The site appears to have expired or been replaced by one of those generic link pages that domain hosts often put up. a mirror site at does not show the version, but only up to No mention of it on cynlabs forum Nothing on either. I have to get back to work, so I can't investigate further until later this evening.
  14. I'm posting this here for my own future reference, and to help anyone that needs a fast and reliable method of getting the list of feeds added to their "Package Center". Basically adding a feed list of the spk repositories all in one file that can be quickly uploaded. docmoe's site is helpful to determine if the site is reachable, but doesn't help to determine if it is still a working SPK repo, so I added that list to my own and filtered out all the sites that I had trouble connecting to, and resulted in a feeds file that can easily be added to any syno box, quickly and painlessly. the feeds file is currently stored in /usr/syno/etc/packages in DSM 5 if you're just installing your box for the first time, copy the text below into a file called "feeds" and put it into the /usr/syno/etc/packages directory As Loderunner pointed out (Thank you, btw), this is JSON source. Notepad++ was able to help me to reformat the text to something more easily read by a human. Pasted below I haven't tested in the human readable format, but if this file is read by anything that understands JSON, the human readable formatting shouldn't be a problem. The default formatting is one long line. DSM 5 location (Same in previous versions?) b]/usr/syno/etc/packages/feeds[/b] [{ "feed": "", "name": "" }, { "feed": "", "name": "" }, { "feed": "", "name": "" }, { "feed": "", "name": "" }, { "feed": "", "name": "" }, { "feed": "", "name": "" }, { "feed": "", "name": "" }, { "feed": "", "name": "" }, { "feed": "", "name": "" }, { "feed": "", "name": "" }, { "feed": "", "name": "" }, { "feed": "", "name": "" }, { "feed": "", "name": "" }, { "feed": "", "name": "" }, { "feed": "", "name": "" }, { "feed": "", "name": "" }, { "feed": "", "name": "" }, { "feed": "", "name": "" }, { "feed": "", "name": "" }, { "feed": "", "name": "" }, { "feed": "", "name": "" }, { "feed": "", "name": "" }, { "feed": "", "name": "" }, { "feed": "", "name": "" }, { "feed": "", "name": "" }, { "feed": "", "name": "" }, { "feed": "", "name": "" }, { "feed": "", "name": "" }, { "feed": "", "name": "" }, { "feed": "", "name": "" }, { "feed": "", "name": "" }, { "feed": "", "name": "" }, { "feed": "", "name": "" }, { "feed": " ", "name": " " }, { "feed": "", "name": "" }, { "feed": "", "name": "" }, { "feed": "", "name": "" }, { "feed": "", "name": "" }, { "feed": "", "name": "" }] If you already have your own list, you may want to compare with this one and adjust accordingly. A few other things to note about these feeds. The first time you get the feeds your package center may choke and complain about a dropped connection, if you 'tail /var/log/messages' you'll see a few sites that might be experiencing difficulties. I eliminated and corrected many of the sites that are incorrect or down forever, but there are a few that I either left because it looked like a temporary problem, or were left because I couldn't determine the actual site with problems via /var/log/messages. I left a couple that looked like they might just be having temporary problems. What's left is a list of the most up to date spk repositories that I could pull together quickly. Below is information if you need to edit the file. Chances are if you're installing this file, you wont need to read it. Note the formatting is JSON. fairly simple. It is a feed url follwed by the feed name. I left the name the same as the feed, but you can change them to whatever is appropriate for each site. file begins with a [ and ends with a ] each feed is surrounded by { } Each feed is separated by a single comma " , " it is all on one single line. Example file: (Don't use this one) [{"feed":"","name":""},{"feed":"url to site","name":"nick name or aka or other label for the site"},{and so on...}]