toobueller

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.

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.

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.

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)

does wget http://YourIpaddress:5000 return anything (From the xpen command line) or http://127.0.0.1:5000 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.

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?

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.

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.

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. linkcheck.sh #!/bin/sh # testing for connectivity and bouncing link if there is a problem #replace below with your ip address export MY_IP="192.168.11.222" lc_LOGFILE=/var/log/linkcheck.log # set to /dev/null for no logging checkEthx() { export lc_ETH="eth0" export lc_IP_ADDR="192.168.11.222" 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

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 payment.synology.com.

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":"http://cbo.netau.net/synopackages/","name":"cbo.netau.net"},{"feed":"http://cytec.us/spk/","name":"cytec.us"},{"feed":"http://e-remonty.info/spkrepo/packages","name":"e-remonty.info"},{"feed":"http://ggteknikus.tk/sspks/","name":"ggteknikus.tk"},{"feed":"http://packages.jdel.org/","name":"jdel.org"},{"feed":"http://packages.jdel.org/","name":"jdel.org"},{"feed":"http://packages.mdevries.org","name":"mdevries.org"},{"feed":"http://packages.pcloadletter.co.uk/","name":"packages.pcloadletter.co.uk"},{"feed":"http://packages.synocommunity.com","name":"synocommunity.com"},{"feed":"http://packages.synocommunity.com/?beta=1","name":"synocommunity.com beta"},{"feed":"http://pvr.unzureichende.info/synology","name":"pvr.unzureichende.info"},{"feed":"http://spk.naefmarco.ch/spkrepo/packages","name":"spk.naefmarco.ch"},{"feed":"http://spk.nas-mirror.de/spkrepo/packages","name":"spk.nas-mirror.de"},{"feed":"http://spk.unzureichende.info/","name":"unzureichende.info"},{"feed":"http://synobox.fr.nf/synopackages/","name":"synobox.fr.nf"},{"feed":"http://synobox.fr.nf/synopackages/beta.php","name":"synobox.fr.nf beta"},{"feed":"http://synology.acmenet.ru","name":"synology.acmenet.ru"},{"feed":"http://packages.mdevries.org/","name":"mdevries.org"},{"feed":"http://synology.sysco.ch","name":"synology.sysco.ch"},{"feed":"http://synopkgs-garble.rhcloud.com/","name":"synopkgs-garble.rhcloud.com"},{"feed":"http://www.brigittehelsen.be/plexconnect/","name":"www.brigittehelsen.be/plexconnect/"},{"feed":"http://www.cphub.net/index.php/getpackages.php/","name":"www.cphub.net"},{"feed":"https://www.cphub.net/packages.php","name":"cpbhub.net"}] If you find any missing that you know to work, please post it here.

For those editing the host file(see below) to get volumes to work, echo 127.0.0.1 payment.synology.com >> /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.

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. http://nanoboot.eu.org (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 nanoboot.tk appears to have expired or been replaced by one of those generic link pages that domain hosts often put up. a mirror site at http://xpenology.pety.me/ does not show the 5.0.4.1 version, but only up to 5.0.3.1 No mention of it on cynlabs forum http://cyanlabs.net/Forum-XPEnology-Gnoboot-Nanoboot-Support Nothing on http://forum.xpenology.nl/ either. I have to get back to work, so I can't investigate further until later this evening.

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": "http://cbo.netau.net/synopackages/", "name": "http://cbo.netau.net/synopackages/" }, { "feed": "http://cytec.us/spk/", "name": "http://cytec.us/spk/" }, { "feed": "http://e-remonty.info/spkrepo/packages", "name": "http://e-remonty.info/spkrepo/packages" }, { "feed": "http://ggteknikus.tk/sspks/", "name": "http://ggteknikus.tk/sspks/" }, { "feed": "http://packages.jdel.org/", "name": "http://packages.jdel.org/" }, { "feed": "http://packages.jdel.org/", "name": "http://packages.jdel.org/" }, { "feed": "http://packages.mdevries.org", "name": "http://packages.mdevries.org" }, { "feed": "http://packages.mertymade.com/", "name": "http://packages.mertymade.com/" }, { "feed": "http://packages.missilehugger.com/", "name": "http://packages.missilehugger.com/" }, { "feed": "http://packages.page81.net/", "name": "http://packages.page81.net/" }, { "feed": "http://packages.pcloadletter.co.uk/", "name": "http://packages.pcloadletter.co.uk/" }, { "feed": "http://packages.quadrat4.de/", "name": "http://packages.quadrat4.de/" }, { "feed": "http://packages.synocommunity.com", "name": "http://packages.synocommunity.com" }, { "feed": "http://packages.synocommunity.com/?beta=1", "name": "http://packages.synocommunity.com/?beta=1" }, { "feed": "http://pcloadletter.comlu.com/", "name": "http://pcloadletter.comlu.com/" }, { "feed": "http://pvr.unzureichende.info/synology", "name": "http://pvr.unzureichende.info/synology" }, { "feed": "http://repo.synozwave.com/", "name": "http://repo.synozwave.com/" }, { "feed": "http://spk.naefmarco.ch/spkrepo/packages", "name": "http://spk.naefmarco.ch/spkrepo/packages" }, { "feed": "http://spk.naefmarco.ch/spkrepo/packages/", "name": "http://spk.naefmarco.ch/spkrepo/packages/" }, { "feed": "http://spk.nas-mirror.de/", "name": "http://spk.nas-mirror.de/" }, { "feed": "http://spk.nas-mirror.de/spkrepo/packages", "name": "http://spk.nas-mirror.de/spkrepo/packages" }, { "feed": "http://spk.synologyitalia.com", "name": "http://spk.synologyitalia.com" }, { "feed": "http://spk.unzureichende.info/", "name": "http://spk.unzureichende.info/" }, { "feed": "http://subtitlessh.no-ip.biz/repo_spk/", "name": "http://subtitlessh.no-ip.biz/repo_spk/" }, { "feed": "http://synobox.fr.nf/synopackages/", "name": "http://synobox.fr.nf/synopackages/" }, { "feed": "http://synobox.fr.nf/synopackages/beta.php", "name": "http://synobox.fr.nf/synopackages/beta.php" }, { "feed": "http://synology.acmenet.ru", "name": "http://synology.acmenet.ru" }, { "feed": "http://packages.mdevries.org/", "name": "http://packages.mdevries.org/" }, { "feed": "http://synology.sysco.ch", "name": "http://synology.sysco.ch" }, { "feed": "http://synology.w01.eu", "name": "http://synology.w01.eu" }, { "feed": "http://synopkg.superzebulon.org/spkrepo/packages", "name": "http://synopkg.superzebulon.org/spkrepo/packages" }, { "feed": "http://synopkgs-garble.rhcloud.com/", "name": "http://synopkgs-garble.rhcloud.com/" }, { "feed": "http://update.10trum.de/packageupdate/getpackages.php", "name": "http://update.10trum.de/packageupdate/getpackages.php" }, { "feed": "http://www.brigittehelsen.be/plexconnect/ ", "name": "http://www.brigittehelsen.be/plexconnect/ " }, { "feed": "http://www.christoph-papke.de/spkrepo/spkrepo/packages/", "name": "http://www.christoph-papke.de/spkrepo/spkrepo/packages/" }, { "feed": "http://www.cphub.net/index.php/getpackages.php/", "name": "http://www.cphub.net/index.php/getpackages.php/" }, { "feed": "http://www.need-soft.com/packages/index.php/spkrepo/packages", "name": "http://www.need-soft.com/packages/index.php/spkrepo/packages" }, { "feed": "https://synocommunity.com/packages", "name": "https://synocommunity.com/packages" }, { "feed": "https://www.christoph-papke.de/spkrepo/spkrepo/packages", "name": "https://www.christoph-papke.de/spkrepo/spkrepo/packages" }] 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":"http://packages.synocommunity.com/?beta=1","name":"http://packages.synocommunity.com/?beta=1"},{"feed":"url to site","name":"nick name or aka or other label for the site"},{and so on...}]

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" 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 FILENAME: /usr/syno/etc/packages/feeds CONTENTS: [{"feed":"http://cbo.netau.net/synopackages/","name":"http://cbo.netau.net/synopackages/"},{"feed":"http://cytec.us/spk/","name":"http://cytec.us/spk/"},{"feed":"http://e-remonty.info/spkrepo/packages","name":"http://e-remonty.info/spkrepo/packages"},{"feed":"http://ggteknikus.tk/sspks/","name":"http://ggteknikus.tk/sspks/"},{"feed":"http://packages.jdel.org/","name":"http://packages.jdel.org/"},{"feed":"http://packages.jdel.org/","name":"http://packages.jdel.org/"},{"feed":"http://packages.mdevries.org","name":"http://packages.mdevries.org"},{"feed":"http://packages.mertymade.com/","name":"http://packages.mertymade.com/"},{"feed":"http://packages.missilehugger.com/","name":"http://packages.missilehugger.com/"},{"feed":"http://packages.page81.net/","name":"http://packages.page81.net/"},{"feed":"http://packages.pcloadletter.co.uk/","name":"http://packages.pcloadletter.co.uk/"},{"feed":"http://packages.quadrat4.de/","name":"http://packages.quadrat4.de/"},{"feed":"http://packages.synocommunity.com","name":"http://packages.synocommunity.com"},{"feed":"http://packages.synocommunity.com/?beta=1","name":"http://packages.synocommunity.com/?beta=1"},{"feed":"http://pcloadletter.comlu.com/","name":"http://pcloadletter.comlu.com/"},{"feed":"http://pvr.unzureichende.info/synology","name":"http://pvr.unzureichende.info/synology"},{"feed":"http://repo.synozwave.com/","name":"http://repo.synozwave.com/"},{"feed":"http://spk.naefmarco.ch/spkrepo/packages","name":"http://spk.naefmarco.ch/spkrepo/packages"},{"feed":"http://spk.naefmarco.ch/spkrepo/packages/","name":"http://spk.naefmarco.ch/spkrepo/packages/"},{"feed":"http://spk.nas-mirror.de/","name":"http://spk.nas-mirror.de/"},{"feed":"http://spk.nas-mirror.de/spkrepo/packages","name":"http://spk.nas-mirror.de/spkrepo/packages"},{"feed":"http://spk.synologyitalia.com","name":"http://spk.synologyitalia.com"},{"feed":"http://spk.unzureichende.info/","name":"http://spk.unzureichende.info/"},{"feed":"http://subtitlessh.no-ip.biz/repo_spk/","name":"http://subtitlessh.no-ip.biz/repo_spk/"},{"feed":"http://synobox.fr.nf/synopackages/","name":"http://synobox.fr.nf/synopackages/"},{"feed":"http://synobox.fr.nf/synopackages/beta.php","name":"http://synobox.fr.nf/synopackages/beta.php"},{"feed":"http://synology.acmenet.ru","name":"http://synology.acmenet.ru"},{"feed":"http://packages.mdevries.org/","name":"http://packages.mdevries.org/"},{"feed":"http://synology.sysco.ch","name":"http://synology.sysco.ch"},{"feed":"http://synology.w01.eu","name":"http://synology.w01.eu"},{"feed":"http://synopkg.superzebulon.org/spkrepo/packages","name":"http://synopkg.superzebulon.org/spkrepo/packages"},{"feed":"http://synopkgs-garble.rhcloud.com/","name":"http://synopkgs-garble.rhcloud.com/"},{"feed":"http://update.10trum.de/packageupdate/getpackages.php","name":"http://update.10trum.de/packageupdate/getpackages.php"},{"feed":"http://www.brigittehelsen.be/plexconnect/ ","name":"http://www.brigittehelsen.be/plexconnect/ "},{"feed":"http://www.christoph-papke.de/spkrepo/spkrepo/packages/","name":"http://www.christoph-papke.de/spkrepo/spkrepo/packages/"},{"feed":"http://www.cphub.net/index.php/getpackages.php/","name":"http://www.cphub.net/index.php/getpackages.php/"},{"feed":"http://www.need-soft.com/packages/index.php/spkrepo/packages","name":"http://www.need-soft.com/packages/index.php/spkrepo/packages"},{"feed":"https://synocommunity.com/packages","name":"https://synocommunity.com/packages"},{"feed":"https://www.christoph-papke.de/spkrepo/spkrepo/packages","name":"https://www.christoph-papke.de/spkrepo/spkrepo/packages"}] If you already have your own list, you may want to compare with this one. 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 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: [{"feed":"http://packages.synocommunity.com/?beta=1","name":"http://packages.synocommunity.com/?beta=1"},{"feed":"url to site","name":"nick name or aka or other label for the site"},{and so on...}]

I had a similar problem a few days ago. my newznab and spotweb stopped working and after everything else failed, I thought a reboot might fix things. When it rebooted, I saw error messages and was no longer able to login or even use the keyboard on the console. Turns out that something corrupted my root partition ( /dev/md0) so the only way I had to fix it was to reinstall syno. From now on, I am making backups of that partition. I lost several databases in that partition (Probably the reason it crashed). Fortunately, that was backed up. Try booting with something like SystemRescueCD and see if you can mount /dev/md0 (em dee zer0) mkdir /tmproot mount /dev/md0 /temproot ls /temproot If you can see your files, you might be able to find the problem and fix it without a reinstall. You will not see volume1 there. You will have to mount that separate. I don't recall where the system rescue cd put it, but I was able to find it under something like /dev/vg1 You may have to play with mdadm to get it mounted. Other useful commands are df cat /proc/partitions (Look for the largest one) I plan to add a nightly dd backup of that partition, from now on, and also reconfiguring my databases to be on the main volume and not defaulting to one that might fill up and cause unintentional corruption. dd if=/dev/md0 if=/pathto/mybackup/file

I should add. attempting to migrate didn't work. I get an error "Available system space is unsufficient. (16)" I'm reasonably confident it's just a matter of removing a symlink or deleting a few files or something that wont involve reformatting.

Interestingly, I got this same message this evening. I was having strange problems that I thought would be fixed by a reboot. After rebooting, my login prompt is (none) login: instead of (MyServerName) login: it does not respond to keyboard input, including caps lock and numlock (no lights when I type them) It does not respond on the network. If I reboot and try to "upgrade" and migrate to fix the problem without losing data, I see some of the error messages you are seeing "awk not found.. etc.." I think the problem is one of two things. my /tmp is full (But I if /tmp is ram, that can't be it) or a recent installation of ipk coreutiils, which replaced awk provided by synology's busybox install. Problem is that I don't know the default password to login when the xpenology is in install mode. I tried this link https://wrgms.com/synologys-secret-telnet-password/ but I'm guessing syno figured that was insecure and removed it, because that didn't work. I really don't want to have to wipe and start over, because of a recent problem with a backup volume, my current backup is incomplete. Any thoughts on how to access the shr raid volume to try to diagnose the problem, or at least backup what is on it? ( Close to 8 Terabytes of videos and newznab/spotweb NZBs )

I ran into a similar problem with an external JBOD unit that said it would work if the chipset would work with a port multiplier. The USB 3.0 interface was faster, so I focused on that. Especially after I could not get my box to even recognize a single drive. I used Syno's method to turn the 4 external drives into a raid array. I got it working... Sort of.. The syno box kept trying to mount the USB drives, even after I dismounted them and created the raid. This caused corruption in the volume and I couldn't find a way around the problem. I also couldn't figure out how to get the syno to recognize the drive and make it usable to the syno apps (FIle Manager, for example). I could mount it to the root as /volume2 using that method, but it was useless for any syno apps. Mounting it somewhere under /volume1 worked to give the syno access, but then it counted any data stored against the storage for volume1, which I suspected could lead to problems. I finally gave up and picked up a Buffalo LS441DE. It turned them into a raid for me, but now I have to connect via a much slower ethernet connection and backup with rsync. Since the hardware and processor on it are the same as other actual syno boxes, I may try hacking it into a syno box, after I find a better external raid USB enclosure that is cheap and fast (USB3) Please keep us posted if you try the method Frostiex suggested.

Just guessing based on the info you provided... There are several different things that could be happening, based on your description. more details of the step by step would be helpful to determine exactly which drive got unplugged from what and how and what it was plugged into and what order and how, etc. What order the reboots and re-syncs took place in, etc. Possibility 1 I think when you hot swapped the drives, the synology thought the drive was pulled and reinserted. Something went wrong where it should have sensed that the drive was different, and instead of acting accordingly, it thought the drive was somehow degraded. You repaired it. In the process, it could have seen that whatever it uses to identify the drive was different than expected, so it updated its information with the ID from your drive. Now, it thinks your drive is the original drive. I can't see an easy way out of this, except to completely reload the whole thing. Side note: When I upgraded my drives and had to expand, I think I may have needed to reboot after the re-sync before the possibility of expanding was available. Possibility 2 Your bios config is defaulting to boot from the wrong device. With everything in place as you want it to be when you are done, reboot and in the config for your bios, make sure the boot device is your USB stick. Side note: confirm the image on the USB stick is good by re-downloading. This step may not be necessary if your box will boot with it when the original drive is in place. This may not be helpful at all, but hopefully, it is a place to start or it gives you an idea where to look next.

Make sure you're logged in as 'root' and not 'admin'. If for some reason, vi is not in the path, try /bin/vi /path/to/file if that fails, get a copy of winscp (Assuming a windows PC) and use scp to access the file system and edit the files on your PC. Make sure it does not save the file with windows CR/LF end of lines. that could confuse anything attempting to read the file. if ssh scp fails to get you connected, you may have more issues with this unique image than you are aware of.