meimeiriver
-
Posts
104 -
Joined
-
Last visited
Posts posted by meimeiriver
-
-
2 hours ago, flyride said:
This is often a point of confusion. The "surplus disk" is exactly that, a test disk that is often cited in ESXi installation tutorials, and it properly being offered to use as a possible storage device. If you aren't using your 16GB virtual test disk, just delete it.
The loader is a 50MB image and should not be visible (although there are ways of defeating that too even if synoboot is built correctly).
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.
-
23 hours ago, flyride said:
As long as your synoboot device is accessible (verify it per the synoboot script page), you should be able to install the update 3 file as you cite, via the GUI. If for some reason it does not work, it will just be rejected and your system should not be damaged.
https://xpenology.com/forum/topic/37652-dsm-623-25426-update-3/
https://xpenology.com/forum/topic/28183-running-623-on-esxi-synoboot-is-broken-fix-available/
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.gz2 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?
-
14 hours ago, flyride said:
I think you were trying to reuse an boot loader image file. When an install occurs, the loader itself is modified. So if you are trying to do a clean install, you need to extract a clean, new copy of the loader and edit grub.cfg as appropriate. Editing the serial number probably did the same thing, although it would not have worked if you were trying to install an older version than had been encountered by that loader before.
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?
-
34 minutes ago, flyride said:
I think you were trying to reuse an boot loader image file. When an install occurs, the loader itself is modified. So if you are trying to do a clean install, you need to extract a clean, new copy of the loader and edit grub.cfg as appropriate. Editing the serial number probably did the same thing, although it would not have worked if you were trying to install an older version than had been encountered by that loader before.
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.
-
1 hour ago, flyride said:
It shouldn't be "created" by VM, you should be using it from the loader. Did you use a clean, fresh loader image file?
Did you remember to select the GRUB ESXi option on boot? If you use the default the img disk will be visible for install.
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).
-
1 hour ago, flyride said:
This isn't an issue for a new install, only after the system is up and running. See my comments on your other post.
Finally got it going now. Will add the script provided.
-
59 minutes ago, flyride said:
It shouldn't be "created" by VM, you should be using it from the loader. Did you use a clean, fresh loader image file?
Did you remember to select the GRUB ESXi option on boot? If you use the default the img disk will be visible for install.
This is irrelevant for a image file install
That points back to an incorrect GRUB selection above.
The "trick" to hide the boot disk under ESXi has not changed. The boot disk is flagged incorrectly at bootup which is where FixSynoBoot script offers a solution. This is not a issue for the initial install and has nothing to do with whether the boot drive is visible on that install.
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.
-
On 6/15/2021 at 5:14 AM, JoeOIVOV said:
Thank you, I was able to update to 6.2.3-25426 Update 3 after applying/rebooting with this script. Can't update beyond that, but it helps..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.
-
1 minute ago, flyride said:
1.02b is the loader for 6.1 through the latest, 6.1.7. It works fine with ESXi.
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).
-
1
-
-
19 hours ago, Designator said:
That´s what I did last night.
Just for your information I´m running a baremetal Intel machine.
My starting point was DSM 6.1.1-15101 Update 4 with Jun 1.02a2 bootloader for ds3617xs.
I placed the new bootloader 1.02b onto my current usb stick, edited the grub.cfg and plugged it back in without updating DSM.
It booted and asked my to "recover" my old installation. This step took 1 or 2 seconds, it then rebooted itself.
DSM came back up just fine. I then went on to upgrade DSM to the latest version 6.1.2-15132. Rebooted and it´s now running peacefully since then.
Just to give you guys some feedback.
Big thanks to Jun for his amazing loader
Greetz,
Desi
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.
-
2 minutes ago, foxbat said:
again - clean install works perfect on 6.5
Sorry, missed that. I thought I saw someone say it worked on bare metal.
-
6 hours ago, jun said:
its an old script bug due to my oversight, I am uploading a new version to fix it, hopefully without introduce new bugs
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?
-
1 hour ago, mcdull said:
No, you cannot. You need to re-format the volume for a different file system
Okay, thx.
-
45 minutes ago, mcdull said:
update always result in recovery mode. Need clean install everytime.
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.
-
10 minutes ago, ad911 said:
DSM 6.1.2-15132
https://www.synology.com/en-global/releaseNote/DS3615xs
bootloader 1.02a, for DS3615sx
updated from DSM 6.1.1-15101 Update 4 to DSM 6.1.2-15132
so far no problem
Thanks! That's what I needed to hear!
-
13 hours ago, Masrawy said:
I have 6.1.1-15101 Update 4 with no issue since it was released
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.
-
12 hours ago, meimeiriver said:
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.
Can someone please answer this too?
-
28 minutes ago, jitesh_88 said:
i noticed my volume is ext4, is there a way to upgrade it to btrfs or do i need to delete the volume and create a new one?
I dont want to loose my data
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.
”Failed to install the file. The file is probably corrupted. (13)"
in General Installation Questions/Discussions (non-hardware specific)
Posted
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.