einsteinagogo

XPEnology NAS Loading error 17.

Recommended Posts

Booted my XPEnology NAS this evening, and it didn't boot, so after connecting a monitor to the server (which happens to be a HP MicroServer N36L)

 

I get a

 

Grub loading stage 1.5

 

Grub loading please wait……

 

Loading error 17.

 

This has worked perfectly for over 12 months.

 

using DS3612xs_3810-repack-trantor-v1.0.7.z.

 

The image is written to a USB flash drive, and I have 3 SATA disks in the server.

 

I thought I would just create a new USB flash drive, as I believe the USB flash drive contains the bootloader, but I also get an error, about loading the DSM....

 

Any ideas?

 

Do you think the disks have become corrupted ?

Share this post


Link to post
Share on other sites

As I understand it the common causes of an error 17 being thrown are hardware failure and a partitions mismatch with the order grub expects. You would need to diagnose your system to make sure everything is correct.

 

You're using an old insecure xpenology version so you could try migrating to the latest nanoboot xpenology package. If that works you maybe able to recover your system if the nas disks update OK. Obviously you should backup all your critical data before attempting that. If you have some spare disks you could experiment first using them. If that builds you could try inserting one of your current disks, and see if the DSM reports it as degraded and offers to repair it. There will be a chance of data loss so you will have to decide what to do at that point.

 

I'm no linux/xpenology guru so do your own due diligence.

Share this post


Link to post
Share on other sites

I dont really care about the version, many production systems with DSM 4.3.... it works!

 

I'll wait for the DSM 5.x versions to become stable before I upgrade or install.

 

puzzled that a new usb flash image does the same which may indicate a drive failure!

Share this post


Link to post
Share on other sites

Agreed it seems strange that a new USB stick resulted in an error 17? Maybe some linux expert can offer some explanation as to what's going on?

 

The latest nanoboot is rock solid I have had no issues running DSM 5.0-4528 Update 2 and it's an improvement both in function and security over earlier versions. You maybe waiting a while if you want to go directly to DSM 5.1. I guess it's no big deal if you're running your NAS on a private network and the old version meets your requirements. A migration may have offered a solution to your boot issue. Having said that if you're getting an error 17 with a new stick migration may not even be an option?

Share this post


Link to post
Share on other sites

I'm not a fan of the aesthetics either but that's hardly a reason not to update when the functionality and security is better. I don't give a shit what it looks like if it does the job and works as expected...which it does for me! Personally I wouldn't want to go back to the old version after getting used to the many improvements in DSM 5.0. It's your choice at the end of the day.

Share this post


Link to post
Share on other sites

" I don't give a shit what it looks like if it does the job and works as expected"

 

and the old version does that for me!

 

I may try a recovery or update, as a last resort to fix!

 

As for security, private network with no issues!

Share this post


Link to post
Share on other sites

I don't think an error 17 is an indication of the system working as expected? If you can't fix the grub issue and a fresh USB stick returns the same error your options seem somewhat limited if you want a functional machine. If you really want to stick with the old version you can always try a roll back if the migration allows you to recover the system. Like I said the choice is yours.

Share this post


Link to post
Share on other sites

I had a similar problem a few days ago. my newznab and spotweb stopped working and after everything else failed, I thought a reboot might fix things.

 

When it rebooted, I saw error messages and was no longer able to login or even use the keyboard on the console.

Turns out that something corrupted my root partition ( /dev/md0) so the only way I had to fix it was to reinstall syno.

From now on, I am making backups of that partition. I lost several databases in that partition (Probably the reason it crashed). Fortunately, that was backed up.

 

Try booting with something like SystemRescueCD and see if you can mount /dev/md0 (em dee zer0)

mkdir /tmproot
mount /dev/md0 /temproot
ls /temproot

 

If you can see your files, you might be able to find the problem and fix it without a reinstall.

You will not see volume1 there. You will have to mount that separate.

I don't recall where the system rescue cd put it, but I was able to find it under something like /dev/vg1

You may have to play with mdadm to get it mounted.

Other useful commands are

df

cat /proc/partitions

(Look for the largest one)

 

I plan to add a nightly dd backup of that partition, from now on, and also reconfiguring my databases to be on the main volume and not defaulting to one that might fill up and cause unintentional corruption.

dd if=/dev/md0 if=/pathto/mybackup/file

Share this post


Link to post
Share on other sites

Hello, Interesting tip. Hopefully it will help me out too.

 

While doing a rebuild /root got to 100% full. See here: viewtopic.php?f=2&t=5292

 

I've managed to get to volume1 but can not get to root. I've tried your suggestion but I do not seem to have /dev/md0.

 

I'm using Ubuntu 14.04 Live CD and will try SystemRescueCD next. Hopefully it will allow me to mount /root.

 

Chris

Share this post


Link to post
Share on other sites

Hmmm.. I'm getting an error during mount.

 

mount: /dev/md0: can't read superblock

 

I've been considering an upgrade to XPEnoboot anyway. Is a reinstall safe with DSM in semi-broken state?

 

Thanks

Chris

Share this post


Link to post
Share on other sites
I don't recall where the system rescue cd put it, but I was able to find it under something like /dev/vg1

 

SystemRescueCD put this in /dev/dm-0

 

mkdir /v1_recovery

mount /dev/dm-0 /v1_recovery

 

or..

 

mount /dev/mapper/vg1000-lv /v1_recovery

 

Provides access to the Synology volume in /v1_recovery

 

Pretty cool actually an makes it really easy to pull the data out but I would really love to repair root. trying to find out why it can not read the superblock now. Any/all suggestions welcome.

Share this post


Link to post
Share on other sites