[NEW DSM 5.1-5004 AVAILABLE !!]

Hi Aigor,

 

I guess i shouldn't have replied at all

 

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

[NEW DSM 5.1-5004 AVAILABLE !!]

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

 

cheers Louis

[NEW DSM 5.1-5004 AVAILABLE !!]

Hmmm, guess i forgot to tell you ... After DSM is started volume1 still is removed

So not really a great solution [emoji17]

[NEW DSM 5.1-5004 AVAILABLE !!]

@civilmann

 

Tried several options .... but still only volume 1 will be available...

The other volumes can be mounted but are not available in the DSM

 

The only option is to have a boot script which well reassamble the raid's then activate the volume groups and remount the logical volume.

 

Also to use these other volumes you will first have to create the shared folders on volume1.

Then you'll have to create the folder on, let say, volume2 and remove the folder on volume1 .. then create a symbolic links from volume1 to the folder on volume2.

 

Or you might use a mount --bind to do it (or from fstab)

 

Alot of problems to get it to run ... and an upgrade will probably kill it all

 

btw on a clean install i couldn't get it to work yet .....

 

cheers Louis

 

example of script:

 

mdadm --assemble --force --no-degrade /dev/md3 /dev/hdd3 /dev/hde3 # vg1

mdadm --assemble --force --no-degrade /dev/md2 /dev/hdc3 # vg1000

vgchange -a y vg1

vgchange -a y vg1000

cp /root/fstab /etc/fstab

mount -a

 

example of my test systems fstab :

 

none /proc proc defaults 0 0

/dev/root / ext4 defaults 1 1

/dev/vg1000/lv /volume1 ext4 usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,synoacl 0 0

/dev/vg1/volume2 /volume2 ext4 usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,synoacl 0 0

/volume2/test /volume1/test bind defaults,bind 0 0 # this is the "linked" shared folder

[NEW DSM 5.1-5004 AVAILABLE !!]

@Poechi

 

I think i've already read it somewhere ... When entering DSM it moves /dev/sd* to /dev/hd*

 

So doesn't seem to be the daemon ... But something in DSM ....

 

The question is what causes it .... I read something of a checksum somewhere

[NEW DSM 5.1-5004 AVAILABLE !!]

Hi Poechi,

 

The problem is that at boot they excist but at some point they are renamed to hda, check the /dev. I once wrote a script to create a symlink ....

But they are deleted every time

 

If the sda is in /dev all is good, everything works, but after some time they are deleted ... I guess by some dev daemon

 

Cheers Louis