Jump to content
XPEnology Community

DSM 6.2 Loader


jun

Recommended Posts

So now I have tested the V1.03a2 DS918+ bootloader and the host was found (N4200 Realtek PCIe Gigabit Family) as DS918+ and I was able to install it.

But then it took too long to restart and the installer says timeout.

Later it was found but starts very slow, after 6+minutes it stays service starting but the nit switches off and I was not able to reinstall it (I get at error 21). So I gave up the DS918+

However the DS3617 boots (VD/PID of course corected) and it never get visible in the network. So I guess it does not really boot properly after the last console mesage.

So I'm stuck. I would use a working 918+ bootloader or a DS3617 is alo fine, but both dont work.

Edited by knopserl
Link to comment
Share on other sites

Hi all,

 

I have a microserver gen8 with i5-3470t and 16gb ram, esxi 6.7.0 and LSI2008 (corss flashed Fujitsu D2607) with pci pass through where all my data and the system is on and it's working with 6.1. I updated the loader to 1.03b and made the changes for serial and mac (same as for 6.1).

 

The old system is found, but now I get the Error 13 when I try to install the 6.2 pat file. What could be the problem?

Has somebody a working esxi with pci pass through?

 

When I put back the old loader, all works well again.

 

Greets

 

Alex

esxi_xpenology.PNG

Link to comment
Share on other sites

6 minutes ago, alese said:

Hi all,

 

I have a microserver gen8 with i5-3470t and 16gb ram, esxi 6.7.0 and LSI2008 (corss flashed Fujitsu D2607) with pci pass through where all my data and the system is on and it's working with 6.1. I updated the loader to 1.03b and made the changes for serial and mac (same as for 6.1).

 

The old system is found, but now I get the Error 13 when I try to install the 6.2 pat file. What could be the problem?

Has somebody a working esxi with pci pass through?

 

When I put back the old loader, all works well again.

 

Greets

 

Alex

esxi_xpenology.PNG

 

Error 13 can happen if there is a mismatch between serial # and model on the boot loader (i.e. using a DS3615xs serial with the DS3617xs loader or vice versa).  Maybe that?  If it isn't that--how is your synoboot.img configured in ESXi?  Can expand the details in that screenshot to reveal--should be SATA 0:0.  I set to "Independent - Persistent", although I don't know if that matters.

Link to comment
Share on other sites

9 hours ago, ViSoR said:

Successfully updated from 6.1 to 6.2 (DS3615xs)

ESXi 6.5u2 on HP MicroServer Gen8, Xeon 1220L v2. HDDs are passed to VM as RMD.

There were two important changes in the VM settings to run with 1.03b:

1. Change EFI to BIOS to enable LAN.

2. Move HDDs from virtual SATA to virtual SCSI as Synology installer was not able to find disks on SATA.

Almost the same settings, except I run DS3617xs.

Already booted from BIOS, HDD mounted on SCSI.

Can't find DSM in LAN

Link to comment
Share on other sites

Hi all, some thoughts/help would be appreciated - I'm a N54L user that's been able to boot, but the system hasn't been stable/is a bit flakey;

 

To give context, I had mistakenly clicked the "upgrade to 6.2" button under the 6.0/1 loader, and had been waiting for a 6.2.x loader to come around to try and resurrect my box.

Have since tried both 3615/3617 6.2 imgs, and both the normal boot/re-install (selecting migration) boots, and the box will boot and the web interface is accessible via the network at the originally configured static network address.

 

But I'm running into general flakiness when trying to manage the server, exhibited by:
* Whenever I attempt to use File Station, I have to manually start the service and then run it, and even then it would stop working after awhile (and I would need to re-start the service) - I have tried manually re-installing the package, to only get the same effect
* When I create a Shared Folder, it would state that the operation was not successful and that I would need to re-login to DSM
* The resource monitor doesn't update for CPU or network activity
* Packages keeps saying that it cannot connect to the internet
* And the box doesn't seem to be picked up (in any state) by Synology assistant (web or local version)

Link to comment
Share on other sites

10 hours ago, Saoclyph said:

... and cleaning a little the /etc/synoinfo.conf file (removed support_syno_hybrid_raid option, and some other options, not sure if it had an effect), everything was working great again!

 

That's interesting, because I've also added that line to my synoinfo.conf file in 6.1.  I'd completely forgotten about it, so I'll mess around with 6.2 again and see if this might be the trigger.

 

Those scripts in /etc are suspicious as well, because they don't exist in 6.x, but it sure looks like /etc/upgrade.sh is being called on my system, when I watch 1st boot output using VSP through iLO.  I wonder if they're some holdover from 5.x and are accidentally being called during this upgrade, and messing everything up.

 

Oh well, it's a place to start.

Link to comment
Share on other sites

8 hours ago, autohintbot said:

 

Error 13 can happen if there is a mismatch between serial # and model on the boot loader (i.e. using a DS3615xs serial with the DS3617xs loader or vice versa).  Maybe that?  If it isn't that--how is your synoboot.img configured in ESXi?  Can expand the details in that screenshot to reveal--should be SATA 0:0.  I set to "Independent - Persistent", although I don't know if that matters.

Error 13 is also a "Whoops! I had a problem writing the system to disk". This will be the drives that you intend to put data on. It can be that either it is not finding your disks or you have defined a virtual disk for testing that is too small.....

Link to comment
Share on other sites

Baremetal HP Microserver Gen8 with Xeon 1265Lv2 succesfully updated to 6.2 based on DS3615xs

 

I just copied the new loader img to the microsd, edited the grub.cfg and uploaded the new pat file without any problems in the process.

 

Just waiting for a hp-ams compiled for 6.2 ...

 

Probably will move to a DS3617xs in a few weeks, but as of today I'm too lazy to reinstall and configure every package ...

Edited by latpboe
  • Like 1
Link to comment
Share on other sites

Had some issues, booted up and I started up the migration using 1.03b and 3617, however after it says Installation Completing it will reboot and I can’t get back into it.

I can see it’s boots up and there is HDD activity, I can ping it however I can’t login with SSH or to the web browser.

Any ideas?

Specs are:

Motherboard - H77-D3H-MVP
CPU - i5 3450
Loader - 1.03b DS3617xs
Baremetal - Yes
SATA - Onboard Intel and a Marvell based 4 port SATA card.

Link to comment
Share on other sites

On 8/7/2018 at 1:58 AM, Saoclyph said:

@extenue, @Lennartt, @wenlez, @pateretou, @sashxp, @enzo, @dodo-dk

 

- Outcome of the update: SUCCESSFUL 

- DSM version prior update: 6.1.7 Update 2 with Jun's loader v1.02b

- Loader version and model: Jun's Loader v1.03b - DS3617

- Using custom extra.lzma: NO

- Installation type: VM Proxmox 5.2.6 - Xeon D-1537 (need to pass kvm64 cpu type), passthrough LSI SAS2116 with 5 x WD RED 3TB Raid5, 2 x WD RED 4TB Raid1 & 2 x Intel DC S3700 200GB Raid1

- Additional comments : SeaBIOS, loader on sata and ESXi boot line. Update to U2 ok. Had to replace/delete remnant files from older loaders in /etc/rc.*, /.xpenoboot (see last paragraph below).

 

Using the usb method, I got a "mount failed" as others on Proxmox, but it was successful when using a sata image disk:

  • rename the loader with a .raw instead of .img and place it in the VM images folder /var/lib/vz/images/100/ (Proxmox parser does not understand .img)
  • add a sata0 disk in the vm .conf (/etc/pve/qemu-server/100.conf)  : 

sata0: local:100/synoboot_ds3617_v1.03b.raw,size=52429K
  •  choose sata0 in Option/Boot Order in the GUI
  • at start in the GUI console, choose the ESXi boot line

  

My vm ID is 100, replace it with yours.

I also had to choose the kvm64 cpu type.

 

  Bonus: easy way to edit grub.cfg (Hide contents)

It easy to change the loader grub.cfg by mounting the loader image:



cd /var/lib/vz/images/100/
mkdir synoboot_mount
mount -o loop,rw,offset=$((2048*512)) synoboot_ds3617_v1.03b.raw synoboot_mount
vi synoboot_mount/grub/grub.cfg
# unmount it after editing
umount /var/lib/vz/images/100/synoboot_mount

 

 

A serial port is also a good thing to have for debug. You can access the serial console with the following line (type Ctrl-O to exit): 


socat UNIX-CONNECT:/var/run/qemu-server/100.serial0 STDIO,raw,echo=0,escape=0x0f

 

The serial port was very needed in my case.

After I first updated from 6.1 to 6.2, the VM was starting well (docker and ssh were Ok)  but I was not able to logging into DSM, and after ~5 mins from boot, everything was shutting down and I was losing network (as @JBark). I thought it had completely shutdown. But using the serial port, I saw that it just killed everything Synology related even the network config.

With a fresh VM, it was working well, so tried to find differences between the DSM filesystems.

I found that a lot of /etc/rc.* files where referencing old binaries that do not exist anymore so I replaced all the /etc/rc.* files by the ones from the fresh installation. When rebooting, it was still closing down after 5 mins, but I think it was needed in combination with the following removals.

I also saw several /etc/*.sh scripts, and a /.xpenology folder, that were not there in the fresh installation.

After deleting them, and cleaning a little the /etc/synoinfo.conf file (removed support_syno_hybrid_raid option, and some other options, not sure if it had an effect), everything was working great again!

 

@jun Thanks for the loader!

 

 

 

Oh yes!

 

thank a lot work great with the 1.03b jun loader on proxmox !!

 

Please note I had to use the "baremetal" choose in the grub loader to be able to see the SATA disk on my side (vmware/esxi was unable to find the sata harddrive)

update2 successfull too

Fresh install, no update on my side!

 

thank to all

Edited by Polanskiman
Changed .xpenology to .xpenoboot in the Additional comments line.
Link to comment
Share on other sites

1 hour ago, kpas said:

maybe you reboot to UEFI mode

 

I tried in BIOS mode and UEFI mode, same results.

 

1 hour ago, mmkt said:

 

I guess the CPU is actually to old, its an Ivy Bridge and its needed Haswell and newer....

 

 

It worked fine on the DS3617xs and DSM 6.1

 

Nobody seems to know for sure what the oldest supported version is.

 

Plus, if I can get the initial stage where we migrate the previous install then doesn't that mean it's compatible?

Link to comment
Share on other sites

16 minutes ago, chipped said:

It worked fine on the DS3617xs and DSM 6.1

 

Nobody seems to know for sure what the oldest supported version is.

 

 

I've read that haswell is needed, my Laptop with Sandy Bridge i7 doesn't even show "decpompress the kernel" after the "happy hacking" text in a virtual box boot window. . 6.1 is also working fine.....

Link to comment
Share on other sites

3 hours ago, chipped said:

Had some issues, booted up and I started up the migration using 1.03b and 3617, however after it says Installation Completing it will reboot and I can’t get back into it.

I can see it’s boots up and there is HDD activity, I can ping it however I can’t login with SSH or to the web browser.

Any ideas?

Specs are:

Motherboard - H77-D3H-MVP
CPU - i5 3450
Loader - 1.03b DS3617xs
Baremetal - Yes
SATA - Onboard Intel and a Marvell based 4 port SATA card.

 

i have a e3-1265L that is a Sandy Bridge and has no issue with ds3615xs or ds3617xs loader (i use ds3615xs because bromolow and packages), only newer ds916+ or ds918+ need haswell or later cpu.

try to reset the system and not migrate, it should work.

Link to comment
Share on other sites

i tried to install it completely new as VM on an HP MicroServer Gen8 with an E3-1230 V2 with ESXi 6.5 Update 2

i have an Xpenology Machine DS3615xs running with the 1.02b Loader just fine, but with the new 1.03b and DS3615xs bootloader it starts like the other one and stops on

[...]

Happy Hacking

It then should get an IP from DHCP but nothing happens... tried several restarts and also switching between UEFI and BIOS Mode even before starting the vm for the first time

it ran for over 10 Minutes between switching to ensure that it doesnt take some time to start all services etc...

 

also i tested with the VMware Workstation if i get it to work on my system, but same result... not detected in network

so before testing with the running one, i wanted the other VM to work and test it a bit

and yes i changed the MAC and SN in the config and started the installation as VM/ESXi version

 

hope somebody has a hint 

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