Sorry I can't be more definitive, but I just succesfully upgraded my 3.1.2 installation to 3.1.3. Also running as a guest VM on ESXi.

I initially had a problem with it telling me I didn't have enough space, then I realized that I'd created my syspool on mirrored 3GB partitions but I read that 4GB is the stated minimum, even though it might work on other sizes.

I grew my syspool to 4GB using some VMDK resizing combined with mirror shuffling, and that worked. Once I was at 4GB mirrored, the upgrade went through without a hitch.

A suggestion I found from a thread from about a year ago was to check for the presence of a file named "core" by typing:

ls / -la

If it's there, it was suggested that this is a diagnostic dump and not necessary for anything other than doing crash-dump analysis, so can be safely deleted.

I must confess as not being able to vouch for the safety of deleting said "core" file, but I did it on mine without any apparent ill-effects. Perhaps this will get you over your hump. Otherwise, since you're already working in a VM, tacking on extra space to the syspool is relatively trivial, assuming you have that space on your parent storage.

Good luck, AJM

Thanks for your reply Adam.

Yes, I'd already spotted that /core file and guessed it was an old core dump so had deleted it without any apparent problem (assuming it is a core file it's not much use without a debugger and source code, i.e. support, anyway).

That the volume might be mirrored is in interesting thought and might explain a loss of half of the space though I will have only given it one device for booting when I installed. I'll pursue that line of investigation.

(Oh, I could increase the virtual disk size but I'd sooner understand what I've done wrong as this is a lab system anyway).

Simon

Well, it was worth a shot. Sorry, you've tapped me out of answers.

A degraded mirror shouldn't cause any incorrect space reporting issues since a mirror is just a mirror. 4GB mirrored is still 4GB, whether the mirror is broken or intact.

I just mentioned mirroring the syspool as that's how I have mine setup, 2 mirrored drives on different SSDs. The mirroring was what allowed me to seamlessly grow the syspool from 3GB to 4GB without any hassle.

In your case, I don't think it's pertinent, but please do share if you're able to resolve things as I'd be curious as well. My upgrade process pretty blatantly said "you need X free space to apply this upgrade, you currently have Y" where Y was much bigger than X from the get-go, yet still it failed. I suspect there's more going on behind the scenes than what it's telling us it wants/needs during the upgrade process.

Good luck, please let us know how it goes! AJM

can you try zfs list from a command line? let me see the output?

Thank you Linda. I hadn't had time to look at this for a few days but your suggestion gets us nearer to the issue: $ zfs list

NAME USED AVAIL REFER MOUNTPOINT

syspool 3.56G 353M 35.5K legacy

syspool/rootfs-nmu-000 4.98M 353M 1.45G legacy

syspool/rootfs-nmu-001 2.52G 353M 1.30G legacy

syspool/swap 1.03G 374M 1.01G -

vol1 ... various vol1 volumes... (sorry, I can't get the hang of formatting a block of code!)

So ~0+2.52+1.03=3.55G out of 4GB... it's the swap space that's accounting for the difference... I should have spotted that!

In /etc/vfstab I have: /dev/zvol/dsk/syspool/swap - - swap - no -

The VM currently has 1GB vRAM. Would it be possible to reduce the swap size and allocate it rootfs-nmu to to get it through the upgrade?

Actually I could easily give it 2 or 4GB vRAM instead of swap - I'm not sure as a VM I really want it paging anyway. I've been meaning to look at the "NexentaVSA for View" does as that must be similar.

reducing swap on a running machine is tricky business :) you really don't want to do this on a really busy machine.

it can be done manually..

"#swap -d /dev/zvol/dsk/syspool/swap"

"#swap -l (check that it's gone)"

"#zfs volsize=200m syspool/swap (to resize)"

"#swap -a /dev/zvol/dsk/syspool/swap"