Jump to content
XPEnology Community

XPEnology gnoBoot


gnoboot

Recommended Posts

Hi thommy86 are you talking about what version of dsm? 5.0 beta or 4.3? for what i know 4.3 works fine on usb stick, version 5.0 beta, i dont know, i'm using it on VM

installation it's' simple, download trantor distro, http://xpenology.trantor.be/xpenology.com/c0643dac6b8fc2fbd6c3f9a1514b9b69/52e68337/XPEnology_DS3612xs_3810-repack-trantor-v1.0.7z

download original .pat file from synology web.

Use some img writer to write trantor img file on usb stick, put usb stick on real pc, boot from usb, download synology assistant, install, discover new dsm system, click on it, and use original .pat file already downloaded, wait, reboot, enjoy :smile:

Link to comment
Share on other sites

Alpha3 ramdisk and kernel available, get it from page one and don't forget to check the change log.

 

There's a 10 seconds delay "Enable Synology SATA fast booting" when booting up the kernel . This is not a kernel issue, default gnoBoot grub.conf is set to empty ihd_num. You have to change ihd_num value to the number of disk attached in your gnoBoot system. Don't change it to higher value than your available disk as it add more delays.

 

title gnoboot-4.3-8310 - alpha

root (hd0,0)

kernel /zImage root=/dev/md0 ihd_num=1 netif_num=0 syno_hw_version=DS3612xs sn=B3JN00310 vga=0x370 loglevel=3

initrd /rd.gz

 

EDIT: Set ihd_num to 1 only to avoid bootup delays.

Edited by Guest
Link to comment
Share on other sites

I'm not sure if I removed ata_piix.ko correctly so my VM of DSM doesn't see ata controllers, and start the raid array at slot 3, but I got it to work I guess. I booted into gnoboot (after putting in new zImage and rd) and logged into root and renamed ata_piix.ko to ata_piix.ko.old at /lib/modules/ then reboot and proceeded to install.

 

With no other VM drives (but gnoboot), the installer still says it sees one disk. At console, cat /proc/partitions returns /dev/sda (which I guess is gnoboot still, and why the installer sees 1 disk). But it can't install to it, which is good - gets an error. With an additional disk the installer says it sees 2 disks, but proceeds to install to just the one, and it installed to slot 1 :grin:

 

6ud8MFS.png

Link to comment
Share on other sites

I just successfully migrated 10 disks from an earlier version of gnoboot to the latest for dsm 5 (alpha1). Then 2 more disks, one blank, and one used as a single disk dsm install. It successfully migrated both my 10 disk array, and had an additional volume from the 1 disk dsm install, as well as the one blank disk. I was able to remove volume 2, and add the other 2 disks to my array for a total of 12. It retained all my data too :grin:

 

something I noticed, is when gnoboot/dsm detects disk changes on boot it will do some stuff then shutdown. you have to manually restart it, then all is good.

Link to comment
Share on other sites

I think this has something to do with /etc/upgrade.sh. Could you post a screenshot while it happens?

 

 

Here's the best I can do, since it floods the screen with stuff. When it detects a disk change (add/remove), synocfgen fails. On normal boot, synocfgen follows after last module load, and is close to one of the last things displayed before login prompt. When it detects a disk change, there's a bunch of stuff between last module load, and the synocfgen check, then a bunch of stuff after it, it unmounts all the drives and powers off. You can reproduce it easily by just adding and removing same disk over and over (i created a tiny disk for testing).

 

z2UCq0l.png

 

edit: it took me a bunch of reboots to get it to boot normally again. Here's what it looks like at first normal boot after going through all that stuff:

 

6Rny3NF.png

Link to comment
Share on other sites

Tried to remove a disk on v5, but I got degraded volume, and then rebooted the system. Once it booted, I added the disk again, and then rebooted again. But I wasn't able to reproduce the same power off scenario. Did you migrate/upgrade using 1 disk with v5 installed and added v4 disk?

 

I made another test by copying an older v4 disk with v5 installed on one disk. Got DSM alert that file system error has happened and needs to be rebooted. I had to forced reboot as it never responded with a kernel traceback displayed on the console. Tried to reboot a few times but it keeps on alerting me. My advice is migrate your disk from v4 to v5 using SA only. I can confirm this without losing your data volume.

Link to comment
Share on other sites

Tried to remove a disk on v5, but I got degraded volume, and then rebooted the system. Once it booted, I added the disk again, and then rebooted again. But I wasn't able to reproduce the same power off scenario. Did you migrate/upgrade using 1 disk with v5 installed and added v4 disk?

 

I made another test by copying an older v4 disk with v5 installed on one disk. Got DSM alert that file system error has happened and needs to be rebooted. I had to forced reboot as it never responded with a kernel traceback displayed on the console. Tried to reboot a few times but it keeps on alerting me. My advice is migrate your disk from v4 to v5 using SA only. I can confirm this without losing your data volume.

 

All my playing has been with DSM 5 w/ gnoboot.

 

Here's a summary of steps I took:

 

1) VM #1, with 10 disk array using gnoboot alpha 0 for DSM 5 working okay (just couldn't use slots 1 and 2 - they were reserved for IDE controller)

2) created new VM #2 w/ gnoboot alpha 1 for DSM 5 w/ single disk.

3) powered down VM #2, removed single disk. Added 10 disk array from VM #1.

4) booted up VM #2, saw weird stuff shown in my screen caps from previous post. gnoboot turns itself off.

5) booted up VM #2, it boots fine. I verify my test data is still there. It was.

6) shut down VM #2, added 2 more disks. One blank, the other from my initial test of VM #2.

7) booted VM #2, saw wierd stuff again. gnoboot turns itself off.

8) booted VM #2 again, all good. Booted into DSM, all 12 disk shown in the 12 slots. Now have volume 2 from since one of the drives had data from initial tests of VM #2.

9) deleted volume 2 with DSM disk managment. Expanded volume 1 from 10 disk array to 12 disk array. All good, data still there.

10) shut down VM #2 . Create 13 disk for testing the weird shutdown at boot.

11) booted VM #2, saw same stuff I been seeing. gnoboot turns itself off. I removed disk 13 from array.

12) repeat steps 10-13 to see weird stuffs.

 

None of my testing consisted of removing a drive already in the array. Just added new drives (additional) to VM and rebooting. All disks added were when power was off (VM off). All my disks are virtual disk just for testing.

Link to comment
Share on other sites

Tried to remove a disk on v5, but I got degraded volume, and then rebooted the system. Once it booted, I added the disk again, and then rebooted again. But I wasn't able to reproduce the same power off scenario. Did you migrate/upgrade using 1 disk with v5 installed and added v4 disk?

 

I made another test by copying an older v4 disk with v5 installed on one disk. Got DSM alert that file system error has happened and needs to be rebooted. I had to forced reboot as it never responded with a kernel traceback displayed on the console. Tried to reboot a few times but it keeps on alerting me. My advice is migrate your disk from v4 to v5 using SA only. I can confirm this without losing your data volume.

 

All my playing has been with DSM 5 w/ gnoboot.

 

Here's a summary of steps I took:

 

1) VM #1, with 10 disk array using gnoboot alpha 0 for DSM 5 working okay (just couldn't use slots 1 and 2 - they were reserved for IDE controller)

2) created new VM #2 w/ gnoboot alpha 1 for DSM 5 w/ single disk.

3) powered down VM #2, removed single disk. Added 10 disk array from VM #1.

4) booted up VM #2, saw weird stuff shown in my screen caps from previous post. gnoboot turns itself off.

5) booted up VM #2, it boots fine. I verify my test data is still there. It was.

6) shut down VM #2, added 2 more disks. One blank, the other from my initial test of VM #2.

7) booted VM #2, saw wierd stuff again. gnoboot turns itself off.

8) booted VM #2 again, all good. Booted into DSM, all 12 disk shown in the 12 slots. Now have volume 2 from since one of the drives had data from initial tests of VM #2.

9) deleted volume 2 with DSM disk managment. Expanded volume 1 from 10 disk array to 12 disk array. All good, data still there.

10) shut down VM #2 . Create 13 disk for testing the weird shutdown at boot.

11) booted VM #2, saw same stuff I been seeing. gnoboot turns itself off. I removed disk 13 from array.

12) repeat steps 10-13 to see weird stuffs.

 

None of my testing consisted of removing a drive already in the array. Just added new drives (additional) to VM and rebooting. All disks added were when power was off (VM off). All my disks are virtual disk just for testing.

 

I will try what you did. BTW, default configuration is set to maximum 12 disks only while I've changed it to 14 when I did my test. That's maybe the reason why its turning off.

Link to comment
Share on other sites

Tried both versions (3810 and 4418) with latest rd.gz and zImage on real hrdw: 1155 itx board with celeron and hdd on onboard sata (gnoBoot image is situated on usb flash). Both of them work.

 

But there is a problem the same as with Trantor's 3810 builds. I need sil3132 sata card to work with two synology dx510 enclosures. If I load gnoBoot with enclosure powered on - it crashes and hangs. If I load gnoBoot with enclosure powered off - it boots normally. But when I turn on dx510 - it crashes (but not hangs in this situation).

 

As I already said - the same as in Trantors's 3810. But this configuration works flawlessly with Trantor's 3211 r1.2 build. I do not have any ideas why...

 

And I have a question. What should be changed to change hardware version? As far as I understand there are several change points:

1. Parameter in grub.cfg.

2. Byte in stage2 (I am not sure).

3. Byte in synobios.ko in rd.gz.

4. Text values in /etc/version and /etc/synoinfo.conf (not sure if it really necessary).

 

Anyway I tried changing all of this stuff but it resulted in "RS3411Rpxs" as for SA opinion. But I wanted it to become DS1511+... Can you give me any advise on correct procedure of changing version to DS1511+? Or 1512+, or 1513+, or 1812+, or 1813+. You see, I want to try any of DS version that should work with dx510 officially.

Link to comment
Share on other sites

Turns out... gnoBoot doesn't support switching from trantor's repacked ESXi...

I lost all my data on my first disk...

That's very sad, can you tell us what steps you use to switch from trantor's image?

1. I have an vm already running trantor's DSM 4.3, but the CIFS is broken and it act weird when connected to a USB sound card so I decided to switch, I have two physical disks attached to it, both were in basic mode. The boot device is an IDE vmdk provided by trantor.

2. I use fedora livecd to write gnoBoot 4.3 alpha2 into my boot device, aka the vmdk.

3. Tried to boot.

4. Disk 1 showed up as "not initialized". Disk 2 was OK.

5. I switch back to trantor's ESXi 1.1 vmdk.

6. No luck, Disk 1 sill "not initialized".

7. I think I shouldn't try Disk 1 on my 713+ in order to prevent further damage. I'll connect it to a Fedora in order to see whether LVM volume still exist. Hope I still have some luck.

8. Since DSM store installed packages and their configuration within my Disk 1, they are all gone for sure now...

9. Don't do what I do, value your data.

Link to comment
Share on other sites

My post also might be helpful in getting back your missing data : http://forum.cgsecurity.org/phpBB3/foun ... t2600.html . I got a bunch of help from Remy, and was able to figure out some stuff on my own when his suggestions didn't work as expected. So I figured I'd post my step by step experience in case it's helpful to anyone :smile:

 

I never was able to repair my partition tables so DSM worked correctly. But I was able to manually reassemble my array, then get all my data off my drives and build a new virtual DSM system.

Link to comment
Share on other sites

Diverge, since you're the only one who can reproduce the issue. Can you do me a favor?

 

1. Edit your grub with the highlighted settings.

serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1

terminal --timeout=5 serial console

default 1

timeout 10

fallback 0

 

title gnoboot-5.0-4418 - alpha (debug)

root (hd0,0)

kernel /zImage root=/dev/md0 ihd_num=1 netif_num=0 syno_hw_version=DS3612xs vga=0x370 debug console=ttyS1,115200

initrd /rd.gz

 

 

2. Enable serial logging on your VM and send me the results - http://kb.vmware.com/kb/2009269

Link to comment
Share on other sites

gnoboot, i'll try what you said and see if I can get the logs to you.

 

I also just saw that a decent amount of people are losing their partitions when updating from dsm 4.x to 5, and it's supposedly a bug that synology will fix http://forum.synology.com/enu/viewtopic ... 32&t=79886 . Just a heads up for people paying around with drives with unbacked up data :razz:

Link to comment
Share on other sites

Don't forget to boot on the debug option:)

 

edit: Something is weird with my VM, it keeps powering off. I might just delete it all and start fresh. But I have a log for you if you're curious with what might be going on.

edit2: gnoboot, I PMd you the link to logs. They were too big to send in a message.

Link to comment
Share on other sites

gnoboot,

 

nope, i never changed that in grub.

 

I'm playing with fresh VM, newly assembled gnoboot (rd, zImage), with the same array. whats the correct way to keep ata_piix from loading? Last time I mounted rd and just renamed it... not sure if that is the correct way to do it.

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