doron

Okay @Socrates, this implies that your server does get an IP address (etc.) from the DHCP server. You are connecting to it via SSH. What does not seem to run is the web server (nginx). "Connection Refused" means we got to the box, but the applicable port (80 by default for a web client) is not open (listened to). At any rate, can you do, on the shell you connect to via putty, run this and post the output: netstat -apn | grep LISTEN | grep 80

Check if unRAID (sorry, Unraid) sees the NIC and has a driver for it. Can you paste the output of: ifconfig -a and ethtool -i eth0

The complete answer to this question will depend on "describe your threat model". If your considered threat involves nation states or people with access to substantial resources for reconstructing your data, you may want to consult military standards for erasing data, most of which call for multiple overwrites with different patterns. This can be a good starting point. For the rest of us, overwriting with zeroes (as in preclear) should be fine - provided it completes successfully (you do note hardware issues on the drives). Note that if your drives are encrypted (using a reasonable passphrase / key) - you don't actually need to do anything, your drives can be considered wiped, for all practical purposes, to anyone who does not have access to your key.

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.

... or: ls -lR /mnt/disk* > /boot/list.txt

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.

Tom, would you be able to comment on this?

Perhaps an expansion of emhttp_event functionality would serve this purpose well.