meimeiriver
-
Posts
104 -
Joined
-
Last visited
Everything posted by meimeiriver
-
I'm sorry I said that. It looked surplus in Storage Manager, as just a spare 16 GB VM drive, but appeared vital after all. Not sure what's going on. Now, only 50 MB disk is listed as 'uninitialized,' and the 16 GB drive is gone. I'm going to leave it like that. I should simply count my blessings, and leave well enough alone.
-
Now my NAS won't start up any more. ;( "Operating system not found" That was some bad advice. EDIT: I had to redo the entire process, and now my NAS is working again, but shows the extra 50MB drive (instead of the 16G one). I'm not going to mess with it any more.
-
Not that it hugely matters, but the surplus disk remains visible in Storage Manager (after reboot, before you ask); and is called 'Vmware Virtual Sata Hard Drive, 16 GB.' And script was placed correctly: admin@Xpenology:/$ cd /usr/local/etc/rc.d/ admin@Xpenology:/usr/local/etc/rc.d$ ls -la total 12 drwxr-xr-x 2 root root 4096 Aug 21 20:33 . drwxr-xr-x 10 root root 4096 Aug 21 13:34 .. -rwxr-xr-x 1 root root 2161 Aug 21 20:33 FixSynoboot.sh admin@Xpenology:/usr/local/etc/rc.d$
-
So, I tried to change the ridiculous mouse-over color from DSM 6.2.3, changing ux-all.css -r--r--r-- 1 root root 246136 Aug 22 00:25 ux-all.css lrwxrwxrwx 1 root root 58 Aug 21 23:38 ux-all.css.gz -> /usr/syno/synoman/scripts/ext-3.4/ux/ux-all-default.css.gz -rw-r--r-- 1 root root 246136 Aug 21 23:38 ux-all-default.css -rw-r--r-- 1 root root 22091 Aug 21 23:38 ux-all-default.css.gz -rw-r--r-- 1 root root 375716 May 12 2020 ux-all.js -rw-r--r-- 1 root root 97145 May 12 2020 ux-all.js.gz -rw-r--r-- 1 root root 27168 May 12 2020 ux-encrypt.js -rw-r--r-- 1 root root 9493 May 12 2020 ux-encrypt.js.gz root@Xpenology:/usr/syno/synoman/scripts/ext-3/ux# rm ux-all-default.css root@Xpenology:/usr/syno/synoman/scripts/ext-3/ux# ln ux-all.css ux-all-default.css root@Xpenology:/usr/syno/synoman/scripts/ext-3/ux# ls -la total 808 lrwxrwxrwx 2 root root 55 Aug 22 00:27 ux-all.css -> /usr/syno/synoman/scripts/ext-3.4/ux/ux-all-default.css lrwxrwxrwx 1 root root 58 Aug 22 00:27 ux-all.css.gz -> /usr/syno/synoman/scripts/ext-3.4/ux/ux-all-default.css.gz lrwxrwxrwx 2 root root 55 Aug 22 00:27 ux-all-default.css -> /usr/syno/synoman/scripts/ext-3.4/ux/ux-all-default.css -rw-r--r-- 1 root root 22091 Aug 22 00:27 ux-all-default.css.gz 2 minutes later, as you can see, DSM has had the audacity to revert my changes! Dafuq?! How can I break through this passive-aggressive wall of opposition, and get DSM to accept normal mouse-over colors that don't look the same as the background color?
-
If I may call on you once more, what if I want to install DSM 6.2.3-25426, Update 3 now? It appears to be synology_apollolake_918+.pat (37,914 KB), and looks to be an 'incremental' patch, rather than a full DSM. Can I install that right over it, or will that hose my machine as well?
-
Yeah, that's exactly what happened. Didn't realize you needed a fresh loader. The changed serial number likely wasn't even necessary, but I simply 'accidedntally' took a new loader to try again with a different serial number.
-
For the record, I used this menu entry: menuentry "DS918+ 6.2.1/6.2 VMWare/ESXI $VERSION" --class os { set img= savedefault loadlinux 918 sata loadinitrd showtips } The other 2 were for bare metal (not applicable to my ESXi situation). So I had removed those (as per I had read somewhere here).
-
Running 6.2.3 on ESXi? Synoboot is BROKEN, fix available
meimeiriver replied to flyride's topic in DSM 6.x
Finally got it going now. Will add the script provided. -
I wasn't able to install the DSM at all (so, no attaching a script for me). Fortunately, I just resolved the matter. Edited a new grub.cfg, with a different serial number, and voila, DSM would install again. Makes no sense to me, really (as my old disk set worked just fine), but it worked. Yeah, wasn't sure about the visible boot disk, as Synology first said it wanted to format 7 drives (1 boot + 6 nas drives), so I figured it might trip over that extra disk. Glad to hear it has no bearing on anything (except visual), so I will add the script to hide it now. Thanks.
-
Running 6.2.3 on ESXi? Synoboot is BROKEN, fix available
meimeiriver replied to flyride's topic in DSM 6.x
How can you attach a script to a DSM that hasn't even been installed yet? I replaced all my hard drives, went for 6.2.3-25426 Update 3 again, and get the infamous "Failed to install the file. The file is probably corrupted. (13)" error (ESXi 7.0.U2). My guess is because Synology sees the 50MB boot device, and wants to use it; but it can no longer be hidden. -
Coming from DSM_DS918+_25426 (jun loader 1.04b, under ESXi 7.0.2), I replaced all my 6 hard drives with new ones, as many exhibited bad sectors. So, put new disk in, found disk station, and loaded the DSM 6.2.3-25426.pat file again. But at ca. 65% system says ”Failed to install the file. The file is probably corrupted. (13)" Googling about it, ppl are suggesting VID/PID is may be incorrect, but those haven't changed at all, and the system is booting. I don't understand this at all. All I did was replace my drives (with WD Red Plus ones). What is possibly going wrong here? N.B. Synology is seeing my 50 MB boot disk too (created by VM). That was the case on my previous install too. I read that on 6.2.3, the trick to hide the boot disk from Synology doesn't work any more; but it didn't give me trouble before.
-
I'm still running DSM 6.0.2-8451 Update 9 (ESXi). So, apparently -- as per this thread -- there's a 1.04b jun loader, capable of loading 6.2, after all. So, does an .ovf for ESXi exist yet? Or, if not via an .ovf, does anyone have 6.2 running on their ESXi install? I'd really love to run 6.2 (improved/fixed Btrfs, auto RAID-scrubbing, etc). Thanks.
-
Thx.
-
I'm currently running DSM 6.0.2-8451 Update 9, on a virtual DS3615xs (ESXi). I saw the warning not to load version 6.2; so, what's the latest 6.1 version I can safely install with loader v.1.02b? And does an ESXi install package exists for it yet? I have an Intel i7 CPU. Thanks.
-
Currently on ESXi 6.5, on a virtual DS3615xs. I certainly wouldn't mind if someone made an OVF template one day, with this (or higher model) server, with built-in 6.1.3-15152-1 Update (or upgradeable to it).
-
But he asked for an update to the latest, from DSM 6.0.2-8451 Update 11, without data loss. That's not going to happen, as they changed the file system.
-
Sorry, missed that. I thought I saw someone say it worked on bare metal.
-
Thanks! Will the new loader be able to support DSM 6.1.2-15132 (as clean install) on ESXi 6.5?!
-
Okay, reformat needed (when coming from DSM 6.0.2-8451 Update 9). Check. My remaining question then is, can DSM 6.1.2-15132 be (safely) installed on ESXi 6.5 at all yet?
-
Okay, thx.
-
So, it looks like I really have to wait for a new loader then, in order to upgrade from DSM 6.0.2-8451 Update 9 (ESXi 6) to the latest shiny.
-
Thanks! That's what I needed to hear!
-
Hmm, didn't they have like a new file system format? (Or at least one that was incompatible with 6.0.2 Brtfs) I recall reading something about that. So, you just deployed jun's loader, installed 6.1, upgraded to latest version, and were able to mount your existing Btrfs? Cuz that would be ideal.
-
Can someone please answer this too?
-
And now the only remaining question is, whether we can upgrade to 6.1.1-15101 Update 4 too, without data loss. N.B. My 6.0.2-8451 install was already on Brtfs.
