Jump to content
XPEnology Community

NEW DSM 5.1-5004 AVAILABLE !!


Recommended Posts

Hi Hetfield,

 

As mentioned before the problem is in a different part of the system, it has to do with all kind of checks dsm does ... checksumming ... device checking ... etc, as mentioned by schmill don't touch this until ....

 

just my 2 cents :smile:

 

cheers Louis

 

as fr you know, how works checksumming? which kind of data are involved? where OS grab data?

Thanks :grin:

 

It's possibile that they put some bios module where read data for checksumming?

Link to comment
Share on other sites

Hi Aigor,

 

I guess i shouldn't have replied at all :roll:

 

But sorry to dissappoint you, i don't have any knowledge of these things, i just read the forums lately, and found some old stuff for version 4.3, i guess the checksum thing was introduced in this version .... don't pin me on this one ...

 

So i can't help you or anyone else in this matter ...

 

I guess this should all be done at boottime, so the nanoboot or any other boot module should be able to take care of it.

 

Until that is done i guess there will not be a working Xpenology 5.1....

 

I guess we have to be patient

 

Cheers Louis

Link to comment
Share on other sites

Hi yud - put simply, no. Don't touch 5.1 yet, there are various issues with it that the great minds here are still figuring out :smile:

 

You can always keep an eye on the status table at the bottom of the page (above the comments) on xpenology.nl to see the overall status of a release:

http://www.xpenology.nl/synology-released-dsm-5-1-5004/

 

Welcome to xpenology :smile:

 

Thanks!

 

I will stick to my current version for now...

Link to comment
Share on other sites

This is the point i was afraid for the last weeks. we are trying to find the error, without having the option to test a solution cause 1 person got the code. i had asked here in this forum 4 weeks ago if anybody has the source for nanoboot....... no answer at all.

 

don´t get me wrong. But open source development works differently.

 

does anybody have the source from nanoboot?

Link to comment
Share on other sites

This is the point i was afraid for the last weeks. we are trying to find the error, without having the option to test a solution cause 1 person got the code. i had asked here in this forum 4 weeks ago if anybody has the source for nanoboot....... no answer at all.

 

don´t get me wrong. But open source development works differently.

 

does anybody have the source from nanoboot?

 

 

Isn't this the source code: http://nanoboot.eu.org/source

Link to comment
Share on other sites

Hey Guys,

 

i have installed DSM 5.1 on my test system and i did boot but without my drive getting mounted als already mentioned. (See attached image)

 

But when i did some investigation of de log files (see relevant parts of DMESG below ) i found out that:

- My disk is detected

- (3) Partitions where created in a Raid 1 configuration

- 2 of the 3 Partitions are mounted (SWAP en System)

- the 3 one (data) is not mounted because is is missing a super block

 

Could this be the reason why the disks are disappearing, and how can we over come the missing super block issue ?

 

Login Screen Diskstation

Post init
Init: Unable to mount /dev filesystem: No such device
=================== start  udevd ================
===trigger device plug event =====

DiskStation login: 

 

Fragment DMESG |GREP MD

[    2.521864] md: Autodetecting RAID arrays.
[    2.557755] md: invalid raid superblock magic on sda3
[    2.557759] md: sda3 does not have a valid v0.90 superblock, not importing!
[    2.557768] md: Scanned 3 and added 2 devices.
[    2.557769] md: autorun ...
[    2.557771] md: considering sda1 ...
[    2.557776] md:  adding sda1 ...
[    2.557779] md: sda2 has different UUID to sda1
[    2.557783] md: created md0
[    2.557786] md: bind
[    2.557800] md: running: 
[    2.557881] md/raid1:md0: active with 1 out of 12 mirrors
[    2.557894] md0: detected capacity change from 0 to 2549940224
[    2.557929] md: considering sda2 ...
[    2.557932] md:  adding sda2 ...
[    2.558072] md: created md1
[    2.558073] md: bind
[    2.558081] md: running: 
[    2.558149] md/raid1:md1: active with 1 out of 12 mirrors
[    2.558163] md1: detected capacity change from 0 to 2147418112
[    2.558200] md: ... autorun DONE.
[    2.588148]  md1: unknown partition table
[    2.619514]  md0: unknown partition table
[    2.627526] EXT4-fs (md0): barriers disabled
[    2.664578] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: 
[    2.755146] Adding 2097084k swap on /dev/md1.  Priority:-1 extents:1 across:2097084k 
[   12.564551] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: barrier=1
[   13.059297] EXT4-fs (md0): re-mounted. Opts: (null)
[   16.126338] Adding 2097084k swap on /dev/md1.  Priority:-1 extents:1 across:2097084k 

[   18.187065] systemd-udevd[12176]: starting version 204
[   19.844557] md: md2 stopped.
[   20.158934] ata1.00: cmd 60/08:00:08:00:90/00:00:00:00:00/40 tag 0 ncq 4096 in
[   20.336575] ata1.00: cmd 60/08:00:08:00:90/00:00:00:00:00/40 tag 0 ncq 4096 in
[   20.514303] ata1.00: cmd 60/08:00:08:00:90/00:00:00:00:00/40 tag 0 ncq 4096 in
[   20.691952] ata1.00: cmd 60/08:00:08:00:90/00:00:00:00:00/40 tag 0 ncq 4096 in
[   20.869715] ata1.00: cmd 60/08:00:08:00:90/00:00:00:00:00/40 tag 0 ncq 4096 in
[   21.047414] ata1.00: cmd 60/08:00:08:00:90/00:00:00:00:00/40 tag 0 ncq 4096 in
[   21.048569] md: disabled device sda3, could not read superblock.
[   21.048573] md: sda3 does not have a valid v1.2 superblock, not importing!
[   21.048580] md: md_import_device returned -22
[   21.049702] md: md2 stopped.
[   21.213691] md: md2 stopped.

Link to comment
Share on other sites

Hey Guys,

 

i have installed DSM 5.1 on my test system and i did boot but without my drive getting mounted als already mentioned. (See attached image)

 

But when i did some investigation of de log files (see relevant parts of DMESG below ) i found out that:

- My disk is detected

- (3) Partitions where created in a Raid 1 configuration

- 2 of the 3 Partitions are mounted (SWAP en System)

- the 3 one (data) is not mounted because is is missing a super block

 

Could this be the reason why the disks are disappearing, and how can we over come the missing super block issue ?

 

Login Screen Diskstation

Post init
Init: Unable to mount /dev filesystem: No such device
=================== start  udevd ================
===trigger device plug event =====

DiskStation login: 

 

Fragment DMESG |GREP MD

[    2.521864] md: Autodetecting RAID arrays.
[    2.557755] md: invalid raid superblock magic on sda3
[    2.557759] md: sda3 does not have a valid v0.90 superblock, not importing!
[    2.557768] md: Scanned 3 and added 2 devices.
[    2.557769] md: autorun ...
[    2.557771] md: considering sda1 ...
[    2.557776] md:  adding sda1 ...
[    2.557779] md: sda2 has different UUID to sda1
[    2.557783] md: created md0
[    2.557786] md: bind
[    2.557800] md: running: 
[    2.557881] md/raid1:md0: active with 1 out of 12 mirrors
[    2.557894] md0: detected capacity change from 0 to 2549940224
[    2.557929] md: considering sda2 ...
[    2.557932] md:  adding sda2 ...
[    2.558072] md: created md1
[    2.558073] md: bind
[    2.558081] md: running: 
[    2.558149] md/raid1:md1: active with 1 out of 12 mirrors
[    2.558163] md1: detected capacity change from 0 to 2147418112
[    2.558200] md: ... autorun DONE.
[    2.588148]  md1: unknown partition table
[    2.619514]  md0: unknown partition table
[    2.627526] EXT4-fs (md0): barriers disabled
[    2.664578] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: 
[    2.755146] Adding 2097084k swap on /dev/md1.  Priority:-1 extents:1 across:2097084k 
[   12.564551] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: barrier=1
[   13.059297] EXT4-fs (md0): re-mounted. Opts: (null)
[   16.126338] Adding 2097084k swap on /dev/md1.  Priority:-1 extents:1 across:2097084k 

[   18.187065] systemd-udevd[12176]: starting version 204
[   19.844557] md: md2 stopped.
[   20.158934] ata1.00: cmd 60/08:00:08:00:90/00:00:00:00:00/40 tag 0 ncq 4096 in
[   20.336575] ata1.00: cmd 60/08:00:08:00:90/00:00:00:00:00/40 tag 0 ncq 4096 in
[   20.514303] ata1.00: cmd 60/08:00:08:00:90/00:00:00:00:00/40 tag 0 ncq 4096 in
[   20.691952] ata1.00: cmd 60/08:00:08:00:90/00:00:00:00:00/40 tag 0 ncq 4096 in
[   20.869715] ata1.00: cmd 60/08:00:08:00:90/00:00:00:00:00/40 tag 0 ncq 4096 in
[   21.047414] ata1.00: cmd 60/08:00:08:00:90/00:00:00:00:00/40 tag 0 ncq 4096 in
[   21.048569] md: disabled device sda3, could not read superblock.
[   21.048573] md: sda3 does not have a valid v1.2 superblock, not importing!
[   21.048580] md: md_import_device returned -22
[   21.049702] md: md2 stopped.
[   21.213691] md: md2 stopped.

 

Very interesting as when you create an RAID1 under Linux with mdadm command you get the following hint for the bootloader:

mdadm: Note: this array has metadata at the start and may not be suitable as a boot device. If you plan to store '/boot' on this device please ensure that your boot-loader understands md/v1.x metadata, or use --metadata=0.90

 

So maybe nanoboot does create the RAID in a different way which isn't supported in DSM 5.1 anymore or uses an outdated version of madam.

Or the kernel is too old.

 

[root@localhost ~]# mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1
mdadm: Note: this array has metadata at the start and
   may not be suitable as a boot device.  If you plan to
   store '/boot' on this device please ensure that
   your boot-loader understands md/v1.x metadata, or use
   --metadata=0.90
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
[root@localhost ~]#

 

More Infos can be found here for example:

http://www.thomas-krenn.com/de/wiki/Linux_Software_RAID

Link to comment
Share on other sites

So, I think it safe to say DSM 5.1 uses superblock 1.2 for the data array.

 

Correct, but as DSM 5.0-4528 U2 also uses superblock 1.2 it can't be the cause of problem which we are having with DSM 5.1.

 

I installed 5.1 on a simple bare metal test system and I see the following:

 

Starting /usr/syno/bin/syncfgen...  [OK]
/usr/syno/bin/synocfgen returns 0
Partition Version=0
Partition layout is not DiskStation style.
NOT EXECUTE /sbin/e2fsck.
Mounting /dev/md0 /tmpRoot
:: Checking upgrade file  [OK]
linuxrc.syno executed successfully.
Post init
init: Unable to mount /dev filesystem: No such device
=================== start  udevd ================
===trigger device plug event =====

DiskStation login: 

Link to comment
Share on other sites

It isn't the superblock on the partition, it has been 1.2 for a while. The seems that the volume problem is related to device detection. If you upgrade a DSM5.0 to DSM5.1 md0 and md1 are preserved and work correctly, it is only md2 (where the volume is) that stops working. The volume and data are all there though - if you boot to a different linux, and assemble the raids you will find that all 3 work fine.

 

I think the problem is device detection during the boot: The boot message "init: Unable to mount /dev filesystem: No such device" is one clue, the other is that if you try "mdadm --assemble --scan" it tries to assemble md2 out of "8;53, 8:69, 8:85, and 8:37 when it should be assembling the array out of the sd[abcd]5 partitions. "cat /proc/partitions" indicates that sd[abcd]5 exist, but "ls /dev/sd*" indicates there are no sdX devices, while "ls /dev/hd* shows that the drives are apparently all there, but detected as hdX devices. Trying to assemble md2 from the hdX5 partitions doesn't work either.

 

Googling around for the "init: Unable to mount /dev filesystem: No such device" and the misdetection of sdX as hdX it would seem that CONFIG_DEVTMPFS was not set when the xpenology boot image was compiled, but this may be a red herring. liwei's Git repository has this flag set. Nonetheless, I think it is related to the device detection.

 

I am trying to set up a VM to compile the kernel but I'm not having much luck - on the one hand, I'm not all that proficient at linux, and on the other, I think we need the gpl for DSM5.1 from synology, which hasn't been released yet. Has anyone seen a complete "how to set up for cross compiling xpenology guide"?

 

The "partition layout is not diskstation style" has been there since quite a few versions of xpenology, so I don't think that is the issue.

Link to comment
Share on other sites

Hi there all again,

 

i have been looking more into the issue of the volumes not getting mounted. I have seen 2 points of interest the seem to be linked to each other.

1) DSM 5.1 uses AppArmor

2) the boot script has been seriously changed for mounting the volumes

 

DSM 5.1 uses AppArmor.

DSM uses AppArmor for high security protection. I expects that the relevant modules are load in the linux kernel. De kernel that is used for Nanoboot does not support AppArmor which leads to faults during booting. I am not sure if activation AppArmor in the Nanoboot linuxkernel requires a complete rebuild of the kernel ...... As an alternative i am looking at Disabling AppArmor in /etc/synoinfo.conf and /etc.defaults/synoinfo.conf ...

 

support_apparmor="yes"  

 

Running

/usr/syno/etc/rc.sysv/apparmor.sh status

Gives

AppArmor is not loaded.

Install the apparmor-utils package to receive more detailed

status information here (or examine directly).

 

Different boot script.

In DSM 5.1 the boot script has been changed (etc/rc) especially on mounting of the volumes. See included code examples.....

 

Part of the old bootscript DSM 5.0 4493 on a DS214play.

if [ "yes" = "$RUN_HA" ]; then
$SZF_HA_RC prepare-for-upg
else
# initial findhostd first to report quota check progress, see DS20 bug #
/usr/syno/etc/rc.d/S98findhostd.sh start

if [ "yes" = "${UbifsVolume}" ]; then
	/bin/mount -t ubifs ubi0:volume1 /volume1
else
	# checking and Mounting filesystem(s) ...
	/usr/syno/bin/synobootseq --set-check-fs  >/dev/null 2>&1
	/etc.defaults/rc.volume start
	# reset bootseq to start-services
	/usr/syno/bin/synobootseq --set-start-services >/dev/null 2>&1
fi
/sbin/initctl emit --no-wait syno.volume.ready
fi

 

Part of the new bootscript on DSM 5.1 5004 on a DS3612xs.

if [ "yes" = "$RUN_HA" ]; then
$SZF_HA_RC prepare-for-upg
else
# checking and Mounting filesystem(s) ...
/usr/syno/bin/synobootseq --set-check-fs  >/dev/null 2>&1
/etc.defaults/rc.volume start
# reset bootseq to start-services
/usr/syno/bin/synobootseq --set-start-services >/dev/null 2>&1
/sbin/initctl emit --no-wait syno.volume.ready
fi

 

When manually running the steps on DSM 5.1

/usr/syno/bin/synobootseq --set-check-fs  >/dev/null 2>&1
/etc/rc.volume start         
/usr/syno/bin/synobootseq --set-start-services >/dev/null 2>&1
/sbin/initctl emit --no-wait syno.volume.ready

 

I get the following output which links it back to the AppArmor module which is not loaded (see point 1)

DiskStation> Starting AppArmor 
modprobe: chdir(3.2.40): No such file or directory
$Loading AppArmor module: Failed. 

 

I know this gives not the solution we all are looking for ...... but might provide some more insight the the problem we need to tackle....

Link to comment
Share on other sites

So, I have setup a Ubuntu server vm, latest updates, and tried using sancome's git repository (and scripts) and the other files per nanoboot.eu

 

I ran:

01-unzip-linux-3.x.sh

make clean

make menuconfig

without seeing any error messages.

 

When I run:

make modules

It outputs:

 

fs/nfsd/vfs.c: In function ‘nfsd_setattr’:
fs/nfsd/vfs.c:337:2: error: implicit declaration of function ‘IS_SYNOACL’ [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[2]: *** [fs/nfsd/vfs.o] Error 1
make[1]: *** [fs/nfsd] Error 2
make: *** [fs] Error 2

 

This makes make bzImage barf, even if I don't change anything in menuconfig.

Question 1)

Why is make modules giving this error?

 

Question 2)

Even if I do get this to compile an image, this will be for DSM50, don't I need gpl and toolchains for DSM5.1?

 

Andrew

 

ps. As far as I can tell, CONFIG_DEVTMPFS is set in Sancome's .config, I was hoping that it wasn't, as this can cause device detection issues similar to what we have been seeing on DSM5.1.

Link to comment
Share on other sites

so in the 5 pages of comments i take it nobody was successful in getting this to work on any hardware. That is kind of scary to think about it, since nobody has this working and its been a good couple of weeks or so. I wonder if by this year in 2014 will it be possible to run 5.1 or have the xpenology box not be accessible from the internet.

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...