Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] rootfs: handle cross-compilation with a dummy rootfs #91

Closed
wants to merge 1 commit into from

Conversation

samueldr
Copy link
Member

@samueldr samueldr commented Mar 8, 2020

Note that this rootfs will not boot, and it's by design.

It does not have the appropriate filesystem label, nor does it have the
right UUID.

This may look absurdly useless, but I assure you it's not.

With this scheme, some targets are easier to deal with. Namely, those
that allow booting from multiple boot sources. With the u-boot system
type, you can produce a full disk image that can be burned on an SD
card, and will boot the internal storage's rootfs that was already
present.

This makes it much more trivial to deal with stage-1 development while
sitll booting the internal rootfs.

Though, I'm not expecting this behaviour to remain.


Notes

I don't know whether this will be merged. For now I'm using this and I thought others might find this useful.

I'd prefer instead figure out a good way to configure that as a local.nix thing instead of hijacking the build process.

Furthermore, I'd prefer if we could trivially build a rootfs that is cross-compilable, even if it is minimal and not representative of a fulle system.

@samueldr samueldr changed the title rootfs handles cross-compilation with a dummy rootfs rootfs: handle cross-compilation with a dummy rootfs Mar 8, 2020
@samueldr samueldr added the 4. type: enhancement New feature or request label Mar 8, 2020
@samueldr samueldr changed the title rootfs: handle cross-compilation with a dummy rootfs [WIP] rootfs: handle cross-compilation with a dummy rootfs Mar 8, 2020
Note that this rootfs *will not boot*, and it's by design.

It does not have the appropriate filesystem label, nor does it have the
right UUID.

This may look absurdly useless, but I assure you it's not.

With this scheme, some targets are easier to deal with. Namely, those
that allow booting from multiple boot sources. With the u-boot system
type, you can produce a full disk image that can be burned on an SD
card, and will boot the internal storage's rootfs that was already
present.

This makes it much more trivial to deal with stage-1 development while
sitll booting the internal rootfs.

Though, I'm not expecting this behaviour to *remain*.

(cherry picked from commit f8dbc5a)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
4. type: enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant