DSM 6.1.x Loader


Recommended Posts

5 hours ago, lunzet said:

Yeah thanks. I know that tutorial.

 

Just wondering what is really required for running dsm on vmware as i think its different than baremetal:

vid / pid usb --> only for baremetal right?

yes

 

 

5 hours ago, lunzet said:

sn --> required for vmware and also baremetal

yes, but only some funcktions or plugins seem to depend on that, might be more in the future to get rid of freeloaders like us

 

5 hours ago, lunzet said:

mac --> only for enabling wol? (so optional for vmware/baremetal)

not entirely as i have seen that on virtula box vm you need a matching mac in vm and boot image to get network working, i've never used vmware/esxi with dsm, baremetal seems to work without matchin it to the reall mac but i would ecomend to do it

Link to post
Share on other sites
45 minutes ago, abced said:

When I plugin the boot USB, I have three options for boot in UEFI (partition 1, partition 2 an USB device or something). What's the one I should put on the first place?

 

 i'd guess usb device, my bios does not offer partitions, is just the usb device

Link to post
Share on other sites
4 hours ago, IG-88 said:

 

 i'd guess usb device, my bios does not offer partitions, is just the usb device

I guess you have BIOS, not UEFI, so you only see that loader. I guess the partition 1 of UEFI is the one I should select for boot.

Link to post
Share on other sites
1 hour ago, abced said:

I guess you have BIOS, not UEFI, so you only see that loader. I guess the partition 1 of UEFI is the one I should select for boot.

as grub ist the first thing to start and the grub.cfg ist in the first partition it will be the first choice

Link to post
Share on other sites

the files and there date in the image are a hint

like first parttion (easy to access when usb stick is in another system like windows or linux) folder "grub" the file "grubenv"

27.02.2017 - 1.02a

10.04.2017 -1.02a2

17.06.2017 - 1.02b

 

Link to post
Share on other sites
On 9/17/2017 at 3:47 AM, Rob_Quads said:

Is it possible on a running system to work out which version of the boot loader I'm running i.e. Version v1.02a, v1.02a2 or v1.02b:?

 

On 9/17/2017 at 3:42 PM, IG-88 said:

the files and there date in the image are a hint

like first parttion (easy to access when usb stick is in another system like windows or linux) folder "grub" the file "grubenv"

27.02.2017 - 1.02a

10.04.2017 -1.02a2

17.06.2017 - 1.02b

 

 

I think he meant on a running DSM system where the usb is plugged in. I don't think that's possible. I've tried to find references of the loader in the logs but Jun was very careful to make sure the logs did not contain any reference to it else the kernel would detect it as a hack. I think that during boot time there are some checks done to make sure the kernel is not modified. @jun would probably be the most appropriate person to answer this accurately.

Link to post
Share on other sites
On 9/17/2017 at 5:30 PM, Polanskiman said:

I think he meant on a running DSM system where the usb is plugged in. I don't think that's possible. I've tried to find references of the loader in the logs but Jun was very careful to make sure the logs did not contain any reference to it else the kernel would detect it as a hack. I think that during boot time there are some checks done to make sure the kernel is not modified. @jun would probably be the most appropriate person to answer this accurately.

ok i asumed shutting down dsm and plugging the usb stick to another computer, i did'nt take the running so serious

Link to post
Share on other sites
On 9/13/2017 at 10:17 AM, lunzet said:

 

I was wondering on the same. Could someone explain what the differences are --> pros / cons --> do's and dont's?

Just found one important difference between ds3615xs and ds3617xs, the former is "bromolow" architecture, while the latter is "broadwell" architecture, which means that since SynoCommunity packages must be recompiled for architecture and many have not yet been recompiled for the broadwell architecture, many SynoCommunity packages are unavailable on DS3617xs. Now hopefully it is just a matter of time but meanwhile, this limits SynoCommunity package access on 3617xs.

Link to post
Share on other sites
On 9/17/2017 at 5:05 PM, aol said:

Just found one important difference between ds3615xs and ds3617xs, the former is "bromolow" architecture, while the latter is "broadwell" architecture, which means that since SynoCommunity packages must be recompiled for architecture and many have not yet been recompiled for the broadwell architecture, many SynoCommunity packages are unavailable on DS3617xs. Now hopefully it is just a matter of time but meanwhile, this limits SynoCommunity package access on 3617xs.

Oh ok that explains my issue, thanks.

 

So running ds3615xs 6.1DSM will be ok with the SynoCommunity packages? 

I was going to rebuild my machine to 6.0.2 thinking it was the DSM version.  Is there benefits to the "broadwell" architecture?

Link to post
Share on other sites
31 minutes ago, LittleScratch said:

Oh ok that explains my issue, thanks.

 

So running ds3615xs 6.1DSM will be ok with the SynoCommunity packages? 

I was going to rebuild my machine to 6.0.2 thinking it was the DSM version.  Is there benefits to the "broadwell" architecture?

Sorry forgot to add I have a E3-1246v3 which I believe is a Denlow architecture.... Would that be an issue?

Link to post
Share on other sites

Any DSM will be ok with SynoCommunity packages... but the DS version you are running (3615xs, 3617xs, 916) has a hardcoded architecture regardless of the actual CPU you have inside your xpenology. An xpenology that has been told by nature of the bootloader that it's a 3615xs can only _install_ (through the Package Center GUI) SynoCommunity packages compiled for bromolow architectures or SynoCommunity packages that were compiled with "noarch" (no architecture specified). In reality of course any 64-bit CPU can run almost any 64-bit compiled program; it's a matter of the instruction sets that the compiled package uses, stuff like SSE, SSE2, SSE3 etc, MMX, etc.  You're obviously not going to change your CPU, the only way it'd be an issue is if you specify a model and architecture that results in installing a SynoCommunity package which expects (let's say) SSE5 instruction set support but your CPU doesn't actually have that support. Then that program will crash most likely. So that's a point in favor of choosing a model that is closest to your actual CPU and if in doubt behind (since later CPUs generally support the earlier instruction sets).

 

Broadwell adds support for later instruction sets but as we discovered many SynoCommunity packages haven't been compiled (yet) for Broadwell so it doesn't do you any good. Really depends on your need. Plex (my main app) runs regardless of model. Most of the popular apps in SynoCommunity run on Broadwell by nature of compiled for "noarch". But some don't. 

Link to post
Share on other sites

Something get wrong.

DSM 6.1.3.Update 4. Jun 1.02b. HP gen 8.

First I cant mount directories under the admin user. It post something like "Relogin again".

Then I reboot it manually.

At that time I saw the device in samba and Synology assistent, but when try to connect to admin web

I got page: "Synology. Sorry, search page didn't find".

I reboot HP by hand then (push the button).

Now I cant see DSM in samba and in Synology assistent.

In the web I get the same page: "Synology. Sorry, search page didn't find".

Recently all worked fine. I update to 6.1.3.Update 4 last week, before was 6.1.3.Update 3.

 

Link to post
Share on other sites
21 hours ago, aol said:

Any DSM will be ok with SynoCommunity packages... but the DS version you are running (3615xs, 3617xs, 916) has a hardcoded architecture regardless of the actual CPU you have inside your xpenology. An xpenology that has been told by nature of the bootloader that it's a 3615xs can only _install_ (through the Package Center GUI) SynoCommunity packages compiled for bromolow architectures or SynoCommunity packages that were compiled with "noarch" (no architecture specified). In reality of course any 64-bit CPU can run almost any 64-bit compiled program; it's a matter of the instruction sets that the compiled package uses, stuff like SSE, SSE2, SSE3 etc, MMX, etc.  You're obviously not going to change your CPU, the only way it'd be an issue is if you specify a model and architecture that results in installing a SynoCommunity package which expects (let's say) SSE5 instruction set support but your CPU doesn't actually have that support. Then that program will crash most likely. So that's a point in favor of choosing a model that is closest to your actual CPU and if in doubt behind (since later CPUs generally support the earlier instruction sets).

 

Broadwell adds support for later instruction sets but as we discovered many SynoCommunity packages haven't been compiled (yet) for Broadwell so it doesn't do you any good. Really depends on your need. Plex (my main app) runs regardless of model. Most of the popular apps in SynoCommunity run on Broadwell by nature of compiled for "noarch". But some don't. 

Really informative thank you! Have read up a bit more since reading this.

 

I think I understand now a little more.  The bit I am getting lost on one thing:

If the DS has a hardcoded architecture then does it use all the processors cores and threads?  I understand it wont use all the instruction sets which for me i don't think will cause too much of an issue. Also out of curiosity is Intel® Quick Sync Video classed as an instruction set?

 

I'm mainly using it for Plex, sonarr, couchpotato sabnzb so at the moment 3617xs with the broadwell arch is out of the question for community apps at the mo, but sounds wise for me to upgrade when they do....... 

 

It still sounds to me that xpenology would make more stable and maybe faster media pc than if I installed windows 10

Link to post
Share on other sites
On 9/17/2017 at 5:30 PM, Polanskiman said:

I think he meant on a running DSM system where the usb is plugged in. I don't think that's possible. I've tried to find references of the loader in the logs but Jun was very careful to make sure the logs did not contain any reference to it else the kernel would detect it as a hack. I think that during boot time there are some checks done to make sure the kernel is not modified. @jun would probably be the most appropriate person to answer this accurately.

 

Yup this is on a running system, more specifically one sitting in a roof space which is a bit of a pain to get to making removing the USB not so easy and seeing the boot up screen is tricky

Link to post
Share on other sites
On 9/10/2017 at 5:25 AM, azn-tuan said:

Hi guys,

 

I just finish to migrate from DSM 5.1-5022 to DSM 6.1.3-15152 on my HP N54L with no issue at all !

Just a question, how can I apply the DSM 6.1.3-15152 update 4 without problem?

Do I have to install manually update 1, 2 and 3 first?

 

Thanks for your help and thanks for your great work !

 

Hi @azn-tuan, which loader did you use? I own aswell a N54L but didnt get DSM 6.1 working. Actually stuck at DSM 6.0.2-8451.

Polanskiman wrote "v1.02b (DS3615xs, DS3617xs and DS916+) is for DSM 6.1 - AMD loosely compatible and with Bios tweaks - Latest version for DSM 6.1"

 

Could you please describe which bios tweaks you did?

Link to post
Share on other sites

I had a question about expanding drives.

 

So I have a supermicro board with a LSI SAS9207-8i on it, and it has 8 internal SATA ports. Im running Jun 1.02b, and 6.13 R3.

I have had 6 2TB drives connected to it and 1 SSD cache for about a year and one failed, so I figured I'd add 2 more and replace the 3rd one with 3 TB drives.

Problem #1 - When I replaced the 2TB with a 3TB drive, it repaired, but didnt expand the set to the larger size.

Problem #2 - When I added the 2 drives, they appear as eSATA disks.

If i do a quick dmesg it shows all 8 drives as SCSI drives as 0-7 (example: scsi 6:0:7:0: qdepth(32), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1))

 

There are 4 USB3 ports and 2 controllers in the system (on board has 6, LSI has 8).

I changed the synoinfo.conf to esataportcfg="0x0000", usbportcfg="0x0400", internalportcfg="0x00FF"

 

I was running my grub.cfg with SataPortMap=81 (which recognizes 6 drives and 1 ssd) and changed it to SataPortMap=86

Now the SSD cant be put into the cache SSD, and it wont add to raid as it sees the 2 new drives as esata disks.

The drives on the HDD/SSD show as Disk 1 for SSD, then Disk 7-12 for the LSI controller.

I've increased it to 16 just to see if it would do better, but no gold.

 

Any thoughts on what else I can do?

 

Thx!

Link to post
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.