einsteinagogo Posted December 30, 2014 Share #1 Posted December 30, 2014 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 ? Link to comment Share on other sites More sharing options...
CtrlAltDel Posted December 30, 2014 Share #2 Posted December 30, 2014 That is a grub error 17 here's the gentoo explanation https://wiki.gentoo.org/wiki/GRUB_Error_Reference#Grub_Error_17. You could try and repair the grub or make a new USB boot stick and see what happens. Link to comment Share on other sites More sharing options...
einsteinagogo Posted December 30, 2014 Author Share #3 Posted December 30, 2014 I'd worked out it was a Grub error! I've re-created a new USB flash drive using the image and still an issue, as per my OP! Link to comment Share on other sites More sharing options...
CtrlAltDel Posted December 31, 2014 Share #4 Posted December 31, 2014 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. Link to comment Share on other sites More sharing options...
einsteinagogo Posted December 31, 2014 Author Share #5 Posted December 31, 2014 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! Link to comment Share on other sites More sharing options...
CtrlAltDel Posted December 31, 2014 Share #6 Posted December 31, 2014 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? Link to comment Share on other sites More sharing options...
einsteinagogo Posted December 31, 2014 Author Share #7 Posted December 31, 2014 personally I'm not a FAN of the child interface in 5! Link to comment Share on other sites More sharing options...
CtrlAltDel Posted December 31, 2014 Share #8 Posted December 31, 2014 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. Link to comment Share on other sites More sharing options...
einsteinagogo Posted December 31, 2014 Author Share #9 Posted December 31, 2014 " 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! Link to comment Share on other sites More sharing options...
CtrlAltDel Posted December 31, 2014 Share #10 Posted December 31, 2014 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. Link to comment Share on other sites More sharing options...
toobueller Posted January 1, 2015 Share #11 Posted January 1, 2015 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 Link to comment Share on other sites More sharing options...
quicksilver Posted February 18, 2015 Share #12 Posted February 18, 2015 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 Link to comment Share on other sites More sharing options...
quicksilver Posted February 18, 2015 Share #13 Posted February 18, 2015 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 Link to comment Share on other sites More sharing options...
quicksilver Posted February 18, 2015 Share #14 Posted February 18, 2015 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. Link to comment Share on other sites More sharing options...
Recommended Posts