gnoboot

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. 2. Enable serial logging on your VM and send me the results - http://kb.vmware.com/kb/2009269

You can still try your luck using http://www.cgsecurity.org/wiki/TestDisk to recover the volumes as long as you don't overwrite the disk with new data.

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

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.

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.

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

Upcoming will release will support zram on v5. gnoboot running RS3612xs+ pat file [spoiler=]

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. EDIT: Set ihd_num to 1 only to avoid bootup delays.

yes, follow this guide - http://xpenology.com/forum/viewtopic.php?f=2&t=2049 EDIT: Uploaded new ramdisk to support more drivers and network cards, get it on my main thread

extract the spk using tar, then extract packages.XXX again to root directory.

The process is already in page one. Are you getting errors, installing on a VM/baremetal? Please post a screenshot and dmesg results.

Synoboot device is already emulated in my build;) So the outstanding process is generate the vender file every reboot/installation to match the real mac address. I know there are programs created by the community members but code is not available.

Wait, is the vender file even required? On the original boot disks, it was possible to pass the MAC address via a console argument in GRUB - couldn't we do the same? No, DSM still reads the vender file from the /dev/synoboot2 eveytime iSCSI starts/restarts.

If I knew the format boot parameter is no longer needed . The format is relatively simple. There's a 4-character device ID (B1J1 for DS411, B3J7 for RS2211+, etc., still collecting the database), followed by a 5-digit number (00001 to 99999), the actual serial number. I think, after collecting all the device IDs, it would be possible to easily change the device serial number, even with an actual Synology app. hahaha, so it's useless. My current grub.conf doesn't include the serial and its working perfectly. I need to generate the vender file, so iSCSI won't use the default mac addresss. How can you generate it from scratch? Working on fixing ssd detection for virtual disk

This is very good What kind of patch did you apply to fix this ? Backport the LIO stack from 2.6 branch ? BTW very nice scripting work For now, I'd like to keep it a secret until dsgpl 4418 is release . EDIT: [spoiler=]Let's see if they're going to include the LIO source code. I don't want them to add another security layer if XPENOLOGY is working on v5 .

iSCSI working! See my main thread .

If I knew the format boot parameter is no longer needed . Another successful hacking day! I broke iSCSI file level while building alpha3 but got both file and block level working after applying some kernel patch .

Copy the following to your grub.conf: #serial --unit=0 --speed=115200 #terminal serial default 0 timeout 10 fallback 0 title gnoboot 4.3-8310 - alpha root (hd0,0) kernel /zImage root=/dev/md0 ihd_num=0 netif_num=0 syno_hw_version=DS3612xs sn=B3JN00310 vga=0x370 loglevel=3 initrd /rd.gz title gnoboot 4.3-8310 - alpha (debug) root (hd0,0) kernel /zImage root=/dev/md0 ihd_num=0 netif_num=0 syno_hw_version=DS3612xs sn=B3JN00310 vga=0x370 debug initrd /rd.gz title gnoboot 4.3-8310 - alpha (vender) root (hd0,0) vender /vender show kernel /zImage root=/dev/md0 ihd_num=0 netif_num=4 syno_hw_version=DS3612xs sn=B3JN00310 vga=0x370 initrd /rd.gz

Yes, it doesn't use vender file. I will include the default serial number from the vender file on the next release. Does anybody know the serial number format? EDIT: Upcoming feature, alpha3 modular ata drivers [spoiler=]

How would modules work? Would you then need to add/remove a particular module for lets say in my case IDE, at initial boot, prior to installing? http://en.wikipedia.org/wiki/Loadable_kernel_module For virtual machines, gnoboot image will not add any ATA drivers but you can still have an option to load it after installation. But this would bring problems to baremetal users during installation if drivers are not available. EDIT: modular ATA drivers working - http://xpenology.com/forum/viewtopic.php?f=2&t=2152&p=11010#p11010

Me too. Anyway, I'm working on getting all the ATA drivers as modules. Or I would build a separate virtual boot image which doesn't include all the useless drivers with exception to RAID controllers. Would that be ok?

make sense to me, have you tried using SCSI as boot image? One of my test machines uses SCSI and it maps to sdaeX.

No thanks (on USB stick), but there must be better way to do it. I'm not complaining, or trying to create work for you. I figure you made gnoBoot cause you like to create and fix stuff I have another ESXI system. It's my main system and has been running for over 6 months on DSM 4.2. It's not based on trantor's builds, its step by step from the ESXI pdf someone made. Anyway, that VM doesn't mount boot as sda. sda is the first data disk. So there must be a way to do it BusyBox v1.16.1 (2013-03-01 01:11:47 CST) built-in shell (ash) Enter 'help' for a list of built-in commands. DiskStation> cat /proc/partitions major minor #blocks name 8 0 1953514584 sda 8 1 2490240 sda1 8 2 2097152 sda2 8 3 1 sda3 8 5 1948780864 sda5 8 16 1953514584 sdb 8 17 2490240 sdb1 8 18 2097152 sdb2 8 19 1 sdb3 8 21 1948780864 sdb5 8 32 1953514584 sdc 8 33 2490240 sdc1 8 34 2097152 sdc2 8 35 1 sdc3 8 37 1948780864 sdc5 8 48 1953514584 sdd 8 49 2490240 sdd1 8 50 2097152 sdd2 8 51 1 sdd3 8 53 1948780864 sdd5 9 0 2490176 md0 9 1 2097088 md1 9 2 5846338944 md2 253 0 5846335488 dm-0 DiskStation> Yes, there is. Use alpha0 kernel and update the rd.gz from alpha2;) You can also put your gnoboot on the last port for SATA/SCSI disk, so it won't become sda. Edit: Changing disk port order in your VMX file. before: sata0.present = "TRUE" sata0:0.present = "TRUE" sata0:0.fileName = "gnoboot-0.vmdk" <---- boot image sata0:0.redo = "" sata0.pciSlotNumber = "36" sata0:1.present = "TRUE" sata0:1.fileName = "gnoboot-1.vmdk" after: sata0.present = "TRUE" sata0:0.present = "TRUE" sata0:0.fileName = "gnoboot-1.vmdk" sata0:0.redo = "" sata0.pciSlotNumber = "36" sata0:1.present = "TRUE" sata0:1.fileName = "gnoboot-0.vmdk" <---- boot image

sda is gnoboot;), unless you want to stick usb on your VM Another issue, mac address is random in v5. Will fixed it at a later time. Enjoy my build!

The kernel was built from scratch with Andy's patches and mine. It's very different from Trantor's boot image and kernel.