doron

Ouch. In your shoes I would now smash the partition table on that drive, and let unRAID format it as new. (there might be a mighty simpler way to resolve the partition table alignment thing in unRAID - I'm just not sure what that would be - maybe it's time to summon @bonienl to the table?...) How do you go about doing that? Well first you need to know (with absolute certainty!) what is the device name given to your cache drive. Wrong move here and you kill a live drive. Let's assume it is /dev/sdh (I'm making this up - please check). Now: 1. Stop the array, remove the cache drive from it. 2. dd if=/dev/zero of=/dev/sdh bs=1M count=1 (please please make sure it's the right dev. Also, /dev/sdh and not /dev/sdh1) 3. Reassign the cache drive and start it. It now has no partition table, so one needs to be created upon formatting - hopefully a good one :-)

Let me ask a very stupid question: does the cache drive mount okay now? Cuz if it does, then problem solved, right?

I see you have read the thread I pointed you at :-) Seems like you should be fine without a downgrade. Remove -> attach with UA -> copy -> attach as cache -> format -> copy back. Please report results for posterity...

Check this out.

No need to download. You can just assign the vmdk (after you powered down unRAID) to another VM - could be Windows, could be Linux, whatever - and you will see the device as a new HDD on that VM, upon which time you can copy stuff to your heart's content. As long as you don't boot from the VMDK that is ?

Yes but that is your actual flash drive (I'd umount it now - double mounting ain't healthy - "umount /mnt/t"). This is weird. I'm kind of at the end of my wits on this one - not sure how your boot drive would not have a Linux device. It might have to do with the version discrepancy between the flash and the VHD, causing your booted kernel to not have all the needed drivers to access the boot device. That's a guess though. My suggestion now would be to power down the unRAID VM, copy the bz* files from the flash drive to the vmdk (using another machine - probably Windows, or a Hiren Boot CD if you have that, etc.) and then restart unRAID and see that you successfully upgraded. Once this is done, I'd be curious to see another run of "fdisk -l", to see if my theory above holds water. And assuming it does, you will from that point on be able to do this much more easily - using the mechanism I described above (which is what I do regularly).

So we haven't nailed the vmdk device yet. Okay, one more shot. Please paste output of: fdisk -l Also, how large is your vmdk? (will help in eliminating)

Ah. You have /dev/sdc1 mounted on /mnt/t - probably from previous attempts ? We can't double mount. /dev/sdc seems to be a ~128GB HDD (or flash). Your USB flash drive seems to be 8GB. We need to unmount /mnt/t to start clean. Please do: umount /mnt/t mount /dev/sdb1 /mnt/t ls /mnt/t

Oh. So the vmdk is not at /dev/sdb after all. Can you paste the output of "df" (when the array is online and mounted)? We can then find it by elimination... (might be /dev/sdg?) Anyway, we can either continue looking for the right /dev/sdX for the vmdk, or you can shortcut this by doing it with the server offline. It'd be good if you do find it, since you will need to copy these files each time you update the unRAID OS.

@guruleenyc So here's /dev/sdb right there. Can you now paste: mkdir /mnt/t mount /dev/sdb1 /mnt/t ls -la /mnt/t

Yes, you will have to figure out where the drive is. It will be one of the /dev/sd* (you'd have quite a few). When you say you don't see /dev/sdb, what do you mean? If you still can't find it, can you paste the output of: ls -la /dev/sd* ls -la /dev/disk/by-uuid BTW, @uldise's suggestion is also excellent. It calls for a change in the way you boot your VM though.

Sorry, had to go into a meeting. Let's take half a step back. Under ESXi, unRAID VM does not actually boot off your flash drive (limitation of the hypervisor). Instead, unRAID boots from a virtual HDD (your vmdk) which somewhat clones the bootable content of the flash drive. Early in the boot process, unRAID detects your real flash drive, and mounts it as /boot. Now when the "Update OS" process happens, it updates the real flash drive. What we need to do is to copy the files containing the kernel, drivers etc. from the flash drive (which is under /boot) to the small HDD you are using to boot (which is typically not mounted). So back to my reply above. If we assume that your vmdk is /dev/sdb, you would do this, after Update OS but before rebooting: mkdir /mnt/t mount /dev/sdb1 /mnt/t cp -p /boot/bz* /mnt/t/ Good luck!

Try to run the 6.5.2 update via "tools -> Update OS"; then, DO NOT REBOOT but copy all bz* files from /boot into your real boot drive (you'd probably need to mount it first). So if your real boot drive (not the USB flash) is e.g. /dev/sdc, do something like -- mkdir /mnt/t mount /dev/sdc1 /mnt/t cp -p /boot/bz* /mnt/t/ Then, reboot. Let me know if this works.

Absolutely, yes. At 6.5.2 now. What is the problem you are seeing?

Have you also updated bzmodules and bzfirmware? Not doing the former will lead to what you are seeing.

Thanks. For me, I fixed it already. To reproduce: [*]uninstall S3 [*]install dynamix' latest version (so it's not the vanilla, bundled version ==> there's stuff in /boot/config/plugins/dynamix...) [*]Remove the dynamix.cfg file, so that the plugin uses the default.cfg [*]Install the S3 plugin You should now be able to see the breakage.

No, it won't. This happens only when you do not have a dynamix.cfg file. Since you did, as can be seen from the chain of actions you describe, the plugin took a different code path (edit the dynamix.cfg file) which it does correctly.

It works fine for me. More information on how it breaks would be useful then I'm sure someone will have an answer. Kevin. You're right of course. From how the breakage looks here I presumed it'd be universally reproduced. What happens here is that the sheer installation of the S3 Sleep plugin over the updated dynamix messes up all the pages of the webGUI. It appears as if there's no CSS and no PHP actions (HTML text, no formatting, no action on buttons). Sample screenshot attached. When S3 Sleep is installed on the "vanilla" (beta12) Dynamix, no problem. When Dynamix is updated - breakage. When I remove S3 Sleep, then update Dynamix to latest - no problem; when I now install S3 Sleep - breakage. Deleting the S3 plugin files and rebooting doesn't fix the breakage. Deleting the entire /boot/config/plugins/dynamix - does. Deleting only /boot/config/plugins/dynamix/dynamix.cfg - also does. The problem seems to be with the fact that S3 Sleep plugin writes the dynamix.cfg file if it does not exist. What I end up with here is: [confirm]\nsleep="1"\n [display]\nsleep="plugins/dynamix.s3.sleep/Sleep.php"\n That's the entire file. I'm guessing you don't experience this because you do have dynamix.cfg already, in which case the plugin edits it, and seems to do that correctly.

It appears the S3.Sleep plugin breaks the Dynamix webGUI after the last update to the latter (12.01). This did not happen prior to the last update to webGUI.

+1 (on all counts, including testing!)

Thanks for your response. Following your advice, I just did just that. Redownload this file. Then installpkg (I'm trying to isolate the problem from the plugin, but I get the very same with the plugin) and then "vboxmanage extpack install...". Same result: vboxmanage hangs, never returns; "top" shows VBoxSVC eating up as much CPU as it possibly can. What do I do now?! **UPDATE** Problem resolved. Ugh. The vbox package was okay, but the extpack itself was somehow corrupt. Refreshed it, installed plugin, exrpack installed fine. Sorry for the "noise". Thanks!

Hi folks - were any of you able to install the vbox extension pack for 4.2.16? When I try to install it - be it via the plugin (thanks!!) or via a manual install of the packages - the "vboxmanage extpack install" hangs forever and does not complete. When it does, I see the process VBoxSVC eating 100% CPU and not completing. unRAID 5 rc16c. Any help would be greatly appreciated! (I also posted about it here).