> Just run a buildworld/buildkernel of your modified FreeBSD, set up a few parameters (AWS keys, AWS region, and an S3 bucket to be used for staging the upload), and cd /usr/src/release && make ec2ami.

This is as FreeBSDish as it gets :)

To be fair, this is for people who have made changes to the FreeBSD base system -- so the buildworld/buildkernel is kind of axiomatic.

It was mostly a joke, back in the day when I started using freebsd, it seemed that the answer for 'how do I do such-and-such with FreeBSD' was, most of the time, 'cd /usr/src && make such-and-such'

Indeed -- annoyance with that is why I wrote FreeBSD Update. My view is that regular users should never have to compile anything, and I certainly wouldn't be happy if the first option for running FreeBSD in EC2 involved running a buildworld.

But I'm just fine with saying that this is an option for people who want to make their own changes to the FreeBSD base system. (And moreover, anyone who is making such changes is unlikely to be scared off by the buildworld/buildkernel; in fact, they've already done it, when they were making their changes offline.)

Hi Colin.

Why is freebsd-update(8) so slow? When upgrading between releases, it's significantly slower than apt, yum, dnf, Solaris IPS, pkgin, FreeBSD's own pkg(8), Windows Update, macOS update, while fundamentally doing less than any of these tools. It's bordering on being unusably slow.

What's the problem here? Thanks.

FreeBSD Update is doing something it was never designed for. I wrote it as a tool for security updates -- which inherently affect just a handful of files --and have a number of paranoid checks in it, in order that it can be safely run blindly.

We needed a tool for upgrading between releases, and I was able to hack that into FreeBSD Update, but I didn't change the fundamental design. At this point, we're all waiting for pkgbase so there's no reason to revisit the design now.

I think that image cost FreeBSD a prominent place in datacenters.

I agree. OpenBSD also has/had the same problem. Until not that long ago, they didn't even have downloadable bootable ISOs. You either had to buy the CD, or roll your own CD from the file sets.

Until very recently there weren't any binary updates at all, and right now you still can't do an in-situ upgrade between releases (the closest thing being https://www.openbsd.org/faq/upgrade64.html#NoInstKern).

Thanks Colin for the guides, though as I can find, only FreeBSD in BSD world bothered to provide already baked and ready to use EC2 AMI (including AWS ENA driver).

I think you're right; at various times people have managed to build NetBSD, OpenBSD, and (I think) DragonFlyBSD and published instructions, but I don't think anyone has pushed to have those projects ship official images.

I don't blame them. It's a lot of work, and for most developers, if they need to run something in EC2, their need is satisfied once they have images -- whether official images are publicly available is irrelevant. I'm in the position of not just wanting to use EC2 now, but wanting to make sure it's available for me in the future -- so having a large userbase is important, both so that other people can find bugs before me, and so that FreeBSD is something Amazon cares about (the ENA driver was ported to FreeBSD by a team hired by Amazon... without that, it would have taken us years to catch up).

There's a financial cost to having these AMIs online, right?

Kind of. Yes, but it's on the order of a couple cents per month.

Builder pays for EBS storage costs, and of course the human cost of maintaining and releasing the images.

Is freenas running on AWS yet? Any interest in this if not?

Not that I'm aware of. If the iXsystems people want to do this, I'll be happy to help.

Out of curiosity: What would be the use case/benefits of running FreeNAS on AWS?

Had a really long conversation with some remarkably smart folks about this.

Here are the pros:

1. It's a tool folks use; and being able to use it in AWS/Azure/GCP/etc would be useful

2. When folks use a tool they know, and need more capacity/locations, it'd be nice to be able to 'cloudburst' into AWS/Azure/GCP/etc

Here are the Cons:

1. Smarty pants folks can come up with many theoretical and plausible solutions for anything FreeNAS can do in AWS using proprietary lockin solutions from AWS. If you just reformulate your requirements, there's another solution you can use instead of FreeNAS

2. ZFS is good at helping with diverse physical volumes and this paradigm is moot with AWS EBS volumes (as they are not physical volumes). However, this argument reduces to "don't do parity/erasure coding across EBS volumes."

So, reply here if you want it and I'll work w/ some folks to make it happen.

In my case, there are a lot of places where we use disparately multitiered storage on freenas/zfs/filesystem($foo) and sometimes it makes sense to temporarily "cloudburst" into AWS while waiting hardware to support the load.