Jump to content
XPEnology Community

NEW DSM 5.1-5004 AVAILABLE !!


Recommended Posts

For a pre-holiday special I've committed a fix for the synobios issue in my build. Big shout outs to kalimero for checking my patch work and providing the fix. There is a new step involved in the build process, so make sure you check the script outputs before building.

 

kalimero has also provided some output from his patch which indicates that there is still a problem with mounting volumes. See below:

 

Jan  1 00:00:02 syslog: format start, szBuf = ^R4VxSYNONI^A^D^A
Jan  1 00:00:02 syslog: ninstaller.c:695 Dev: sda, DiskPath: /dev/sda, Partition version: 8
Jan  1 00:00:02 syslog: ninstaller.c:194 Mount partion /dev/md0 /tmpRoot
Jan  1 00:00:02 syslog: ninstaller.c:548 failed to get upnpmodelname from [/tmpRoot/etc.defaults/synoinfo.conf].
Jan  1 00:00:02 syslog: ninstaller.c:555 failed to get buildnumber from [/tmpRoot/etc.defaults/VERSION].
Jan  1 00:00:02 syslog: ../libsynosdk/lib/system/system_platform_get.c:35 failed to get unique from /tmpRoot/etc.defaults/synoinfo.conf errno=[0x0900]
Jan  1 00:00:02 syslog: ninstaller.c:571 failed to get platform from [/tmpRoot/etc.defaults/synoinfo.conf].
Jan  1 00:00:02 syslog: ../libsynosdk/lib/system/system_max_align_get.c:85 [/tmpRoot/.system_info/pgsql_alignment] doesn't exist, check model name for alignment
Jan  1 00:00:02 syslog: ../libsynosdk/lib/system/system_endian_get.c:61 [/tmpRoot/.system_info/endian] doesn't exist, check model name for endian
Jan  1 00:00:02 syslog: ../libsynosdk/lib/system/system_bit_get.c:57 [/tmpRoot/.system_info/bits] doesn't exist, check model name for bits
Jan  1 00:00:02 syslog: ninstaller.c:757 fail to read [unique] from [/tmpRoot//etc.defaults/synoinfo.conf]
Jan  1 00:00:02 syslog: ninstaller.c:851 unique not match
Jan  1 00:00:02 syslog: ninstaller.c:1308 SYSTEM_NORMAL, [Recoverable=0]
Jan  1 00:00:02 syslog: ninstaller.c:223 umount partion /tmpRoot
Jan  1 00:00:02 syslog: ninstaller.c:1246(FillUpgradeVolumeInfo): gszUpgradeVolDev = /dev/md0 
Jan  1 00:00:02 syslog: ninstaller.c:1247(FillUpgradeVolumeInfo): gszUpgradeVolMnt = /tmpData 
Jan  1 00:00:02 syslog: ninstaller.c:1324 gblSupportRaid: 1, gSysStatus: 1, gblCreateDataVol: 0, gblSystemRecoverable: 0
Jan  1 00:00:02 syslog: ninstaller.c:2236 CreateDataVol=[0]
Jan  1 00:00:02 syslog: ninstaller.c:223 umount partion /tmpData
Jan  1 00:00:02 syslog: ninstaller.c:2351(ErrFHOSTDoFdiskFormat) retv=[0]
Jan  1 00:00:02 syslog: ErrFHOSTTcpResponseCmd: cmd=[2], ulErr=[0]
Jan  1 00:00:02 syslog: query prog, szBuf = ^R4VxSYNONI^A^D^A
Jan  1 00:00:02 syslog: ninstaller.c:2127(ErrFHOSTUpdateMkfsProgress) gInstallStage=[3] ret:0
Jan  1 00:00:02 syslog: index=[0], ulRate=[101]
Jan  1 00:00:02 kernel: [  208.554490] EXT4-fs (md0): barriers disabled
Jan  1 00:00:02 kernel: [  208.554789] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: 
Jan  1 00:00:02 syslog: ninstaller.c:194 Mount partion /dev/md0 /tmpRoot
Jan  1 00:00:02 syslog: ninstaller.c:2260 /bin/echo 0 > /tmpRoot/.upgrade_vol
Jan  1 00:00:02 kernel: [  208.562529] EXT4-fs (md0): barriers disabled
Jan  1 00:00:02 kernel: [  208.562820] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: 
Jan  1 00:00:02 syslog: ninstaller.c:223 umount partion /tmpRoot
Jan  1 00:00:02 syslog: ninstaller.c:2346 retv=[0]
Jan  1 00:00:04 syslog: query prog, szBuf = ^R4VxSYNONI^A^D^A
Jan  1 00:00:04 syslog: ninstaller.c:2127(ErrFHOSTUpdateMkfsProgress) gInstallStage=[3] ret:0
Jan  1 00:00:04 syslog: ninstaller.c:2164(ErrFHOSTUpdateMkfsProgress) gInstallStage=[3] , process=[/dev/md0]
Jan  1 00:00:04 syslog: ninstaller.c:2168(ErrFHOSTUpdateMkfsProgress) switch to PROG_FORMAT_DATA 
Jan  1 00:00:04 syslog: ninstaller.c:2127(ErrFHOSTUpdateMkfsProgress) gInstallStage=[4] ret:0
Jan  1 00:00:04 syslog: ninstaller.c:2202(ErrFHOSTUpdateMkfsProgress) skip format data volume...
Jan  1 00:00:04 syslog: index=[1], ulRate=[100]
Jan  1 00:00:06 syslog: query prog, szBuf = ^R4VxSYNONI^A^D^A
Jan  1 00:00:06 syslog: ninstaller.c:2127(ErrFHOSTUpdateMkfsProgress) gInstallStage=[4] ret:0
Jan  1 00:00:06 syslog: ninstaller.c:2202(ErrFHOSTUpdateMkfsProgress) skip format data volume...
Jan  1 00:00:06 syslog: index=[1], ulRate=[100]
Jan  1 00:00:08 syslog: pat start, szBuf = ^R4VxSYNONI^A^D^A
Jan  1 00:00:08 syslog: ninstaller.c:194 Mount partion /dev/md0 /tmpData
Jan  1 00:00:08 kernel: [  214.534618] EXT4-fs (md0): barriers disabled
Jan  1 00:00:08 syslog: ninstaller.c:1527(ErrFHOSTReceiveUpgradeFile): szUpgradeFile = /tmpData//upd@te.pat 
Jan  1 00:00:08 kernel: [  214.535893] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: 
Jan  1 00:00:13 syslog: ninstaller.c:1558(ErrFHOSTReceiveUpgradeFile) cRead=[4], ulFileSize=[185866240]
Jan  1 00:00:13 syslog: ErrFHOSTTcpResponseCmd: cmd=[5], ulErr=[0]
Jan  1 00:00:13 syslog: Starting ErrFHOSTDoUpgrade()...
Jan  1 00:00:13 syslog: ErrFHOSTTcpResponseCmd: cmd=[5], ulErr=[0]
Jan  1 00:00:13 syslog: ErrFHOSTTcpResponseCmd: cmd=[5], ulErr=[0]
Jan  1 00:00:13 syslog: ninstaller.c:2412(ErrFHOSTDoUpgrade) retv=[0]
Jan  1 00:00:13 syslog: ErrFHOSTDoUpgrade() Done
Jan  1 00:00:13 syslog: Remove /tmpData/upd@te...cmd=[/bin/rm -rf /tmpData/upd@te > /dev/null 2>&1]
Jan  1 00:00:13 syslog: Create /tmpData/upd@te...cmd=[/bin/mkdir -p /tmpData/upd@te > /dev/null 2>&1]
Jan  1 00:00:13 syslog: Untar /tmpData/upd@te.pat...cmd=[/bin/tar xpf "/tmpData/upd@te.pat" -C /tmpData/upd@te > /dev/null 2>&1]
Jan  1 00:00:13 syslog: query prog, szBuf = ^R4VxSYNONI^A^D^A
Jan  1 00:00:13 syslog: alz=[0], prg=[0], cfg=[0], retv=[0]
Jan  1 00:00:14 syslog: Verify checksum of [/tmpData/upd@te]...
Jan  1 00:00:14 syslog: Pass checksum of /tmpData/upd@te...
Jan  1 00:00:14 syslog: ErrFHOSTTcpResponseCmd: cmd=[5], ulErr=[0]
Jan  1 00:00:14 syslog: ninstaller.c:516 ullPATReqKBytes=[620212]
Jan  1 00:00:14 updater: updater.c:5011 Start of the updater...
Jan  1 00:00:14 updater: updater.c:5120 This is X86 platform
Jan  1 00:00:14 updater: updater.c:5123 ==== Start flash update ====
Jan  1 00:00:14 updater: boot/boot_lock.c(225): failed to mount boot device /dev/synoboot2 /tmp/bootmnt (errno:6)
Jan  1 00:00:14 updater: updater.c:4945 Failed to mount boot partition
Jan  1 00:00:14 updater: updater.c:5711 Failed to accomplish the update! (errno = 2)
Jan  1 00:00:14 syslog: ninstaller.c:1751 Executing [/tmpData/upd@te/updater -v /tmpData -x > /dev/null 2>&1] error[2]
Jan  1 00:00:14 syslog: ninstaller.c:194 Mount partion /dev/md0 /tmpRoot
Jan  1 00:00:14 syslog: ninstaller.c:1720 Moving updater for configuration upgrade...cmd=[/bin/mv -f /tmpData/upd@te/updater /tmpRoot/.updater > /dev/null 2>&1]
Jan  1 00:00:14 syslog: ninstaller.c:223 umount partion /tmpRoot
Jan  1 00:00:14 syslog: ErrFHOSTCleanPatchDirFile: After updating /tmpData/upd@te...cmd=[/bin/rm -rf /tmpData/upd@te > /dev/null 2>&1]
Jan  1 00:00:14 syslog: ErrFHOSTCleanPatchDirFile: Remove /tmpData/upd@te.pat...
Jan  1 00:00:14 syslog: ErrFHOSTDoUpgrade(2396): child process failed, retv=-2
Jan  1 00:00:14 syslog: ninstaller.c:2404(ErrFHOSTDoUpgrade) err=[-1]
Jan  1 00:00:15 syslog: query prog, szBuf = ^R4VxSYNONI^A^D^A
Jan  1 00:00:15 syslog: alz=[0], prg=[0], cfg=[0], retv=[-2]
Jan  1 00:00:15 syslog: ninstaller.c:1841(ErrFHOSTUpdaterProgress) retv=-2
Jan  1 00:00:17 syslog: query prog, szBuf = ^R4VxSYNONI^A^D^A
Jan  1 00:00:17 syslog: alz=[0], prg=[0], cfg=[0], retv=[-2]
Jan  1 00:00:17 syslog: ninstaller.c:1841(ErrFHOSTUpdaterProgress) retv=-2
Jan  1 00:00:17 syslog: ninstaller.c:1361(ErrFHOSTNetInstaller) read socket fail, ret=[0], errno=[10]
Jan  1 00:00:17 syslog: ninstaller.c:1443(ErrFHOSTNetInstaller) retSel=[1] err=(10)[No child processes]
Jan  1 00:00:17 syslog: ninstaller.c:1458(ErrFHOSTNetInstaller)
Jan  1 00:00:17 syslog: Return from TcpServer()

 

For some reason synoboot2 is failing to mount, which seems to be causing the update process to fail.

 

Heres the github repository again: https://github.com/Jman420/nanoBoot-DSM5.1

Link to comment
Share on other sites

The new seagate 8TB drives (archive series) is it supported with the new 5.1 XPEnology;

 

They aren't in the compatibility list of hard drives on the synology site.

 

what about hp microserver n54L with these SEAGATE 8tb drives and XPEnology?

Will it work?

 

Thanks

Link to comment
Share on other sites

The new seagate 8TB drives (archive series) is it supported with the new 5.1 XPEnology;

 

They aren't in the compatibility list of hard drives on the synology site.

 

what about hp microserver n54L with these SEAGATE 8tb drives and XPEnology?

Will it work?

 

Thanks

It will not work as there is no DSM 5.1 xpenology edition as of now.

Link to comment
Share on other sites

For a pre-holiday special I've committed a fix for the synobios issue in my build. Big shout outs to kalimero for checking my patch work and providing the fix. There is a new step involved in the build process, so make sure you check the script outputs before building.

 

kalimero has also provided some output from his patch which indicates that there is still a problem with mounting volumes. See below:

 

Jan  1 00:00:02 syslog: format start, szBuf = ^R4VxSYNONI^A^D^A
Jan  1 00:00:02 syslog: ninstaller.c:695 Dev: sda, DiskPath: /dev/sda, Partition version: 8
Jan  1 00:00:02 syslog: ninstaller.c:194 Mount partion /dev/md0 /tmpRoot
Jan  1 00:00:02 syslog: ninstaller.c:548 failed to get upnpmodelname from [/tmpRoot/etc.defaults/synoinfo.conf].
Jan  1 00:00:02 syslog: ninstaller.c:555 failed to get buildnumber from [/tmpRoot/etc.defaults/VERSION].
Jan  1 00:00:02 syslog: ../libsynosdk/lib/system/system_platform_get.c:35 failed to get unique from /tmpRoot/etc.defaults/synoinfo.conf errno=[0x0900]
Jan  1 00:00:02 syslog: ninstaller.c:571 failed to get platform from [/tmpRoot/etc.defaults/synoinfo.conf].
Jan  1 00:00:02 syslog: ../libsynosdk/lib/system/system_max_align_get.c:85 [/tmpRoot/.system_info/pgsql_alignment] doesn't exist, check model name for alignment
Jan  1 00:00:02 syslog: ../libsynosdk/lib/system/system_endian_get.c:61 [/tmpRoot/.system_info/endian] doesn't exist, check model name for endian
Jan  1 00:00:02 syslog: ../libsynosdk/lib/system/system_bit_get.c:57 [/tmpRoot/.system_info/bits] doesn't exist, check model name for bits
Jan  1 00:00:02 syslog: ninstaller.c:757 fail to read [unique] from [/tmpRoot//etc.defaults/synoinfo.conf]
Jan  1 00:00:02 syslog: ninstaller.c:851 unique not match
Jan  1 00:00:02 syslog: ninstaller.c:1308 SYSTEM_NORMAL, [Recoverable=0]
Jan  1 00:00:02 syslog: ninstaller.c:223 umount partion /tmpRoot
Jan  1 00:00:02 syslog: ninstaller.c:1246(FillUpgradeVolumeInfo): gszUpgradeVolDev = /dev/md0 
Jan  1 00:00:02 syslog: ninstaller.c:1247(FillUpgradeVolumeInfo): gszUpgradeVolMnt = /tmpData 
Jan  1 00:00:02 syslog: ninstaller.c:1324 gblSupportRaid: 1, gSysStatus: 1, gblCreateDataVol: 0, gblSystemRecoverable: 0
Jan  1 00:00:02 syslog: ninstaller.c:2236 CreateDataVol=[0]
Jan  1 00:00:02 syslog: ninstaller.c:223 umount partion /tmpData
Jan  1 00:00:02 syslog: ninstaller.c:2351(ErrFHOSTDoFdiskFormat) retv=[0]
Jan  1 00:00:02 syslog: ErrFHOSTTcpResponseCmd: cmd=[2], ulErr=[0]
Jan  1 00:00:02 syslog: query prog, szBuf = ^R4VxSYNONI^A^D^A
Jan  1 00:00:02 syslog: ninstaller.c:2127(ErrFHOSTUpdateMkfsProgress) gInstallStage=[3] ret:0
Jan  1 00:00:02 syslog: index=[0], ulRate=[101]
Jan  1 00:00:02 kernel: [  208.554490] EXT4-fs (md0): barriers disabled
Jan  1 00:00:02 kernel: [  208.554789] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: 
Jan  1 00:00:02 syslog: ninstaller.c:194 Mount partion /dev/md0 /tmpRoot
Jan  1 00:00:02 syslog: ninstaller.c:2260 /bin/echo 0 > /tmpRoot/.upgrade_vol
Jan  1 00:00:02 kernel: [  208.562529] EXT4-fs (md0): barriers disabled
Jan  1 00:00:02 kernel: [  208.562820] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: 
Jan  1 00:00:02 syslog: ninstaller.c:223 umount partion /tmpRoot
Jan  1 00:00:02 syslog: ninstaller.c:2346 retv=[0]
Jan  1 00:00:04 syslog: query prog, szBuf = ^R4VxSYNONI^A^D^A
Jan  1 00:00:04 syslog: ninstaller.c:2127(ErrFHOSTUpdateMkfsProgress) gInstallStage=[3] ret:0
Jan  1 00:00:04 syslog: ninstaller.c:2164(ErrFHOSTUpdateMkfsProgress) gInstallStage=[3] , process=[/dev/md0]
Jan  1 00:00:04 syslog: ninstaller.c:2168(ErrFHOSTUpdateMkfsProgress) switch to PROG_FORMAT_DATA 
Jan  1 00:00:04 syslog: ninstaller.c:2127(ErrFHOSTUpdateMkfsProgress) gInstallStage=[4] ret:0
Jan  1 00:00:04 syslog: ninstaller.c:2202(ErrFHOSTUpdateMkfsProgress) skip format data volume...
Jan  1 00:00:04 syslog: index=[1], ulRate=[100]
Jan  1 00:00:06 syslog: query prog, szBuf = ^R4VxSYNONI^A^D^A
Jan  1 00:00:06 syslog: ninstaller.c:2127(ErrFHOSTUpdateMkfsProgress) gInstallStage=[4] ret:0
Jan  1 00:00:06 syslog: ninstaller.c:2202(ErrFHOSTUpdateMkfsProgress) skip format data volume...
Jan  1 00:00:06 syslog: index=[1], ulRate=[100]
Jan  1 00:00:08 syslog: pat start, szBuf = ^R4VxSYNONI^A^D^A
Jan  1 00:00:08 syslog: ninstaller.c:194 Mount partion /dev/md0 /tmpData
Jan  1 00:00:08 kernel: [  214.534618] EXT4-fs (md0): barriers disabled
Jan  1 00:00:08 syslog: ninstaller.c:1527(ErrFHOSTReceiveUpgradeFile): szUpgradeFile = /tmpData//upd@te.pat 
Jan  1 00:00:08 kernel: [  214.535893] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: 
Jan  1 00:00:13 syslog: ninstaller.c:1558(ErrFHOSTReceiveUpgradeFile) cRead=[4], ulFileSize=[185866240]
Jan  1 00:00:13 syslog: ErrFHOSTTcpResponseCmd: cmd=[5], ulErr=[0]
Jan  1 00:00:13 syslog: Starting ErrFHOSTDoUpgrade()...
Jan  1 00:00:13 syslog: ErrFHOSTTcpResponseCmd: cmd=[5], ulErr=[0]
Jan  1 00:00:13 syslog: ErrFHOSTTcpResponseCmd: cmd=[5], ulErr=[0]
Jan  1 00:00:13 syslog: ninstaller.c:2412(ErrFHOSTDoUpgrade) retv=[0]
Jan  1 00:00:13 syslog: ErrFHOSTDoUpgrade() Done
Jan  1 00:00:13 syslog: Remove /tmpData/upd@te...cmd=[/bin/rm -rf /tmpData/upd@te > /dev/null 2>&1]
Jan  1 00:00:13 syslog: Create /tmpData/upd@te...cmd=[/bin/mkdir -p /tmpData/upd@te > /dev/null 2>&1]
Jan  1 00:00:13 syslog: Untar /tmpData/upd@te.pat...cmd=[/bin/tar xpf "/tmpData/upd@te.pat" -C /tmpData/upd@te > /dev/null 2>&1]
Jan  1 00:00:13 syslog: query prog, szBuf = ^R4VxSYNONI^A^D^A
Jan  1 00:00:13 syslog: alz=[0], prg=[0], cfg=[0], retv=[0]
Jan  1 00:00:14 syslog: Verify checksum of [/tmpData/upd@te]...
Jan  1 00:00:14 syslog: Pass checksum of /tmpData/upd@te...
Jan  1 00:00:14 syslog: ErrFHOSTTcpResponseCmd: cmd=[5], ulErr=[0]
Jan  1 00:00:14 syslog: ninstaller.c:516 ullPATReqKBytes=[620212]
Jan  1 00:00:14 updater: updater.c:5011 Start of the updater...
Jan  1 00:00:14 updater: updater.c:5120 This is X86 platform
Jan  1 00:00:14 updater: updater.c:5123 ==== Start flash update ====
Jan  1 00:00:14 updater: boot/boot_lock.c(225): failed to mount boot device /dev/synoboot2 /tmp/bootmnt (errno:6)
Jan  1 00:00:14 updater: updater.c:4945 Failed to mount boot partition
Jan  1 00:00:14 updater: updater.c:5711 Failed to accomplish the update! (errno = 2)
Jan  1 00:00:14 syslog: ninstaller.c:1751 Executing [/tmpData/upd@te/updater -v /tmpData -x > /dev/null 2>&1] error[2]
Jan  1 00:00:14 syslog: ninstaller.c:194 Mount partion /dev/md0 /tmpRoot
Jan  1 00:00:14 syslog: ninstaller.c:1720 Moving updater for configuration upgrade...cmd=[/bin/mv -f /tmpData/upd@te/updater /tmpRoot/.updater > /dev/null 2>&1]
Jan  1 00:00:14 syslog: ninstaller.c:223 umount partion /tmpRoot
Jan  1 00:00:14 syslog: ErrFHOSTCleanPatchDirFile: After updating /tmpData/upd@te...cmd=[/bin/rm -rf /tmpData/upd@te > /dev/null 2>&1]
Jan  1 00:00:14 syslog: ErrFHOSTCleanPatchDirFile: Remove /tmpData/upd@te.pat...
Jan  1 00:00:14 syslog: ErrFHOSTDoUpgrade(2396): child process failed, retv=-2
Jan  1 00:00:14 syslog: ninstaller.c:2404(ErrFHOSTDoUpgrade) err=[-1]
Jan  1 00:00:15 syslog: query prog, szBuf = ^R4VxSYNONI^A^D^A
Jan  1 00:00:15 syslog: alz=[0], prg=[0], cfg=[0], retv=[-2]
Jan  1 00:00:15 syslog: ninstaller.c:1841(ErrFHOSTUpdaterProgress) retv=-2
Jan  1 00:00:17 syslog: query prog, szBuf = ^R4VxSYNONI^A^D^A
Jan  1 00:00:17 syslog: alz=[0], prg=[0], cfg=[0], retv=[-2]
Jan  1 00:00:17 syslog: ninstaller.c:1841(ErrFHOSTUpdaterProgress) retv=-2
Jan  1 00:00:17 syslog: ninstaller.c:1361(ErrFHOSTNetInstaller) read socket fail, ret=[0], errno=[10]
Jan  1 00:00:17 syslog: ninstaller.c:1443(ErrFHOSTNetInstaller) retSel=[1] err=(10)[No child processes]
Jan  1 00:00:17 syslog: ninstaller.c:1458(ErrFHOSTNetInstaller)
Jan  1 00:00:17 syslog: Return from TcpServer()

 

For some reason synoboot2 is failing to mount, which seems to be causing the update process to fail.

 

Heres the github repository again: https://github.com/Jman420/nanoBoot-DSM5.1

 

Guys i think with the new release(s) synology changed the way the handle Access Control lists on the EXT4 drivers.

 

-> If i use the current kernel build (with the enhancement of also coping a synoacl_vfs.ko in the image the system boots normal on a 4493 installation of DSM. Once a go to install/de-install modus the installations does indead fail. Strangely is the fact that Nanoboot 5.0.3.2. does allow you to install 5004, without any errors.

 

Booting 5004 with the new build images leads to the normal error and the unmounting of all volumes. In the messages log one can read the following.

 

[    2.999826] synoacl_vfs: Unknown symbol __vfs_setxattr_noperm (err 0)
[   29.121477] thermal_sys: exports duplicate symbol generate_netlink_event (owned by kernel)
insmod: can't insert '/lib/modules/thermal_sys.ko': invalid module format
Dec 24 15:47:08 DiskStation kernel: [   29.250561] processor: exports duplicate symbol acpi_processor_get_bios_limit (owned by kernel)
insmod: can't insert '/lib/modules/processor.ko': invalid module formatinsmod: can't insert '/lib/modules/synoacl_vfs.ko': unknown symbol in module, or unknown parameter
Dec 24 15:47:09 DiskStation kernel: [   30.243642] synoacl_vfs: Unknown symbol __vfs_setxattr_noperm (err 0)

 

if you look a the original kernel parameters you see

CONFIG_EXT4_FS=y
CONFIG_EXT4_FS_XATTR=y
# CONFIG_EXT4_FS_POSIX_ACL is not set
# CONFIG_EXT4_FS_SECURITY is not set
# CONFIG_EXT4_DEBUG is not set

 

Inclusion of the SYNO_ACL for EXT is no longer there. Giving the impression that access controle is handled via eXtended Attributes....

CONFIG_EXT4_FS_SYNO_ACL=y

 

Maybe this is the explanation why the volumes are not mounting.

Link to comment
Share on other sites

the current problem is this one:

 

Jan  1 00:00:14 updater: updater.c:5011 Start of the updater...
Jan  1 00:00:14 updater: updater.c:5120 This is X86 platform
Jan  1 00:00:14 updater: updater.c:5123 ==== Start flash update ====
Jan  1 00:00:14 updater: boot/boot_lock.c(225): failed to mount boot device /dev/synoboot2 /tmp/bootmnt (errno:6)
Jan  1 00:00:14 updater: updater.c:4945 Failed to mount boot partition
Jan  1 00:00:14 updater: updater.c:5711 Failed to accomplish the update! (errno = 2)

 

for some reason it's trying to mount /dev/synoboot2, and this thing should not happen

 

Jan  1 00:00:22 updater: updater.c:4890 Start of the updater...
Jan  1 00:00:22 updater: updater.c:2270 fail to read company in /tmpRoot//etc.defaults/synoinfo.conf
Jan  1 00:00:22 syslog: ninstaller.c:1991 set upgrade completed cmd=[/bin/echo "C:0:" > /tmp/update.progress]

 

both log are taken from 4458 pat install (1st with 5004 kernel/rd 2nd with 4458)

Link to comment
Share on other sites

Looking at the PAT files from DSM 5.0 respectively revision 4458 or 4493 and compare it to the most recent DSM 5.1 PATs respectively revision 5004 or 5021, you will notice a huge difference between the updater executable.

 

They do seem to have moved out all basic C lib and BIOS, crypto stuff to H2OFFT-Lx64. In addition to that the updater lack the references to syno_dual_head (USB and SATA DOM parallel boot).

 

Consequently, I assume they have changed the way the updater works. It has nothing to do with the kernel, that we can actually build due to GPL source code access. The update however, is bundled with the PAT and inaccessible for us.

 

So far I have had no success to modify the updater due to my lack in ASM skill. But maybe someone else can continue here. It does not contain any reference to '/dev/synoboot' nor '/dev/synoboot2'.

Link to comment
Share on other sites

the current problem is this one:

 

Jan  1 00:00:14 updater: updater.c:5011 Start of the updater...
Jan  1 00:00:14 updater: updater.c:5120 This is X86 platform
Jan  1 00:00:14 updater: updater.c:5123 ==== Start flash update ====
Jan  1 00:00:14 updater: boot/boot_lock.c(225): failed to mount boot device /dev/synoboot2 /tmp/bootmnt (errno:6)
Jan  1 00:00:14 updater: updater.c:4945 Failed to mount boot partition
Jan  1 00:00:14 updater: updater.c:5711 Failed to accomplish the update! (errno = 2)

 

for some reason it's trying to mount /dev/synoboot2, and this thing should not happen

 

Jan  1 00:00:22 updater: updater.c:4890 Start of the updater...
Jan  1 00:00:22 updater: updater.c:2270 fail to read company in /tmpRoot//etc.defaults/synoinfo.conf
Jan  1 00:00:22 syslog: ninstaller.c:1991 set upgrade completed cmd=[/bin/echo "C:0:" > /tmp/update.progress]

 

both log are taken from 4458 pat install (1st with 5004 kernel/rd 2nd with 4458)

 

Hmmmm which boot image did you use kali ?

 

What i find strange is that nano boot 5.0.3.2. installs 5004 pat files without any problem so where are we missing the issue....

Link to comment
Share on other sites

i was not aware about 5004 installs fine on nanoboot 5.0.3.2 and this is promising

 

as i cant find nanoboot source, i compared nanoboot and a stock rd, and applied thing over 5004 rd

but is a stripped down version, i didnt apply things which looked to be cosmetics

Link to comment
Share on other sites

i was not aware about 5004 installs fine on nanoboot 5.0.3.2 and this is promising

 

as i cant find nanoboot source, i compared nanoboot and a stock rd, and applied thing over 5004 rd

but is a stripped down version, i didnt apply things which looked to be cosmetics

 

What i find strange is that nano boot 5.0.3.2. installs 5004 pat files without any problem so where are we missing the issue....

Are you sure?

I thought DSM 5.0-4528 Update 2 is the latest to install for the moment.

 

I think what HommiePeter is saying is that NanoBoot 5.0.3.2 installs the 5004 PAT file successfully, but when you boot 5004 with NanoBoot 5.0.3.2 you end up with no volumes mounted. On the other hand, NanoBoot compiled with 5004 kernel will not successfully install either 4458 or 5004 PAT files.

 

On another note (and more for my curiosity than anything else), what exactly is NanoBoot? Is it just the modded DSM kernel and ramdisk packaged into a custom boot image or is there more going on behind the scenes? Like Kali said above, I'm not sure that I've ever actually seen any NanoBoot source code.

Link to comment
Share on other sites

So I think I answered my own question above about what NanoBoot is, its exactly what I thought it was. Just the modded DSM kernel & ramdisk in a custom boot image.

 

I've also had another idea which I'm not sure anyone has tried. Since NanoBoot 5.0.3.2 can install the 5004 PAT file and NanoBoot with the 5004 kernel can successfully load volumes, what would happen if we installed 5004 with NanoBoot 5.0.3.2 and then switched over to NanoBoot with the 5004 kernel. Maybe the volumes would be loaded and DSM 5.1 would be successfully installed. NOTE: I'm just theorizing and haven't tried this at all. Hopefully I can give it a shot later tonight after I move a couch into my apartment.

Link to comment
Share on other sites

So I think I answered my own question above about what NanoBoot is, its exactly what I thought it was. Just the modded DSM kernel & ramdisk in a custom boot image.

 

I've also had another idea which I'm not sure anyone has tried. Since NanoBoot 5.0.3.2 can install the 5004 PAT file and NanoBoot with the 5004 kernel can successfully load volumes, what would happen if we installed 5004 with NanoBoot 5.0.3.2 and then switched over to NanoBoot with the 5004 kernel. Maybe the volumes would be loaded and DSM 5.1 would be successfully installed. NOTE: I'm just theorizing and haven't tried this at all. Hopefully I can give it a shot later tonight after I move a couch into my apartment.

 

Dear Jman420,

 

Indeed a interesting thought which has crossed my mind as Well but i have not figured out yet how to separate the ramdisk from the kernel with nanoboot his images. Furthermore Nanoboot 5.0.3.2 installs the 5004 pat file (correctly, installation procedure ends without errors) but on the reboot it states no volumes mounted.

 

Any suggestions on how to crack the nanoboot image open ?

 

Ps could anyone with a official 5.1 installation provide us with a file dump of the dmesg and messages log files right after booting up ? And show us the result of ls *syno*.* in the lib/modules folder.

 

Thanks in advance

Link to comment
Share on other sites

Ps could anyone with a official 5.1 installation provide us with a file dump of the dmesg and messages log files right after booting up ? And show us the result of ls *syno*.* in the lib/modules folder.

 

Thanks in advance

 

Someone with a real Synology running 5.1 offered to help out if anyone wanted them to not so long ago. I just scanned through most of this thread but couldn't find their post.

Link to comment
Share on other sites

Dear Jman420,

 

Indeed a interesting thought which has crossed my mind as Well but i have not figured out yet how to separate the ramdisk from the kernel with nanoboot his images. Furthermore Nanoboot 5.0.3.2 installs the 5004 pat file (correctly, installation procedure ends without errors) but on the reboot it states no volumes mounted.

 

Any suggestions on how to crack the nanoboot image open ?

 

Ps could anyone with a official 5.1 installation provide us with a file dump of the dmesg and messages log files right after booting up ? And show us the result of ls *syno*.* in the lib/modules folder.

 

Thanks in advance

 

The easiest way I've found to crack open the NanoBoot Image is to mount it in Linux. The build scripts on Sancome's Git Repository are a big help. Here is the line that mounts the IMG file:

mount -o loop,offset=32256 Synoboot_5.0-4458_x64_3612xs.img /mnt/img

 

Once the Image is mounted you can navigate to it just like any other device or directory:

cd /mnt/img

 

Just remember to unmount when you're done:

umount /mnt/img

 

Your changes will be reflected in the Image file that you mounted.

 

As for separating the kernel & ramdisk, they are already separated within the Boot Image. The 'zImage' file is the kernel and the 'rd.gz' archive is the ramdisk. If you are looking for more details about how the Image file is built you should check out the '02-build-img-file.sh' in Sancome's Git Repository.

Link to comment
Share on other sites

Dear Jman420,

 

Indeed a interesting thought which has crossed my mind as Well but i have not figured out yet how to separate the ramdisk from the kernel with nanoboot his images. Furthermore Nanoboot 5.0.3.2 installs the 5004 pat file (correctly, installation procedure ends without errors) but on the reboot it states no volumes mounted.

 

Any suggestions on how to crack the nanoboot image open ?

 

Ps could anyone with a official 5.1 installation provide us with a file dump of the dmesg and messages log files right after booting up ? And show us the result of ls *syno*.* in the lib/modules folder.

 

Thanks in advance

 

The easiest way I've found to crack open the NanoBoot Image is to mount it in Linux. The build scripts on Sancome's Git Repository are a big help. Here is the line that mounts the IMG file:

mount -o loop,offset=32256 Synoboot_5.0-4458_x64_3612xs.img /mnt/img

 

Once the Image is mounted you can navigate to it just like any other device or directory:

cd /mnt/img

 

Just remember to unmount when you're done:

umount /mnt/img

 

Your changes will be reflected in the Image file that you mounted.

 

As for separating the kernel & ramdisk, they are already separated within the Boot Image. The 'zImage' file is the kernel and the 'rd.gz' archive is the ramdisk. If you are looking for more details about how the Image file is built you should check out the '02-build-img-file.sh' in Sancome's Git Repository.

 

Jman,

 

thanks for your feedback but that is indeed all based in the image that is included in the build environment. What i mean is the Nano boot images that you can download here http://www.xpenology.nl/boot-images/#IMG (choose IMG (USB image voor installatie op hardware) i use 5.0.3.2.). If you mount that images only a zImage and a boot folder is presents. No ramdisk (rd.gz) file seems to be present (also no other partition where it is stored on). But this version allows you to install a 5004 pat file.

Link to comment
Share on other sites

DS1812> ls /lib/modules/ | grep -i syno
flashcache_syno.ko
synoacl_vfs.ko
synobios.ko
syno_flashcache_control.ko
syno_hddmon.ko
usb_wwan_syno.ko

 

 

Dear Sebj

 

thanks very much for this (although it is strange that to my experience the some .ko files (amongst others synoacl_vfs.ko is not made during the build process of a 5.1 kernel....). Could you make them available in a tar of zip file on this forum ?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...