Catalina plz

[mcandre]

Developers are having luck generating macOS boxes using this tool called macinabox!

https://github.com/bacongravy/macinbox

[ladar]

@mcandre I'd love to add MacOS and/or Windows variants to the build pipeline. But they both would involve a significant amount of time to a) get up and running, because they are incredibly different from all the existing configs, and b) maintain once they were integrated. And as much as I'd love to add them, it's hard for me to find/justify the time to make it happen because my job doesn't require them.

Speaking to MacOS specifically, I have looked into it, and at least when I looked, automating the entire process was going to be a very involved process. You'd need a Mac to just to get the install files. Then they'd need to be "prepared" before you could even attempt the install. Then it appeared that a variety of hacks might be required to make it run on the various hypervisors, which itself sounded like a nightmare, as it wasn't clear whether all of those prerequisites could be embedded in the bundled Vagrantfile. And if they couldn't that would mean people would download the boxes, have them fail, and then come asking for help, which would be a nightmare to support.

All that said, if someone was willing to put the in time to make it happen, I'd certainly welcome a PR a that added them to the build pipeline. I just can't make it happen myself right now.

[MikePadge]

Not that I'm advocating for it since I think Big Sur is an absolute shit show, but https://www.techradar.com/uk/news/you-can-now-run-a-mac-mini-on-aws-but-not-the-apple-m1

I can't not imagine that all hands at Apple aren't being applied to completely abandoning intel architecture. I wouldn't go near Mac M1 virtualization with 9001 foot pole right now... but I'm dumb and still can't get the main robox.sh script to work in my environment, so take my opinion for what it's worth... peanuts

(edit: 3 days later re robox.sh fails ~ had to increase system ulimit for files open. Those hyperv boxes were just pounding me.)

But I've set Mac environments up in Vbox before

re your link:

To create a box you will need a macOS installer application. If you are using a Catalina host you must use a Catalina installer:

macOS Catalina installer application Tested with 10.15, 10.15.1, 10.15.3, 10.15.4 Catalina hosts cannot use earlier (e.g. macOS 10.14 Mojave) installers, and Mojave hosts cannot use Catalina installers.

If you are using a Mojave host you should use a Mojave installer:

That by itself is such a pain in the ass to keep up with, I literally just quit. I'd rather use ansible via something like this https://github.com/geerlingguy/mac-dev-playbook to setup my Mac post boot, rather than try to pre-bake it.

[ladar]

I'm dumb and still can't get the main robox.sh script to work in my environment

What is your environment, and what can't you get to work? I've used the script on Linux, MacOS, and Windows. All you need is a Bash shell. That said, I haven't tested every function on MacOS/Windows, so if something is broken, let me know. It's probably an easy fix.

To build a box, just run ./robox.sh box BOXNAME ...

As for the configs. I try to do as little as possible during the auto-install phase, since that is the hardest to debug when something goes wrong. Instead I focus on writing modules, in the form Bash shell scripts that get run via SSH, post-install.

[MikePadge]

@ladar I got it sorted. There's some odds and ends in Debian10 that cause a few problems. Also I wasn't using the custom packer binary build.

Not to derail this issue, (continues derailing the issue) but the packer.sh script in res/providers/packer.sh could use a couple of small tweaks. That script nukes the entire $GOPATH directory... ¯\_(ツ)_/¯ I'm fine with this, but it looks like Golang now makes one of those directories read only because "seccurrity" or something. So running go clean -modcache prior to rm -rf $GOPATH is now required.

Also, for whatever reason, on Debian, Go can't make two go gets without that cd back to $BASE between the calls.

# Fetch gox
go get github.com/mitchellh/gox && cd $GOPATH/src/github.com/mitchellh/gox 
go build -o bin/gox .

cd $BASE

# Fetch packer
go get github.com/hashicorp/packer && cd $GOPATH/src/github.com/hashicorp/packer

Without that, the second go get request fails silently, regardless of the order they're in. Whatever is "go get'ted" second fails.

I meant to respond to this post weeks ago, but got lost in whisky and the holidays, so I feel like I might be forgetting a couple of Debian specific things... permissions issues something somewhere that were fairly easy to fix, and then an increase in the default system amount of files that can be open simultaneously.

[mcandre]

Once a Mac is virtualized, you no longer need a Mac to obtain install media.

Also, install media can be cached on a CDN.

On Tue, Dec 29, 2020, 1:13 AM Mike @.***> wrote:

@ladar https://github.com/ladar I got it sorted. There's some odds and ends in Debian10 that cause a few problems. Also I wasn't using the custom packer binary build.

Not to derail this issue, (continues derailing the issue) but the packer.sh script in res/providers/packer.sh could use a couple of small tweaks. That script nukes the entire $GOPATH directory... ¯_(ツ)_/¯ I'm fine with this, but it looks like Golang now makes one of those directories read only because "seccurrity" or something. So running go clean -modcache prior to rm -rf $GOPATH is now required.

Also, for whatever reason, on Debian, Go can't make two go gets without that cd back to $BASE between the calls.

Fetch gox

go get github.com/mitchellh/gox && cd $GOPATH/src/github.com/mitchellh/gox

go build -o bin/gox .

cd $BASE

Fetch packer

go get github.com/hashicorp/packer && cd $GOPATH/src/github.com/hashicorp/packer

Without that, the second go get request fails silently, regardless of the order they're in. Whatever is "go get'ted" second fails.

I meant to respond to this post weeks ago, but got lost in whisky and the holidays, so I feel like I might be forgetting a couple of Debian specific things... permissions issues something somewhere that were fairly easy to fix, and then an increase in the default system amount of files that can be open simultaneously.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lavabit/robox/issues/179#issuecomment-751975923, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAABJRABIB2NDR3OBDDSPQLSXF6SNANCNFSM4T76XZZQ .

[ladar]

@MikePadge did you ever create a MacOS packer config which fits into the Robox layoiut/workflow?