Schmill

Hi Kanedo, What version of XPenology are you running? I have followed your instructions above, changed the PID/VID on the syslinux.cfg file, and rebooted and sure enough the USB boot device is not visible anymore. However I also can't find it anywhere! Running the parted command gives me this: Disk /dev/sda: 3001GB Disk /dev/sdb: 3001GB Which is just my two physical internal disks, the USB boot device, and my external USB drive are not listed there. Checking for 'volume' directories gives me: ls -la / | grep volume drwxr-xr-x 19 root root 4096 Jun 11 22:08 volume1 drwxr-xr-x 2 root root 4096 Jun 11 22:06 volumeUSB1 drwxr-xr-x 3 root root 4096 Jun 11 22:08 volumeUSB2 volumeUSB2 has my external USB drive mounted on it, but there is nothing on volumeUSB1. Equally attempting to mount any of the 'synoboot' devices fails: DS001> mount -t vfat /dev/synoboot /volumeUSB1 mount: mounting /dev/synoboot on /volumeUSB1 failed: Invalid argument DS001> mount -t vfat /dev/synoboot1 /volumeUSB1 mount: mounting /dev/synoboot1 on /volumeUSB1 failed: Invalid argument DS001> mount -t vfat /dev/synoboot2 /volumeUSB1 mount: mounting /dev/synoboot2 on /volumeUSB1 failed: Invalid argument Any idea where my usb stick has gone? I am running DSM 5.1-5022 Update 5. Thanks

Hi What is the best way for me to speed test my usb3 backup drive? I am using the built in backup facility of xpenology but it seems to take a very long time despite the destination being usb3 and very little having changed on the server. Are the backups incremental or is it recopying everything every time? Tempted to try an rsync or something to test the drive transfer speed, but I'm not sure how exactly to do it so that the cpu / ram doesn't become the bottleneck (I am running on N54L bare metal) Any help / advice gratefully received - Thanks!

When you did the downgrade how did you do it? Is it possible the volume just didn't migrate properly? Also did you re-upgrade back to your original version after?

Does that not erase any attached drives?

Thanks - where did it come from?

Reply to bookmark - interested for the spreadsheet too

I know there are the usual warnings about making sure you have a backup etc, which I do, but... What is the correct process to upgrade from 5.0 4528 to 5.1 5022? I have the img for the USB, and the necessary PAT file, and I know I can install a completely new fresh system, but how do I do it on my live system, and not have the existing data completely wiped during the install? Thanks

AM1 ?

How do you use su? It is disable for all users due to permissions on busybox? I found that applying the usual 'workaround' of changing the permissions of the busybox directory then stopped the Plex client from installing / operating correctly. I didn't know that ipkg was discontinued though, so I'm interested to hear of alternatives. (Ipkg is what synology recommend for installing 'other' software I.e. That which isn't part of package manager)

These are my own 'HowTo' notes - so usual disclaimer "use at your own risk". Bare in mind that these are for the N54L, and the IPKG bootstrap that you download depends on what hardware you are running on, (see the wiki link in my last post to see which one you need). IPKG Installing IPKG The ipkg package installer is required in order to be able to install various software packages outside of Synology’s repository, in particular the sudo package, and nano if you want an alternative editor. Full instructions, for multiple platforms, are available HERE. Below are a condensed set of instructions, suitable for the N54L i686 platform. The files to install the ipkg are referred to as ‘bootstraps’. 1. Login via SSH as root. 2. Change to a temporary directory (e.g. /volume1/@tmp) 3. Download the bootstrap file to the NAS using the following command: wget http://ipkg.nslu2-linux.org/feeds/optware/syno-i686/cross/unstable/syno-i686-bootstrap_1.2-7_i686.xsh 4. Make the .xsh executable chmod +x syno-i686-bootstrap_1.2-7_i686.xsh 5. Run the .xsh script sh syno-i686-bootstrap_1.2-7_i686.xsh 6. After the script has finished it can be deleted rm syno-i686-bootstrap_1.2-7_i686.xsh 7. Use vi to edit /root/.profile vi /root/.profile With vi still in command mode enter the following and press return: :%s/PATH=/PATH=$PATH:/ 8. Press [Esc], then enter “:wq” to write and quit the file. 9. If you received an error that /opt cannot be mounted, unmount /opt umount –f /opt , and delete /opt and /volume1/opt. Using IPKG • Update the list of available packages with “ipkg update” • Upgrade any installed packages to their latest versions with “ipkg upgrade” • Install packages with “ipkg install xxxx” where xxxx is the name of the package. • List available packages with “ipkg list” (this can be filtered with “ipkg list | grep xxxx” where xxxx is the package you are looking for) sudo To install sudo you must first have installed IPKG. 1. As root install sudo ipkg install sudo 2. By default, only ‘root’ has the ability to use sudo. To allow others to sudo they must be added to the /opt/etc/sudoers file. However this file cannot be edited directly and must be edited using a specific utility, visudo. 3. Running visudo will open the sudoers file. 4. Towards the bottom of the file controls who can sudo: ## ## User privilege specification ## root ALL=(ALL) ALL ## Members of group 'administrators' can execute any command %administrators ALL=(ALL) ALL ## Uncomment to allow members of group wheel to execute any command # %wheel ALL=(ALL) ALL ## Same thing without a password # %wheel ALL=(ALL) NOPASSWD: ALL ## Uncomment to allow members of group sudo to execute any command # %sudo ALL=(ALL) ALL 5. Specific users can be added using the format: thisuser ALL=(ALL) ALL 6. Groups can be added using the format: %thisgroup ALL=(ALL) ALL One method is to add the ‘sudo’ group and allow all its members to sudo (last line of the main snippet above). However for my purposes allowing anyone of the ‘administrators’ group is suitable so I have added that in the above section. Once you have made the above changes, (and saved the file with [Esc]:wq) be sure to use SSH to log in as a user that should now be able to use the sudo command. If you disable root access and have not tested that this works, and then it does NOT work you will be stuffed – You have been warned! Good luck

I have my full set of notes elsewhere, I'll update this thread later with the content. In summary you have to apply the correct bootstrap script to add ipkg to the server (as per wiki article http://forum.synology.com/wiki/index.ph ... stall_ipkg ) You can then use ipkg to get & install sudo. More verbose instructions later - What hardware are you running on?

for me from logs you posted before it looked like problem with access rights then i asked about reinstall virtualbox. about icon, strange, icon could be in menu as usual Login with an admin user, and grant this user the right to VirtualBox ( Control-Panel -> Privilege ) Excellent thanks Well I logged in as my admin user "MyAdmin" and "Control Panel --> Privileges" did not list phpVirtualBox. I then re-activated the default Admin account, and then logged in with that, and "Control Panel --> Privileges" now DID list phpVirtualBox. I then added this to the "MyAdmin" account, logged out/in again, and "MyAdmin" now has the icon in the Main Menu So... is there any way that these privileges can be assigned at GROUP level, rather than USER level? I'd like to give all the "Administrators" group have privilege for this app, but I can't see anyway to do that? Thanks again

just says that now it is possible to install DSM5.1 on a DS*10 and higher. Before the update it was only possible to install on a DS*11 or higher. So how do you get DSM 5.1 update 2 onto a DS*10? You MUST surely be able to go DSM5.0 --> DSM5.1 update2, as the above seems to state that DSM5.1 (update1) would not install onto a DS*10, so you would not be able go DSM5.0 --> DSM5.1 --> DSM5.1 update2 on a DS*10 ?

It's an upgrade, so as long as there isn't a way to get the V5.1-5004 up and running it won't be possible to install the U2... It would seem that 5.1 update 2 can actually be installed onto a system running DSM5.x according to this German --> English translation snippet from the page linked to by martva:

Hmmm - cheers, your reply made me go back and recheck everything, and it seems as if the bios on the N54L has some preference to the external USB sockets. Setting the primary boot device to the internal stick, disabling the secondary boot device, and then altering the harddrive order (so that the usb stick came first) seems to have cracked it

Argh... Ok, so I am running XPEnology and nanoboot on the N54L microserver. I have a USB stick inserted in the internal USB socket and all works well - usually... However today I was away from home and needed to reboot the server, which I did... forgetting that I ALSO had an external USB drive connected to the server. It seems that this then stops the server from booting Is there ANY way to set the bios / server to ONLY use the internal socket as a boot device, and to NOT try and boot from external USB sockets?

Under DSM: Control Panel -> Notification -> Push Service there are various options for sending the status of the server to recipients. I have tried to use them but always receive an error of "Failed to forward DiskStation information to push service server". /var/log/messages then shows: Dec 1 17:07:26 DS001 entry.cgi_SYNO.Core.Notification.Push.Conf[1].status[26083]: pushservice_update_ds_token.c:60 synocloudserviceauth failed(1): failed to get a api key Dec 1 17:07:26 DS001 entry.cgi_SYNO.Core.Notification.Push.Conf[1].status[26083]: pushservice_update_ds_token.c:179 Can't set api key Dec 1 17:07:26 DS001 entry.cgi_SYNO.Core.Notification.Push.Conf[1].status[26083]: pushservice_utils.c:338 SYNOPushserviceUpdateDsToken failed. Dec 1 17:07:26 DS001 entry.cgi_SYNO.Core.Notification.Push.Conf[1].status[26083]: pushservice_utils.c:397 GenerateDsToken Failed Dec 1 17:07:26 DS001 entry.cgi_SYNO.Core.Notification.Push.Conf[1].status[26083]: Failed to get ds token. Dec 1 17:07:27 DS001 entry.cgi_SYNO.Core.Notification.Push.Conf[1].set[26110]: pushservice_update_ds_token.c:60 synocloudserviceauth failed(1): failed to get a api key Dec 1 17:07:27 DS001 entry.cgi_SYNO.Core.Notification.Push.Conf[1].set[26110]: pushservice_update_ds_token.c:179 Can't set api key Dec 1 17:07:27 DS001 entry.cgi_SYNO.Core.Notification.Push.Conf[1].set[26110]: pushservice_utils.c:338 SYNOPushserviceUpdateDsToken failed. Dec 1 17:07:27 DS001 entry.cgi_SYNO.Core.Notification.Push.Conf[1].set[26110]: pushservice_utils.c:397 GenerateDsToken Failed Dec 1 17:07:27 DS001 entry.cgi_SYNO.Core.Notification.Push.Conf[1].set[26110]: Failed to get ds token. Does the push service work when using XPEnology? If so how do I get this to work? Thanks!

Re-installed virtualbox and the problem is gone... strange! As an aside, does anyone know VirtualBox doesn't show up in the "Main Menu" in DSM? It looks like the config file says it should, but I get no icon, I have to go to package manager and click the link, or else just go to the url directly. Not a major issue, I just wondered why the icon wasn't showing in the "Main Menu"? Thanks

I recently was introduced to the phpVirtualBox package for the the N54L too, and its quite handy. I run my server baremetal, but anything I want to 'try' I now have a 'virtual' N54L DSM in phpVirtualBox that I can test stuff on, take snapshots of, break, restore, fix, experiment, and then when I am happy I know what I have done, THEN I perform it on the bare-metal host. Not sure if it is what you are looking for or not, but I found it very helpful for determining what was causing me problems when installing certain packages - primarily because of the ease of taking a snapshot before an install, and knowing that by restoring the snapshot you could return the system to EXACTLY how it was before hand, rather than just having to perform an uninstall

Not to worry, all sorted now

Can anyone give me some pointers on how to add "sudo" functionality to my xpenology running on N54L please? I would like to disable the 'root' user, but no other user can use the 'su' command, hence my requirement for sudo. I was trying to follow this article (http://nas.deadcode.net/2009/08/26/inst ... skstation/) but it requires that you use ipkg, which again Synology does not have. How do I either install ipkg, or if there is a better way to get 'sudo' - how do I do that? Many thanks

Cheers but I have no choice in the matter... From my pc I navigate to "http://192.168.22.10/phpvirtualbox/", or indeed the name of my server rather than the IP - it makes no difference. Then I am presented with phpVirtualBox error box; The subsequent dialog box says: Clicking the 'details' option on the dialog shows: Exception Object ( [message:protected] => Could not connect to host (http://127.0.0.1:18083) [string:Exception:private] => [code:protected] => 64 [file:protected] => /volume1/web/phpvirtualbox/lib/vboxconnector.php [line:protected] => 210 [trace:Exception:private] => Array ( [0] => Array ( [file] => /volume1/web/phpvirtualbox/lib/vboxconnector.php [line] => 3100 [function] => connect [class] => vboxconnector [type] => -> [args] => Array ( ) ) [1] => Array ( [file] => /volume1/web/phpvirtualbox/lib/vboxconnector.php [line] => 928 [function] => remote_vboxGetGuestOSTypes [class] => vboxconnector [type] => -> [args] => Array ( [0] => Array ( [fn] => vboxGetGuestOSTypes ) ) ) [2] => Array ( [file] => /volume1/web/phpvirtualbox/lib/ajax.php [line] => 309 [function] => __call [class] => vboxconnector [type] => -> [args] => Array ( [0] => vboxGetGuestOSTypes [1] => Array ( [0] => Array ( [fn] => vboxGetGuestOSTypes ) [1] => Array ( [0] => Array ( [data] => Array ( [responseData] => Array ( ) ) [errors] => Array ( ) [persist] => Array ( ) [messages] => Array ( ) ) ) ) ) ) [3] => Array ( [file] => /volume1/web/phpvirtualbox/lib/ajax.php [line] => 309 [function] => vboxGetGuestOSTypes [class] => vboxconnector [type] => -> [args] => Array ( [0] => Array ( [fn] => vboxGetGuestOSTypes ) [1] => Array ( [0] => Array ( [data] => Array ( [responseData] => Array ( ) ) [errors] => Array ( ) [persist] => Array ( ) [messages] => Array ( ) ) ) ) ) ) [previous:Exception:private] => ) Location:http://127.0.0.1:18083

Cheers Diverge - see above, I think it was VirtualBox being a pain... - Thanks

Argh - 1 reboot of the host later and now I'm getting this message again:

I think I've fixed the above issue - seems that virtualbox defaults to creating the VM's under /root, which fills up the system pretty darn quick. Moving the VMs out to one of my volumes seems to have solved it ( viewtopic.php?p=27400#p27400 )