Questions regarding the building documentation

[doronbehar]

So I want to use robotnix in the most straight forward way, without delving too much into details, and I'm a bit confused by all the paths to go through in the docs/src/building.md file. I wish there was a more concise way of explaining how to build and install the image - with password signed images, and for signed images with empty passwords.

More crucially, I don't understand: What is the purpose of producing an unsigned image? Why isn't signing.enable = true; by default?

It took me ~3 days on my office machine to build an image without specifying signing.enable explicitly, and only now I noticed that I need to sign my images, at least according to the docs/src/installation.md page.

Thanks for creating this project anyway :) It is very appreciated.

[Atemu]

I can't help you with signing as I have never done it myself but I can answer a few questions:

Why isn't signing.enable = true; by default?

Because you need to generate yourself a keypair beforehand and then either pass it into the derivation (requiring extra setup with privileges) or run a signing script outside the drv.

We can't expect users to set all of that up to build a basic image when they don't even need signing.

[doronbehar]

Why isn't signing.enable = true; by default?

Because you need to generate yourself a keypair beforehand and then either pass it into the derivation (requiring extra setup with privileges) or run a signing script outside the drv.

Hmm I understand, but I am positive that many users could benefit from a 1 liner such as:

$(nix build --print-out-paths --no-link .\#robotnixConfigurations.dailydriver.generateKeysScript) ./keys && \
nix build --option extra-sandbox-paths /keys=$(pwd)/keys .\#robotnixConfigurations.dailydriver.img

I haven't tested such a command yet, as I haven't yet built my signed image, but I'm positive such a command and such simplified instructions can be constructed. Maybe the docs building.md and installation.md could be merged into 1 page, with TL;DR list of commands one can run and get an image with less effort.

We can't expect users to set all of that up to build a basic image when they don't even need signing.

I still don't understand, is the unsigned image I built in 3 days worth anything? If not, perhaps we can add a trace warning that an unsigned image is just used for testing? If I can flash it, I don't understand the instructions in installation.md - they mention all kinds of files I didn't yet build.

[Atemu]

$(nix build --print-out-paths --no-link .\#robotnixConfigurations.dailydriver.generateKeysScript) ./keys

Yet another step and an unnecessary one if the user doesn't need signing.

nix build --option extra-sandbox-paths /keys=$(pwd)/keys .\#robotnixConfigurations.dailydriver.img

That will only work if you're a trusted user on the system. For good reason as allowing this for any user would allow for privilege escalation. This also breaks standard Nix build properties such as r13y, the ability to do remote, distributed builds and likely more.

Maybe the docs building.md and installation.md could be merged into 1 page, with TL;DR list of commands one can run and get an image with less effort.

Better docs are always welcome :)

I still don't understand, is the unsigned image I built in 3 days worth anything?

Sure. You can install it and use it like any other build. It's still signed, just with a publicly known test key. You'll get a warning you can disable in system settings but that's about it.

If I can flash it, I don't understand the instructions in installation.md - they mention all kinds of files I didn't yet build.

That guide appears to be specific to pixels? It's been years since I last looked at these.

[doronbehar]

Thanks for trying to help @Atemu .

I still don't understand, is the unsigned image I built in 3 days worth anything?

Sure. You can install it and use it like any other build. It's still signed, just with a publicly known test key. You'll get a warning you can disable in system settings but that's about it.

Thanks, that's consolidating.

That guide appears to be specific to pixels? It's been years since I last looked at these.

Yes, are there any other manufacturers that support unlocking the bootloader like the pixels?

Better docs are always welcome :)

I'd really like to help, but I am not familiar with the details of all the different ways of installing an image. Perhaps we can work on this together? 🙏 I think it can help a lot to this project. I'd like to suggest the following structure for the documentation, where every section first lists a command, and above it a 1 paragraph / 1 sentence explanation of it.

Building and Installing

Explain the difference between signed and unsigned builds, and the implications of using unsigned builds etc., and the advantages and disadvantages.

Unsigned Builds

Building an unsigned image with a flake setup

Building an unsigned image without flakes

Installing an unsigned unsigned image

Signed builds without password

Explain that you need privileges to use the nix option extra-sandbox-paths - if that is not available, refer to the [next section](#signed-builds-with-a-password).

Building a password-less signed image with a flake setup

Building a password-less signed image without flakes

Installing a password-less signed image

Signed builds with a password

Building a password signed image with a flake setup

Building a password signed image without flakes

Installing a password signed image

[Atemu]

Yes, are there any other manufacturers that support unlocking the bootloader like the pixels?

Indeed there are. Quite a lot actually. The LOS devices wiki has a subset of them (bootloader unlock is required to install it afterall): https://wiki.lineageos.org/devices/

I'd really like to help, but I am not familiar with the details of all the different ways of installing an image.

Me neither but I can explain what I know.
There's fastboot which does a relatively dumb image -> partition flash (bundled into a zip file) and there's "OTA" zips you can install via a recovery.
I believe the former is intended for development (having a --wipe-data flag too) while the latter is the one intended for end users (I think pretty much every OEM uses this in one form or another).

Perhaps we can work on this together? 🙏

I'll likely be very busy with $life the coming months :/

I'd like to suggest the following structure for the documentation, where every section first lists a command, and above it a 1 paragraph / 1 sentence explanation of it.

Sounds good to me.

I wouldn't want that structure for anything more than an command example section though as doc text shouldn't differentiate between flakes and non-flakes at every point but rather explain the generic differences with flakes once. Same with the possible methods of signing; in-drv signing cannot use an interactive password due to its nature while you have the option to do it with or without using the post-drv script.

Having a quick command reference would be useful though.