jagwaugh

Probiere mal mit bridged. An der MAC liegt es nicht. Ich hab diverse VMs alle mit bridged und die funtionieren alle problemlos.

You're welcome. In a perverse way it is actually good to have problems at the beginning, as it forces you to go a bit deeper into how the thing works before you start adding all kinds of packages and data to it. Later on, if or when something does go wrong that little bit of knowledge will be useful. Andrew

I believe gnoboot has more drivers for internal cards/hardware than nanoboot... at least that used to be the case, but may not be so anymore. I'm not sure exactly what is (not) happening to cause this. Since it worked with both disks and freenas, We can presume that the hardware is ok. This probably also means that the BIOS settings are also ok. This leaves us with a limited number of possibilities: 1) the device that your missing disk is on is not supported by nanoboot or gnoboot - getting it to work would mean asking either of the developers to add a driver for your Mobo. 2) The partitions left over from the freenas install interfered with the install of the DSM. Try booting to a usb image with DBAN on it and completely zero both disks (this will take a while) I usually don't let DBAN run all the way through when I am trying to get a disk to the "uninitialised" state, it is usually enough to let DBAN run for 5-10 minutes - this does enough damage to the disk boot sectors and partitions that the is for all intents and purposes unformatted. (DBAN is normally used to overwrite all sectors of a disk so that if you give or sell it to someone they cannot recover whatever data you had stored on it) If you only changed the MBR with gparted then the partition table was unchanged, what you need to do is get rid of all the partitions. I use DBAN just because I am lazy (it boots faster than my other image with gparted) Andrew

Enable Beta in Packages & install Cloudsync.

I think [ 6.087334] sd 3:0:0:0: [sdd] 488397168 512-byte logical blocks: (250 GB/232 GiB) means that only one disk is being detected, and that is a 250Gb disk. I thought the 250 Gb disk WASN'T getting detected?

from a an SSH session try "dmesg | grep sd " "dmesg | grep hd" this should list all drives detected google unetbootin, you can use it to create a Ubuntu live usb stick.

Hmn... To be perfectly honest, I'm not sure what to try next. what does dmesg tell you about the harware? If you are using nanoboot, try gnoboot (could be a driver support issue). If you boot the machine to a ubuntu live cd/usb is the drive recognised? Andrew

Have a look at: http://h30499.www3.hp.com/t5/Business-P ... DAteNFxntQ Are you using the latest BIOS, and have you got "Data Execution Prevention" OFF ?

As far as I can tell, this Mobo has a built in RAID function. You need to turn this OFF. Perhaps try a reset to default in the bios.

Try a different usb stick. It may just be a bad stick, Or try burning the .iso to a CD. I boot my bare metal machine from CD, works fine.

What Mobo are you using, and how have you got the ide configured in BIOS?

Thanks. I am by no means a programmer, but this is more System Engineer type stuff (I used to be a SSE). I'm still trolling around trying to figure out what makes it tick, but haven't worked with *nix for a looong time. I am working on compiling drivers for a cdrom, as a start to making an ultimate rip station. As to the hang on restart... In my experience there seems to be problems with restarts on install/upgrade activity. I get much better results with having a terminal open and doing a poweroff whenever a restart is called for. This seems to be the case with both bare metal install AND Virtual Machines. This week I managed to get beta5.1 running with a volume created simply by using poweroffs instead of restarts. If you just do restarts the beta 5.1 barfs on apparmor and won't recognize any disks. Andrew

Nick, I don't see any issue with going straight from U1 to U7 although you might need to make sure your boot .iso/usb is 4493 _U7 (not too sure if this is a show stopper or not). Regarding the magical commands, here is how the update procedure works, as I understand it: Downloading (either straight from synology, or manual from a .pat file) creates two files, one is the .pat file, the other is an "Update info" file. The .pat file is just a compressed archive, ins some cases the synology will uncompress it to /volume1/@tmp/some directory, in some cases it just downloads the .pat to /volume1/@temp/some_number.pat. Whether the .pat file is uncompressed or not seems to be dependant on how major the update is, but is anyways uninmportant with respect to the "magical Command" The "update info" file will either just have a string indicating where the uncompressed.pat file is, or a list of each individual update and where they are if the update is uncompressed by the download mechanism. On a real synology there is a flash memory device, which contains the boot code for the box. This device is updated by a patch called "flashupdatedeb". Since our xpenology boxes don't have a real flash device (this is why we boot from a usb or .iso image), we can't update that device. Presumably the synology update procedure will fail if it cannot update the boot device (obviously the first test for the update procedure is "Where did I boot from?, can I update it? If No, exit". What the magical commant does is modify the "update info" file named "autoupd@te.info" , changing every instance of "flashupdatedeb" to "flashupdatedeb1" i.e. to an update that does not exist in the extracted directory structure. The sed command makes a 2nd copy of the "update Info" called "autoupd@te.info1, which we overwrite the orginal autoupd@te.info with via the "mv" command. Fortunately the synology update procedure doesn't do any testing to see if every update listed in the .info file is actually there, so that when you then click on "update" in the GUI, the software then just steps through the updates listed in the info file, ignoring the flashupdatedeb (because it isn't listed) and wordlessly skipping the updateinfodeb1 (because it doesn't exist), but it updates everything else. On updates that don't include changes to the flashdevice the magical command isn't needed. The update info file is just a text file, you can look at it with any editor/viewer. The .pat file is just an archive, you can expand it with tar -xvf or 7zip in windows and see what is inside. Andrew

Hmn, What do cat /proc/mdstat cat /proc/partitions /usr/syno/sbin/synospace --enum -a Give for output? Andrew

Have a look at http://forum.synology.com/enu/viewtopic ... 39&t=41586 I just made a clone of a test VM with nanoboot and 2 disks in SHR, storage on volume1 per default worked in vm changing volume1 to volume2 I logged into the machine as root via ssh and ran: /usr/syno/sbin/synospace --synoblock -s /dev/sda -v volume_2 Nota Bene: that is no type, it is volume_2 at the end, not! volume2 then did a shutdown. After powering back on the GUI showed all the data still there in filestation (ie. the above migrated the contents cleanly) and the volume was called volume2 In the terminal I found /volume2 with all the data underneath it, and /volume1 with only @tmp inside of it. Then I did rm -r /volume1, and again poweroff. After powering back on the data was still there, & the volume was healthy, so I did /usr/syno/sbin/synospace --synoblock -s /dev/sda -v volume_1 and again a shutdown. After powering back on, the data was still there, & volume was still healthy, from terminal I did rm -r /volume2 and a reboot. Everything fine, volume is called volume1 again, & there is no volume2 anymore. So... to summarize, it would appear that the name of the volume is just where the array (/dev/vg1000/lv) gets mounted. I didn't have a lot of files on the volume & no unusual permissions, but they appear to have stayed intact throughout. As long as your array is healthy then you shouldn't have any trouble: /usr/syno/sbin/synospace --synoblock -s /dev/sda -v volume_1 restart check that the data is on /volume1 again rm -r /volume2 restart Andrew

Epicurean: First off, try a shutdown, as opposed to a reboot, I suspect that wierd stuff sometimes happens to the raid array on upgrades with reboots, as opposed to power off. If your volume is still at volume2 then a few questions: 1: How many disks have you got installed? 2: Are they JBOD or SHR? 3: Was the volume clean when you did the upgrade? 4: login via ssh, what do df, mount, and cat /proc/mdstat give as output? Andrew

It took me a few tries, but I now have a Virtualbox vm running 4977 Update1 Volume1. I used the NB_x64_5032_DSM_51-4977_BETA_Xpenology_nl.iso and 4 32GB .vdi disks. Procedure was: 1. Create VM & Disks 2. Install 5.0-4493, but do not SHR create volume 3. Update this to Update 7. 4. Verify that the array is healthy (cat /proc/mdstat) poweroff. 5. Power on, select 4977 install from boot menu in Console. 6. Install using synology assistant & DSM_DS3612xs_4977.pat 7. Be patient. Wait until you can logon as your admin account via the console. 8. Wait until the md0 / md1 raid is fully operational (cat /proc/mdstat) 9. Poweroff. 10. Poweron, login to gui, set ssh/telnet/time etc. 11. Open ssh (via putty) 12. Download Update in Gui 13. sed's & mv the upd@teinfo as usual 14. Install the update 15. Poweroff 16. Poweron, create the volume in the GUI. The key was not creating the volume until beta 51. is in and updated. I realise that this isn't a viable upgrade path for a running installation, but it does prove that Synology haven't done anything that breaks or interferes with xpenologys boot method. When I first tried upgrading a VM to beta 5.1 it was with a volume created in 5.0 - this resulted in apparmor bombing and wierd stuff happening with the raid array (md2 got lost, and md0 & md1 were getting renamed and built with non existing devices - it ran, in the sense of having a filesystem on it, but the configuration was so messed up that it couldn't be checked, modified, or expanded. Andrew

@Matthias, Soweit ich verstanden habe, die "sed's" & "mv" commands gelten lediglich für updates welche die Flash Speicher ändern... da unsere Xpenology keinen flash had, ändert der "sed" Kommand der inhalt der autoupd@te.info um den interne Eintrag für den flashupdate auf ein nicht existenten patch umzulenken. dann übernimmt den eingebauten synology patch mechanismus alles wie gehabt, aber springt über den flashupdate. Komischerweis hab ich kein log eintrag vom updtate prozedure finden konnen dass der diesen flashupdate1 nicht finden konnte. Andrew

Haven't noticed anything yet. I am running Downloadstation, Virtualboxphp, Serviio, Couchpotato, and various shares (with built in Samba)

Works fine on my bare metal (AMD GeForce Mobo), nanoboot from CD.

Seems to be ok, see viewtopic.php?f=2&t=4062#p24334

Just installed 4493 Update 7 in a Virtualbox machine (nanoboot5031x64_xpenology_5.0-4493_bootloader.iso, two disks). Update installs no problem (using sed on the .info file). Seems normal after the reboot, but I didn't have much else running on the VM. Andrew

I found a check which supposedly tests for the vulnerability. My xpenology VM is apparently clean. see http://www.theregister.co.uk/2014/09/24 ... hell_vuln/

turning apparmor off: support_apparmor="no" in /etc/synoinfo.conf and /etc.defaults/synoinfo.conf (the startup script in init actually checks the config in etc.defaults) This only eliminates apparmor, I am still looking at what goes wrong with the volumes - cat /proc/mdstat only shows md0 & md1 but md2 (where volume1 normally is) is lost after the reboot post installing. i.e. mdstat shows all 3 md after the install but before the reboot.

Sorry, should have given more detail. Baremetal, Nanoboot latest, booting from cd burn with latest .iso. I am just trying to crosscompile a few things, I'd like to be able to use the CD, at least from the terminal. It is not bad for fairly aged hardware, CPU &Mem go to the wall with virtualbox, but it worked, had a high cpu usage with ffmpeg under serviio, changed the dlna profile for my tv and that got a LOT better. Andrew