EFI boot?

[deitch]

Does RancherOS support EFI booting? Looking at the distribution iso for 0.4.3, I see /boot directory but no *.efi files, which leads me to suspect that it does not?

[ibuildthecloud]

We don't package an EFI image, but it will boot from EFI if you already have a bootloader in place. It would be nice if we created an image, it would make it much easier to run on my Minnowboard Max.

[deitch]

Shouldn't be too hard to extend the image to do it. Use efilinux from Intel or shim from Fedora could even get it working with SecureBoot, although that is less of an issue. I would be happy with an iso that boots straight from EFI with SecureBoot disabled.

Minnowboard Max?

[deitch]

I got it working. There still are 2 issues:

1. It takes an extra 10 seconds or so to start up (although I suspect that is VirtualBox's EFI implementation)
2. It doesn't yet support SecureBoot (but easily could with shim)

You want a pull request?

[Xe]

I'd be interested in this

[deitch]

Gosh, this was a month ago. @ibuildthecloud do you want a PR on this? I would like to add all of it, but:

1. I need to find some time (paid work comes first)
2. I am not putting in the effort unless I know it will get merged

[ibuildthecloud]

We 100% would want a PR. Sorry for the delay.

[deitch]

A little busy, @ibuildthecloud ? I cannot imagine! :-)

I need to dig back in and find this stuff. I just implemented a platform with secure and encrypted apps on a root drive that even physical access to the machine cannot give you... but no need for a user to be present to enter the unlock password. I did it on Debian, but since the apps themselves are just containers, I would love to do it over Rancher too. If only I had the time.

Either way, got all the way into initram and MBR and UEFI and GPT and TPM and encryption and kernel and and ....

I will try to dig this part out and set you up for UEFI boot.

[deitch]

@ibuildthecloud when I run a full build, what platform do I build it on? What are the prereqs?

[deitch]

@ibuildthecloud yes, completely confused. How does the build process work? Do I run it on my local Mac? On a Linux machine, and of what flavour? Does it build inside a docker container or locally? There isn't much info there.

[deitch]

And my head is spinning around the dependencies. What is vbox doing in the initrd?

[ibuildthecloud]

@deitch You might want to work off the v0.5 branch we have the build is completely different there. We are in the middle of a bit of a transition. The build in that branch is kicked off by running make. It runs in a container so you can run it on a Mac assuming you have Docker setup (Docker for Mac or Boot2Docker).

[ibuildthecloud]

@deitch There are almost zero dependencies of the host required, just make and curl. vbox is in the build because people want vbox tools for docker-machine to work right. Currently it is not fully used.

[deitch]

That works, much easier.

Yeah, I have D4Mac on my MBA for a while. Even got on the latest Beta, but it requires a CPU feature not available on my 5.5-yr-old Air.... and Apple's offerings are so pathetic (and old) now, that I cannot bring myself to spend the money to upgrade. Contemplating an alternate ultrabook and running Hackintosh or Win10 with Linux/Hack VM, or maybe even Linux desktop. Insane.

I am forking now.

[deitch]

Do you have any idea why github only includes 5 branches in the fork? I can always do it locally on my laptop - add upstream, add tracking branch, then push to origin - but that is a pain.

[deitch]

OK, got the branch. Next question. Running make pulls a large list of targets from scripts/, basically every file there except clean and run. Each of those is just a target for .dapper <script>. And then there are a series of what look like really small image Dockerfiles in images/.

How does this all tie together?

And for EFI, we essentially need:

• wget (or curl) a package, unzip a file out of it,
• install the correct directories and files in the right place in the image - I figured this out
• some changes to the iso creation process - I figured this out

The above will handle booting the iso; booting when installed local is more, but one step at a time.

Where do I run the wget and curl? images/ directory looks like boot-up processes; package-iso is where I actual install onto the CD image, but not getting the files needed. Do I put it in Dockerfile.dapper? Where is a better place?

[deitch]

I am having an issue with the clean (non-EFI-modified) build failing. Will open a separate issue.

[deitch]

As for the build, I finally am getting my head around how this is structured. A doc would have saved lots of headache, but OK, here we are:

1. make calls the default target of ci
2. default target of ci calls ./.dapper scripts/ci, which sets up the entire environment in a container, and then in that container calls scripts/ci
3. scripts/ci itself calls just 4 scripts: build, test, prepare, package

Each of those scripts in turn calls others:

• build: calls build-target, which builds the ros binary via go; build-host, which just ensures host_ros is a copy of ros
• test: runs tests
• prepare: runs four scripts:
• * template: generates build/os-config.yml from its template
• * build-images: builds an image for each of the ones in images/ directory, which serve as the system-docker images to run services
• * tar-images: saves all of the above images to a tar file once built
• * layout: creates the initrd directory structure
• package: runs three scripts:
• * package-rootfs: creates the root file system structure and zips it up into a .tar.gz, then creates an initrd cpio file
• * package-initrd: identical to package-rootfs, no clue why it is there
• * package-iso: builds the iso file

So... given all of the above, I think that the right place to put the steps is:

• Download necessary files in Dockerfile.dapper - that is our build environment
• Do installations in iso in package-iso - that is what is responsible for packaging stuff into the ISO format.

Is that correct?

[deitch]

PR in. Ball in your court, @ibuildthecloud

[pwFoo]

+1 EFI boot would be nice.

[deitch]

@pwFoo PR is in and ready to run. That will, at least, get the live iso to boot on EFI. Once someone gets ros install working on v0.5, then we can get the local install bootable on EFI as well.

[jeff-h]

Once someone gets ros install working on v0.5, then we can get the local install bootable on EFI as well

Are you saying that your PR will allow me to boot Rancheros from a USB drive using UEFI, but once there I won't be able to install it onto the internal HD in a way that will allow me to boot the new internal install using UEFI?

[deitch]

Just about @jeff-h. I can get that working as well. But I was stuck on two things:

1. ros install was not working.
2. The first step - making it work off of a live cd/usb which is the PR - was open as a PR.

I didn't want to put the extra effort of getting the second step - local install - working until the effort for the first step paid off (PR merged). And I couldn't until ros install worked.

It looks like ros install might be working. If so, once they merge the PR, I will look at getting local install to work in between client work.

I'm a little hesitant, since the effort for the first step doesn't appear to have been accepted and used, but if it gets merged, I will look at it.

[jeff-h]

I think I've blurred my comments on this issue and the PR, sorry! My question asking if you "have any suggestions for how I could use your ISO to actually install a usable RancherOS onto my little PC?" actually belongs here, I think.

I'm guessing it's not going to be trivial, so I might just have to go with another OS for a while, although nothing else I've found installs easily on an Atom system either, it seems.

[deitch]

I'm doing this all on my iPhone over 3G, so I couldn't tell you where anything goes!

Sorry, no suggestions. I know how to do it, but haven't put in the effort yet.

I love the idea behind rancheros, which is why I put the effort on. I have a secure appliance OS build; I would look quite seriously at merging the security into rancheros and use it if I felt that the effort would get merged.

[deitch]

@joshwget @SvenDowideit @ibuildthecloud so... we getting this one back in?

[SvenDowideit]

yes. I need to finish up #1361 first tho (and then go out and buy some ssd's for my ARM build boxes.

[deitch]

I need to finish up #1361 first tho (and then go out and buy some ssd's for my ARM build boxes

I am all for good toys and new build environments, but why does that need to finish first? We know the issues (see the PR), let's get it working conditionally (Intel only, no EFI on ARM), then we can add a PR to get EFI working on ARM. (then we can get ros install working with EFI...)

[deitch]

Just surprised at the complexity. The merge happened very quickly once we decided to do it. Granted, we had to back it out because we didn't think about ARM, but we can add the exception case there, like @ibuildthecloud suggested.

[SvenDowideit]

basically, it happened very quickly because we didn't have a trivial build system that let us quickly build&test on all 3 HW platforms - my goal for this week is to change that at minimum for amd64...

[deitch]

There was no automated CI for all potential deployment platforms? Ouch.

Once that is in place, I will be able to submit a PR, and the entire system with the PR as if it had been merged will be run on all targets and report before we accept the merge?

Love it! This kind of building platforms is just fun. I am doing something similar with a company, although it is more software, so simpler.

Which CI system are you using?

all 3 HW platforms

3?

Either way, will you comment here when ready so I can resubmit the PR and get it in?

[SvenDowideit]

don't wait for me - make the PR, and it'll get built as soon as things look like they might hold together :)

[deitch]

OK @SvenDowideit but...

1. I am traveling the next week or so, and have been doing this on a Linux machine I have, so it will have to wait until I am back
2. It will get merged in, right? Once it passes tests? I don't like putting work in that goes nowhere.

[Xe]

Is there any update on this?

[deitch]

@Xe when Rancher and @SvenDowideit are ready for it (committed to putting it in), I will redo it (or Sven will?). After having done the work and getting it a year ago (pre-0.6) and it went nowhere, reluctant to put in even a few minutes unless I know it will go in.

[jaknoll]

+1 on this one. Would love to see it added.

[kanthamohan]

+1 for this feature to be added

[TrueOsiris]

[Trump]Still no (u)EFI support? So sad[/Trump]

[abuisine]

I got a small package which works like a charm for UEFI boot, is there a way to contribute to the project in that regard somewhere ? contribution being doc or images.

[deitch]

Been almost 2 years since I opened this and a PR. Done lots on linuxkit to support it, including on arm64. Not likely to come back to this, but since RancherOS is built on linuxkit nowadays, shouldn't be too hard?

[steve-todorov]

ping @joshwget @SvenDowideit @ibuildthecloud?