stub: add fat variant #182
No reviewers
Labels
No labels
bug
dependency
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
review-next
security
stub
tool
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: raito/lanzaboote#182
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fat-uki"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
A compile time feature is introduced that allows to build "fat" stubs that can be used to build "fat" UKIs. "fat" here means that the actual kernel and initrd are embedded in the PE binary, not only the file path and hash. This brings us one step closer to feature partiy with systemd-stub and thus one step closer to replacing it fully. Such a "fat" or "real" UKI is also interesting for image-based deployments of NixOS.
The new tests use
runTest
the future of testing in NixOS. See https://github.com/NixOS/nixpkgs/pull/230523Thank you @RaitoBezarius and especially @blitz (and all the others who have contributed). The stub code is so well structured and well commented so that it was easy to extend even without any prior experience in UEFI or no-std environments.
@ -0,0 +33,4 @@
impl EmbeddedConfiguration {
fn new(file_data: &[u8]) -> Result<Self> {
Ok(Self {
kernel: extract_bytes(file_data, ".linux")?,
You should actually probably relies on UnifiedSections here, it would make the code much nicer in line with systemd expectations?
@ -0,0 +33,4 @@
impl EmbeddedConfiguration {
fn new(file_data: &[u8]) -> Result<Self> {
Ok(Self {
kernel: extract_bytes(file_data, ".linux")?,
Good idea. Let's do this in a separate refactoring.
(I wish
crane
provided a proper‘features
array)Would be nice if upstream found a way to expose the binaries properly?
that's not prod ready :D
Did you apply shellcheck on the script?
I really wish we use our tooling here someday and not objcopy, etc.
I'm not sure those log are useful, aren't they breaking the quiet thing too?
(maybe keep them actually, because we have max level warn on prod anyway)
It does introduce some code duplication in certain areas, but I feel like this is an interesting step. :)
I don't know if it makes sense to have
pkgs.systemdUkify
. But I understand that they don't want Python in their normal systemd closure.That'd be nice
Well, since we can't really rebuild properly in a VM test anyway its as prod ready as we need for the tests :D
True, but it's also nice that we can test the upstream systemd stuff.
It propbably doesn't make too much sense to keep them. It just a left over when I wanted to make sure that I'm actually booting a fat UKI.
I replace it with
writeShellApplication
which will always run shellcheck.Removed them. They were also kind of in the wrong spot.
Thanks for the review!
I think most of the duplication is incidental duplication though. And I think it is better to have separate modules than a main littered with
cfg()
statements everywhere even if that increases duplication a little.I'll give @blitz some time to also look over this PR. :)
We discussed offline that I just look over this after it's merged. 👍