ssiril

Hi, What configuration have you done in the vSwitch ? Regards, C.G.

Does not work on vmware esxi for me also (no disk detected) follow my guide it works fine. http://cyanlabs.co.uk/tutorials/synolog ... o-nanoboot MAKE SURE TO FOLLOW IT EXACTLY My bad, haven't seen your guide before posting my reply. What are the changes made in the .pat file ? C.G.

Does not work on vmware esxi for me also (no disk detected)

I don't know, I'm not aware of that, I joined xpenology community with my first try with your beta 5.0 repack I beleive gnoboot included it but maybe 4482 has a workaround for the fix ...

lspci does matter for responsiveness of the web ui. Everytime you load the interface, some cgi script tries to issue those commands : sh -c /usr/syno/bin/lspci | grep "111d:806e" sh -c /usr/syno/bin/lspci | grep "11ab:7042" The script (or binary) does that to verify that "genuine" pci devices are present. 11ab:7042 is Marvell kirkwood sata controler (sata_mv linux driver) 111d:806e seems to be an idt audio pci chipset. I've done a "stupid patch" : cd /usr/syno/bin/ mv lspci lspci.real cat > lspci #/bin/bash /usr/syno/bin/lspci.real "$@" echo "02:01.0 Class 0200: Device 111d:806e (rev 01)" echo "02:02.0 Class 0200: Device 11ab:7042 (rev 01)" chmod +x lspci ... And the interface responsiveness is smooth again. But the system still destroys /dev/sd* C.G.

Hi Yabba, Happy to see that my post about rndu 4000 made some people happy Do you mean that you installed the real dsm-50 4482 pat file from synology or the one I packed up this morning ? Regards, C.G.

Please give feedback on this thread, everything could help us remove this security lock

I totally agree with you, my repack is a proof of concept I'm asking myself if the check method is not embedded in a system/syno library. It's kind of stange to see lspci being modified as it is a standard linux program. You should not even imagine install this pat file over your actual working xpenology. I've packed this up for test purpose only. It does not instal from Synology assistant, it does only install from web ui installer after booting with "gnoboot_me=5.0-4482". However, as far as I have seen, there are no major end user benefit update in this release. My work on 4482 aims to help install future version easily. C.G.

Great job ! Here is a link to a repacked version of 4482 pat file. On grub boot menu hit "c" and then kernel /zImage gnoboot_me=5.0-4482 boot Then install with this pat file : https://mega.co.nz/#!1AMjnByB!obF8MVtkYTmxK34fS8VWy7LmersHdHYLEDrvteBBQ6I So far, it's ok for me. Regards, C.G.

So even after replacing /usr/syno/* with 4458 volumes get unmounted after a while ? To be more precise, replacing files in : /usr/syno/bin /usr/syno/synoman/webman/ And the system is stable and running as expected even after reboot (from web ui and shell). I've checked modules in /usr/syno/synoman/webman/modules but they does not seem to be implied. After more than 1 hour running, everything is working properly. C.G.

How do you find this ? What are the files ? Does this files can be patched like the synobios ? Hi Trantor, Hi all, I've taken some time to compare 4458 & 4482, here are the results : - The startup scripts in etc & etc defaults seems to be almost the same for most of them. - Scripts and executables in /usr/syno are very different for some. After some experiment, I've decided to replace the whole /usr/syno of 4482 with 4458 and ... it works. I agree, it it not a good solution. But, it shows that kernel (and synobios, but not sure) might not be the problem but a script of program within /usr/syno .. After further test, I've seen that replacing /usr/syno/hotplug of 4458 by 4482 was temporarily solving the problem. After reboot I've had to recreate /dev/sd* with mknod but the system was pretty ok. The main fact is that a periodic program or script is deleting /dev/sd* files. I've also checked that system crontabs where not deleting /dev/sd* files Hope this will help, will be glad also to help solve this problem. Regard, C.G.

Hi there, Here are the results of my investigation around 4482. After some research here and there, I've seen an old error seen before with esata drives : Failed to open /dev/sdc, errno=No such file or directory /sys/block/sdc/device/../../scsi_host/host*/proc_name It seems that 4482 uses different drivers (or sysfs implementation). When manually rebuilding devices files with mknod, it is possibilie to fdisk it but it's deleted again by some script around /usr/syno/bin/scemd C.G.

Hi there, I've tried of a fresh new install and this is the same problem. I think that it comes from sata/sas/ide drivers included in gnoboot that does not show hardware as the 4482 need them to be. /dev/ does not have any "sd" or "hd" device, this could mean that the post init script that does build hard disks does not communicate correctly with the gnoboot kernel. C.G.

interested : You're right about the fan noise, but it's easy to solve that with few shell tricks : ipkg install mktemp ipkg install lm-sensors Then you issue : sensors It should read something like : coretemp-isa-0000 Adapter: ISA adapter Core 0: +37.0°C (crit = +100.0°C) it8721-isa-0a10 Adapter: ISA adapter in0: +3.06 V (min = +2.20 V, max = +3.06 V) ALARM in1: +2.86 V (min = +0.00 V, max = +2.08 V) ALARM in2: +2.22 V (min = +2.12 V, max = +1.42 V) ALARM +3.3V: +3.34 V (min = +2.69 V, max = +4.01 V) in4: +2.76 V (min = +2.05 V, max = +1.91 V) ALARM in5: +1.16 V (min = +1.46 V, max = +1.40 V) ALARM in6: +2.80 V (min = +0.08 V, max = +1.52 V) ALARM 3VSB: +3.29 V (min = +5.93 V, max = +6.05 V) ALARM Vbat: +3.31 V fan1: 2033 RPM (min = 10 RPM) fan2: 0 RPM (min = 14 RPM) ALARM temp1: +49.0°C (low = +112.0°C, high = -5.0°C) ALARM sensor = thermal diode temp2: +33.0°C (low = -53.0°C, high = +61.0°C) sensor = thermal diode temp3: -128.0°C (low = +79.0°C, high = -7.0°C) sensor = disabled intrusion0: ALARM Then you issue : sensors -s It will build default config files. After that you can config the pwm behavior with : pwmconfig It does build a /etc/fancontrol like this : # Configuration file generated by pwmconfig, changes will be lost INTERVAL=2 DEVPATH=hwmon0= hwmon1= DEVNAME=hwmon0=coretemp hwmon1=it8721 FCTEMPS=hwmon1/device/pwm1=hwmon0/device/temp2_input FCFANS= hwmon1/device/pwm1=hwmon1/device/fan1_input MINTEMP=hwmon1/device/pwm1=20 MAXTEMP=hwmon1/device/pwm1=60 MINSTART=hwmon1/device/pwm1=8 MINSTOP=hwmon1/device/pwm1=10 MINPWM=hwmon1/device/pwm1=10 MAXPWM=hwmon1/device/pwm1=165 Then you create a startup script for fancontrol : /usr/syno/etc/rc.d/S99fancontrol.sh #!/bin/sh # # S99fancontrol.sh - startup script for fancontrol # # This goes in /usr/syno/etc/rc.d and gets run at boot-time. FANCONTROL=/opt/sbin/fancontrol case "$1" in start) if [ -x "$FANCONTROL" ] ; then echo "start fancontrol" $FANCONTROL & fi ;; stop) echo "stop fancontrol" kill -TERM `cat /var/run/fancontrol.pid` > /dev/null 2>&1 logger -p daemon.error "$0 stop fancontrol" sleep 1 ;; *) echo "usage: $0 { start | stop }" >&2 exit 1 ;; esac then you do chmod 755 /usr/syno/etc/rc.d/S99fancontrol.sh After a reboot you will enjoy the sound of silence, the system will automaticaly regulate the fan speed ! Concerning the front display, which is the top most useless functionnality imo, I've.... unplugged it ! When you remove the right side cover of your nas you will see a ribbon cable, just unplug it... C.G.

squallef The hardware is Netgear Readynas Ultra 4 (RNDU 4000) Atom D410 1,6 Ghz (Single core) This processor does have a full 64 bit support. 2 gb ram (so-dimm ddr2 ) 4 disks... It is not the weakest processor at all but not powerfull also. But the system and plex are running fairly well. Regarding Asustor, if you have the hability to boot from external usb (usb key, cd or dvd...) or to have a bios access to change the boot order (some nas does have internal vga header) it might be possible to install xpenology. Once you've boot the system, the biggest part is done C.G.