neXus

Tss bad mood for now... Forum is here to share idea and knowledges

In fact my release works fine but I think I will keep it for me for several reasons : 1/ syno put some verification so they don't want the dsm been installable on a cheaper system. 2/ if it spread on the internet as a ready to use release, syno will certainly add more check in next release. 3/ all on this thread give enough information to create your own working system. 4/ I don't recommend dsm for kiddies as update could break the system 5/ the kernel modification need to be included if they update the kernel and I don't want to be the maintainer. 6/ it's easy to create a Trojan horse release, with backdor in it, that's why I create my own release from scratch. As it's a borderline project, I suggest to only install code you can trust. So to sum up its great if you are familiar with Linux and understood all of the things in this thread. Dsm check can be defeated for the moment. I take responsibility on my own hardware if it failed, I never support this release for others. For a production usage, you should consider using openmediavault/freenas/openfiller. Maybe if I am in a good mood I will post my synoboot img used to install genuine pat files.

It's runs for about 48h on my brand new N54L. Installed from PAT, update done to latest. USB device protected by sinology mechanism (I can also change my boot kernel / parameter within the running system without breaking anything). I don't have any bios bad checksum issue (but I didn't played with the scheduled function or WOL). It works fine, but need more test. During my tests, I discover that other .cgi are doing some "device check test". When it occurs, you must recreate all block nodes described in /proc/partitions. I aslo experience some issue, where the volume crashed (but goes back after reboot). Or some issue regarding the monitor status regarding the network device (fixed by a reboot too). So it's not ready for production unless you are familiar with DSM internal to get through theses issues. I recommend stay on 4.2 for the moment.

Well it use a module in order to have direct memory access through the kernel. A binary is then used to fetch information and flash updates. It is "possible" but need a lot of work. I try to find a workaround... EDIT : As a workaround, let DSM download the files, go to /volume1/@smallupd@te_deb, un pack the flashupdate deb, replace updater with a shell script 'exit 0', repack, replace and push the button. I can easy be scriptable. The flashupdate is here to update synoboot, but we don't care. Note : it may break your DSM, I suggest you to try on a virtual machine before. I update from 3776 to 3776-3 and everything is working fine.

Yes same stage, it loads a module in order to flash the bios and fail. Edit : Monod is not needed for me a my USB stick is reconized as synoboot device.

Il faudrait que : Soit lacpi soit implémentée pour envoyer un proper shutdown au système Soit que l'action du bouton envoie un ordre via le port série ttyS1 Pas simple en somme Sur les syno tout est gèré via le port série apparemment, led et boutons via un contrôleur dédié. Contrôleur que nous n'avons pas sur le n54l. Par contre on doit pouvoir faire notre propre drivers n54l -> serial mais y'a du boulot....

The process use a dedicated module inside the PAT file, and also use /dev/mem... will be hard to fool. The updater process is also inside the PAT file.

Well, Dealing with autoupdates, it tries to update the bios (which failed), no idea if we can deal with as the updater process is in the PAT firmware downloaded. It means, upgrade may work with synoassistant or we need to strip some informations from PAT upgrades and feed the DSM with it...

http://www.synology.com/support/tutoria ... p?q_id=485

Booting on HDD is not possible as drives are parts of a raid array. I know why it failed my synoboot contains only one partition. I have to find the layout of a real synoboot and the contents. We don't have the source of the updates by the way. For the symlink issue it's weird as my volume is empty - fresh install - I will keep you posted.

Just remove the rmmod from linuxrc / updater.sh in the initrd do the same thing. I have something weird, It said the system volume has crashed, it is fixed by a reboot but sometimes it appears again... I found this weird thing in messages : storagehandler.cgi : raid_disk_create.c:88 failed to fopen /sys/block/md1/md/dev-sda2/slot, errno=Too many levels of symbolic links Is anyone already seen that in previous DSM ? (I can't tell DSM4.3 is the first one for me). NOTE : I try an upgrade to 3776.3 we will see EDIT 2 : woops Oct 15 21:12:22 DiskStation updater: updater.c:4197 The SynoBoot partitions exist. Oct 15 21:12:22 DiskStation updater: updater.c:2413 SYNORedBootUpdCheckAndApply(2413): Skip bootloader update, no uboot_do_upd.sh exists Oct 15 21:12:22 DiskStation updater: boot_lock.c(224): failed to mount boot device /dev/synoboot2 /tmp/bootmnt (errno:6) Oct 15 21:12:22 DiskStation updater: updater.c:4293 fail to unlock boot partition Oct 15 21:12:22 DiskStation updater: updater.c:4537 Failed to accomplish the update! (errno = 21) I will need to dig this one too.

So we are at the same state for now with maybe two different approach. Could be nice to discuss it in pm

ttyS1 simulation or just removed the unload line from linuxrc ?

I just added two more kernel parameters to pass pid/vid of a device considered as a "synoboot USB flash" device. No more synoboot erased and the stick doesn't appear either in file station or Storagemanager

It seems, I just installed surveillance station, Volumes are still here.