New installer breaks VMware boot media

[jperkin]

Booting a VMware Fusion image since the integration of the new installer (i.e. https://us-east.manta.joyent.com/Joyent_Dev/public/SmartOS/smartos-latest.vmwarevm.tar.bz2) will result in an un-bootable install, unless the user takes careful steps to amend the default zpool layout.

The problem is that the installer picks the boot media as a valid install target, so if the user accepts the defaults then the live image will be wiped out.

vdevs: c0t1d0 logs: c0t0d0 total capacity: 20.00 GB

The boot media (c0t0d0) is presented to VMware as a SCSI hard disk, so /usr/bin/removable_disk does not accept it as removable media, and disklist -r does not list it. This is likely why it is not being excluded by the installer.

Suggested fix: attach the boot media as a USB device rather than a SCSI disk.

[nshalman]

Alternate possible fix: use the CD image rather than the USB image as the boot media.
EDIT: @pfmooney notes that using read-only boot media can make it a pain for folks to do PI updates.
EDIT2: Also, while I would love to fix this on my own, I do not have VMware or a machine to run it, but I'm happy to work with someone who does to come up with a solution and get a patch written to fix this.

[nshalman]

If we're lucky, in theory we just need to alter these two lines very slightly:
https://github.com/joyent/smartos-live/blob/master/tools/SmartOS.vmwarevm/SmartOS.vmx#L63-L64

[matthiasg]

alternatively you can choose 'manual' at the zpool setup step and write

zpool create zones c0t1d0
exit

and then continue.

[jritorto]

zpool create zones c0t1d0 worked for me; thanks.

[jperkin]

I took a look at this today. It appears we cannot use USB booting at this time, it isn't natively supported by VMware, and the workarounds (e.g. using EFI and using a chainloading floppy image) are untenable.

So I've prepared a patch which simply switches to using the ISO image. This works for me, so would appreciate others testing.

The proposed patch is here:

http://165.225.144.106/0001-joyent-smartos-live-506-New-installer-breaks-VMware-.patch

A resulting VMware image for testing can be downloaded here:

http://165.225.144.106/smartos-20160204T124228Z.vmwarevm.tar.bz2

While this changes the default behaviour for people looking to upgrade the platform image (obviously the ISO is read-only so you can no longer mount and write a new platform directly), the workarounds appear acceptable, either by switching out the ISO image directly (easy enough for casual users via the GUI), or creating a new disk to boot platforms from (for users advanced enough to be building their own platform).

[jperkin]

@rmustacc suggested a different approach, where we give the boot media a volume label then ensure it is skipped by the installer. There was also discussion on IRC about skipping all USB devices by default (users can still create a pool manually if they really really want to, e.g. for testing).

I've implemented a patch which solves both cases, and have tested that it at least resolves the boot image issue in VMware.

The diff is here: https://gist.github.com/jperkin/6487bcc6da5cd912b154

A test VMware image is here: http://165.225.144.106/tmp2/smartos-20160204T124228Z.vmwarevm.tar.bz2

[rmustacc]

I think someone else actually suggested it, I just parroted it. @jclulow could you review the changes here?

[CyBeRoni]

There was also discussion on IRC about skipping all USB devices by default

This is the premise behind #552 which you would fix with that.

[jperkin]

@CyBeRoni any chance you could test to make sure we're skipping USB devices too?

Platform image for testing is here: http://165.225.144.106/platform-20160204T124228Z.tgz

Thanks.

[CyBeRoni]

I'm afraid the box I referred to is in a colo doing Important Things but I'll see if I can't find something else that exhibits the same behaviour.

[jclulow]

@jperkin @rmustacc This patch looks good to me. Do you want to put it back, or shall I?

[jperkin]

This fix will be in the next release.