Jump to content
XPEnology Community

DSM 6.1.x Loader


jun

Recommended Posts

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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
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 comment
Share on other sites

On 18-9-2017 at 9:27 AM, reziel84 said:

hi guys

someone can help me? i have esx 6.5 with old 5.2 xpeno.  please can help me to migrate to 6.1 without loosing data? i have much moore than 2tb of file in raid1.....

please can contact me in private message and help me?

many thanks

 

Follow the steps in this tutorial. Worked for me. Only difference is that I'm using a baremetal but it should work for VM also. Got from 5.2 latest build all the way to DSM 6.1.3-15152 Update 4.

 

Link to comment
Share on other sites

Hi guys,

I followed the migration tutorial and would like to share my experiences.

 

HW/SW: HP DL380 G6 ESXI 6.0

DSM 5.2 with LSI 2008 RAID Contoller in Passthrough Mode.

 

1. MAC/SN Modification of .img

2. Create new DSM 6.1 VM in VMWorkstation following  a youtube tutorial

3. Used VM Converter in order to copy the machine to esxi.

4. In DSM 5.2 VM I replaced 5.2 Bootloader .vmdk with 1.02b .vmdk

5. Started  DSM 5.2 VM with 1.02b Bootloader and started "Migration"

6. Migration finished with a crash of VM and esxi (bluescreen)

7. Changed OS version of migrated VM to Linux 3.x

8. Started migrated DSM 6.1 VM to find out that it's destroyed!

 

from now it's about troubleshooting:

 

9.   I started the VM from step 3 and installed a configuration.dss without the shared folders from my DSM 5.2

10. Created 4 vmxnet3 NIC's and the RAID Controller (PCI Device)

11. Started the DSM 6.1 VM and repaired volumes.

 

RESULT: NO DATA LOST!

 

BUT:

1. ONLY 1 NIC was working. I couldn't ping from a remote machine NIC 2,3,4. I was able to ping on the DSM itself and the configuration looked good.

2. JUMBO Frames did not work.

3. I removed  the 4 NIC's and replaced them with 4 E1000 NIC's

 

RESULT: All adapters are working. JUMBO Frames still not working

 

I couldn't find anything about compatibility of VM NIC types yet. Is anybody aware of bestpractices?

I would like to use the vmxnet3 adapter witth MTU 9000 again, like in the DSM 5.2!

 

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