Jump to content
XPEnology Community

lowietje

Transition Member
  • Posts

    6
  • Joined

  • Last visited

lowietje's Achievements

Newbie

Newbie (1/7)

0

Reputation

  1. 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
  2. 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
  3. Hmmm, guess i forgot to tell you ... After DSM is started volume1 still is removed So not really a great solution [emoji17]
  4. @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
  5. @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
  6. 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
×
×
  • Create New...