ssiril
-
Posts
16 -
Joined
-
Last visited
Posts posted by ssiril
-
-
Unfortunally nanoboot don't work on my Readynas Pro 2
so I must stay for gnoboot kernel.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.
-
Unfortunally nanoboot don't work on my Readynas Pro 2
so I must stay for gnoboot kernel.Does not work on vmware esxi for me also (no disk detected)
-
Strange because both 111d:806e and 11ab:7042 are present in the k3dt pci devices fix that fool the 4.3 protection.
Does your system have the pci devices fix ?
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 ...
-
No need to replace "lspci", no different in 4458 and 4482.
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.
-
tgz archive method works !
to add an entry in the menu. lst is only needed to install the new version, after you can delete this entry
And now my readynas pro synomod work under dsm5.0-4482 !
Don't try use patched .pat files is no't work !
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.
-
apologies. this is my N54L test box.tested on GA-C847N motherboard using above method,... seems to be fine till now. Will update once i see any issue
thanks guys!
Please give feedback on this thread, everything could help us remove this security lock
-
Good news.
But I agree with Vortex it's not a clean method.
We must find what kind of checks these files do.
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.
Just to clarify can you please post the exact steps to upgradefrom DSM 5.0-4458 Update 2 to to DSM 5.0-4482 please.
also what must we update on GnoBoot. or is it the same usual method after editing grub..?
Thanks For The Great Work Guys..
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.
-
To be even more precise, replace only these files:
/usr/syno/synoman/webman/uistrings.cgi
/usr/syno/synoman/webman/usersettings.cgi
/usr/syno/synoman/webman/initdata.cgi
/usr/syno/synoman/webman/modules/SystemInfoApp/LogViewer.cgi
/usr/syno/synoman/webman/modules/PollingTask/polling.cgi
/usr/syno/synoman/webman/modules/DSMNotify/dsmnotify.cgi
/usr/syno/synoman/webman/modules/PkgManApp/PkgSynoMan.cgi
/usr/syno/synoman/webman/modules/PkgManApp/PkgMan.cgi
/usr/syno/synoman/webman/modules/StorageManager/volumehandler.cgi
/usr/syno/synoman/webman/modules/StorageManager/storagehandler.cgi
/usr/syno/bin/lspci
/usr/syno/bin/scemd
/usr/syno/bin/findhostd
But I find this method is awful.
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.
-
After some experiment, I've decided to replace the whole /usr/syno of 4482 with 4458 and ... it works.
The main fact is that a periodic program or script is deleting /dev/sd* files.
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.
-
You must use 3.2.40 (bromolow) sources to get dsm 5.0 working.
You can use 4458 sources to build a kernel for the 4482 version.
Protection is in the /usr/syno/bin/scemd (and some other files), which sources will not be published.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 ;; esacthen 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.
-
Hi there,
I'm following for few month now this fantastic project, and it's time for me today to bring contribution.
For 3 months now, I'm testing xpenology both with trantor boot and gnoboot.
Seeing it's really reliable I decided to build a home made nas with motherboard and disks, migrating data from my old netgeat readynas rndu 4000.
IMO, this is a fine piece of hardware, as it always is with netgear but the software, downside is pure crap.
After a first try with readynas OS 6.1.6 with has been ported to older hardware by community, I was steel unsatisfied, less but still crappy.
So I thought ... why not try to install xpenology huh ?
Well It was not easy at first look. This little nas does have all the attributes of a standard computer ... motherboard, bios, ram, x86 atom... but no vga (there is a vga header I beleive, but unsoldered)
Well It's possible to boot from external usb key however.
So I made usb boot key with trantor kernel and pluged it in the front usb port and a keyboard in the top back usb port.
Booting with "backup" button pressed, well, this is not readynas os booting here, nothing on the lcd screen of the nas.
Pressing "enter" and then ran to my computer and starting Synology assistant.... Nothing !... no wait ! after 2 minutes, the nas showed up !
So I started an installation on DSM 5.0 beta.... after pre-install, I booted again the nas with backup button pressed and ... voilà ! The nas was up with xpenology on it.
This was not hard but not really reliable to have to press this button on every boot.
So I ssh'd the nas and saw that 2 usb storages where there. The netgear (125mb) and my boot key.
So I decided to backup the netgear (to have the possibility to rollback to readynas os)
dd if=/dev/sdu of=some_file_name
And then I overwrote the boot with the xpenology boot img :
dd if=synoboot-5-beta.img of=/dev/sdu
Reboot and .... you definitively have a xpenology nas
After that, I've done the same with gnoboot latest version "gnoboot-alpha10.3-vfat.img".
It's a bit tricky for install because you do not have a display but ..
"Down arrow", (wait 3 secs.) then "Enter"
Wait for 2-3 mins and then your nas shows up in Synology Assistant. You can now upgrade to DSM 5 final.
You can flash the internal usb storage with gnoboot img file, it works fine.
Hope it will please some old users of readynas nas which are like me, appreciate their hardware and hate their software
C.G.
How about 802.3ad in vmware
in Archives
Posted
Hi,
What configuration have you done in the vSwitch ?
Regards,
C.G.