jagwaugh

Yes, with that extra.lzma it now appears on the network.

Hello, I've been running xpeno baremetal for a few years now. Yesterday I went to update from the last nanoboot to Jun's loader (Thanks for the work Jun!). I went through the procedure in the tutorial (Thanks Polanskiman!). Boot is fine, but the box does not appear on the net. Mobo is an older Geforce with an onboard Nvidia NIC (forcedeth). Is the nvidia NIC driver included in the drivers with Jun's loader? Is anyone else using Jun's loader and an Nvidia Nic?

/var/log should have vbox.log for the current boot and vbox.log.N for the previous 10 boots. This file contains detail information. vboxscripts.log (just one) This file just contains the start and stop of the guest VMs. see viewtopic.php?f=15&t=5350#p32723 have a look at /var/packages/virtualbox/target/etc/vbox/vbox.cfg, mine contains VBOXWEB_LOGFILE=/var/log/vbox.log Andrew

AHA.... I didn't realize that was already there in 5.1. In that case, it probably isn't the issue.

I see lots of error messages relating to avahi. Concentrating on them for the moment. The OS seems to boot and detect hardware etc just fine, so it may be a relatively minor thing. Did you notice the platform.ini file in the .pat? It may also be that the xpeno boot image gets left behind when the dsm52 tries to update the firmware. Andrew

I've been trying to install this in a VM... seems to lose the network somehow. I can login on the console, and ifconfig indicates that it is obtaining a dhcp lease, but synology assistant can't find it after the reboot, and the web interface on port 5000 isn't there either. Andrew

Mittel, I have imported .odf files created with both the previous DSM/Virtualbox versions, as well as .odfs created with VB on Windows. iirc I used odf 2 when exporting. Andrew

DKeppi, Am I correct, on a real ds415+, with the real synology DSM5.1, and the fixed spk, the machine spontaneously reboots when you start a VM? What do /var/log/vbox.log and vboxscripts.log show? Are these imported VMs? Any chance you are importing a 64bit VM, but your VB host is 32bit - this would cause a reboot in VB 4.0.18, perhaps the error is back. Try creating a VM from scratch, single disk, booting from a simple install .iso like DSL or such, can you complete the install? Will the VM run? Andrew

Your machine isn't exactly "hairy chested", neither is mine. Mine will do what you describe if I run a few Virtual machines, or do somethingelse that will fill up the system drive (md0). Try the command "df" in a terminal session, watch the % used on /dev/md0 - if this keeps going up and up over the course of a few days then something is filling up the system disk. What apps have you got installed? Andrew

The .spk installer for phpvirtualbox works fine, but Package Center doesn't show the vbox.log when you click on the "View Log". It is a really minr point, but... if you want to get it to work: 1) edit /var/packages/virtualbox/scripts/start-stop-status 2) at the top, just below the PACKAGE_ENABLED= line, add a new line: LOG_FILE="/var/log/vbox.log" 3) near the bottom in the case section, in the line below log) replace: the line "exit 1" with "echo ${LOG_FILE}" so that it reads: ;; log) echo ${LOG_FILE} ;; Save the file, Now it works This works on DSM5.1, with the "fixed" phpvirtualbox.spk from viewtopic.php?f=15&t=3497&start=100#p31827, but it should be valid for any DSM. Andrew

Remylpat, Works fine on my xpenology (dsm5.1), I just installed vim from there and it works fine. Are you looking under "all", or "Community" in the Package Center? Andrew

DKeppi, I presume you edited the INFO file in the .spk, changing the arch= from "bromolow" to "avoton", otherwise I don't think the install will contine, but it is worth asking. Is the reboot immediate, or does it take a while? What happens if you remove the "fixed" spk and install the package via packagemanager? (Add http://spk.synologyitalia.com/ to your Synology NAS Package Center sources) If the "fixed" package is specific to xpenology then it may be making calls to modules that are not present on a real synology. Andrew

So, after removing virtualbox, a reboot, and reinstalling from the latest download (file name: virtualbox-x64-4.3.12_DSM-5.1_fixed.spk) everything seems to be working fine again. After the reinstall all my VMs and settings were still there in the web interface, bridged mode now works, and the md0 filling up issue is gone. The .spk that I had installed from was an earlier version, named:virtualbox-DSM5.1-4.3.12-93733.spk - I am not sure where I downloaded it from, but it was apparently not "fixed", as the latest download _is_ Mittel, what was the name of the .spk file you had installed? Andrew

I suspect I may have an outdated spk then, I am just downloading and will try a remove/install with the latest .spk Andrew

Mittel, Does your xpenology box show as a DS3615xs in Synology Assistant? (i.e. are you using the 64 bit xpeno?) What does "cat /var/log/vbox.log" show? I'm not sure if you still need to scp the modules or not with the latest download from dodo, did you? Andrew

Mittel, Where did you install the package from, and did you upgrade the modules after installing? Can you create a new VM, as opposed to importing? Andrew

Further to my earlier post about md0 filling up: After I upgraded to DSM51 virtualbox wasn't working anymore, so I uninstalled it, then reinstalled it and updated the modules. Since then: The md0 fills up to 100% in about 30-45 minutes if I use a bridged network, it does NOT happen with NAT (this did not happen before DSM51) The VM cannot reach the internet with bridged connection (it could before the upgrade to DSM5.1) The VM CAN reach the internet if I use NAT. VBoxManage command is not in the PATH (it was before the DSM upgrade) Has anyone else had the same issues? I'm wondering if something went wrong with the installation of virtualbox, although there were no error messages). Seba? Andrew

Mittel, Did you change the storage location to somewhere other than the default? The default stores the vms in /root/Virtualbox (or similar), the point being that it is on /dev/mdo which is the "system" disk, and doesn't have much space. Andrew

Just noticed something strange tonight. If I start a VM (in this case a Win XP machine), it slowly fills up /dev/md0. Note, the VM itself is stored on /volume1/Virtualmachines, but something must be generating log or temp files at an alarming rate. I couldn't login to the DSM GUI because the volume was full. The space does not get cleared down when I stop theVM, only when I restart the NAS itself. This only started happening since I upgraded to DSM5.1, The VMs worked fine before the upgrade, and the md0 didn't get filled up. Since the DSM Update the VMs are a lot slower than they were before. Anyone else seen this? Andrew

Try raidtool destroy 2 (this will delete the md2 device, which is where the 1st volume is created. If you have more than one volume then "raidtool destroy 3" etc. Just don't destroy 0 or 1, those are the system volumes. Andrew

So, I have a VM setup and manage to get though the cross compile steps and generate synoboot_5.1-5004_x64_3612xs.img. What I don't know is what to DO with the .img file to cause a VM to boot from this. I tried vboxmanage convert raw, but that didn't work. How do I get from the .img file to either a bootable .iso, or a bootable .vdi or .vmdk? Andrew

HommiePeter A couple of questions: 1) are you using the two scripts in Sancomes repo? If yes, did you leave them as is, and modify/rename/resave the toolchain file to only include the /linux-3.x folder? 2) Does the 01 script run without any error messages, particularily in the sections where patching is done? The script is written for the DSM50 version. Did you modify the patch files and or the script? (This is where I am currently getting hung up) 3) What selections did you change in menuconfig? I was hoping BROMOLOW and devices>general>create DEVTMPFS and mount DEVTMPFS would be enough to get the device detection working properly again. I am working on setting up and documenting creation and configuration of a Ubuntu VM, trying to write the documentation "forward looking" in the sense that it covers what to do when DSM6.0 comes out i.e. download the toolchain, edit the script file to change the name of the tarball, modify the patch file in folder X changing blah blah to foo bar. Unfortunately, it has been quite a while since I worked on this kind of stuff (think DEC PDP series and Motorola 4 bit assembler) - I recognize the rhythm, but the lyrics and hairstyles are largely incomprehensible to me. Andrew

My thanks as well. So far I am resisting the urge to PM you with so many questions about compiling the Kernel that you would be faster to just do it yourself.... so far. Andrew

I am already in waaaay over my head. I am looking at the synobios.h file, There I find a typedef enum section which lists the values the bios accepts/expects including: MICROP_ID_3611xs = 0x42, /* 'B' 3612xs is the same*/ and, at the bottom of this section: MICROP_ID_UNKNOW = 0xFF, so this has me wondering.... what if I change the MICROP_ID_UNKNOW = 0xFF, to MICROP_ID_3611xs = 0xFF, Would this mean that all machines that do not return a valid MICROP_ID would appear to be 3611xs (which is the same as 3612xs)? Does that make sense? As far as I understand it synobios.ko is built from synobios.h, no? Andrew

@HommiePeter: I just checked sourceforge, they have now posted the 5.1 gpl and apparently changed the 5.1 toolchain. Perhaps the problems you had were related to something wrong in the 1st toolchain they posted? Andrew