Gregory's Server@marcan the only reason I could oppose to the curl|sh method is the potential that without enough self-checking, a broken or malformed script could be ran, resulting in damage during. Say, the partitioning stage.
But how would different could it be from an ISO that boots to a broken installer?
@zanagb The script has a basic truncation guard and proper error handling, so there's no real way for unintentional truncation/corruption to go undetected. The bulk of the installer is downloaded as a separate step (and if the download or unpack fails the script aborts). The top level curl part is just a very simple bootstrap.
Of course you can have things like your network die mid-install, but there isn't much we can do about that (the installer streams the actual OS install data directly to the destination, this is a good thing since it avoids having to leave aside staging space and works from recovery mode where no staging space may be available at all). We do have retries and such for intermittent errors, and also reduce the block size when errors happen to help out with flaky connections.
If something does fail and abort, well, manually doing the cleanup/uninstall steps and trying again isn't a huge deal. The actual steps to make the install bootable happen at the end, so it's not possible to end up with an "accidentally booting but actually subtly incomplete/corrupted" install (I think).
@zanagb The script has a basic truncation guard and proper error handling, so there's no real way for unintentional truncation/corruption to go undetected. The bulk of the installer is downloaded as a separate step (and if the download or unpack fails the script aborts). The top level curl part is just a very simple bootstrap.