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

lib/make-ext4: bump fudge factor to 96 MiB #62262

Closed
wants to merge 3 commits into from
Closed

lib/make-ext4: bump fudge factor to 96 MiB #62262

wants to merge 3 commits into from

Conversation

lukateras
Copy link
Member

@lukateras lukateras commented May 30, 2019

Motivation for this change

resize2fs seems to have a block miscalculation bug that requires fudge factor increase from 16 MiB all the way up to 96 MiB 128 MiB.

I'm pretty sure miscalculation bug is specific to Aarch64, since I can build ext4 images that are only 20-30 blocks away on x86-64 just fine, however I'm not entirely sure since I haven't tested it with exact same filesystems.

Issue can be reproduced by running nix-build https://github.com/transumption/holoportos/archive/6b6497c1fde9c143be16be83948d950670f27d11.tar.gz -A artifacts.installers.holoport-nano. I can create minimal repro if necessary: that said, the only variable that should affect this behavior is the closure size.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS (both Aarch64 and x86-64)
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Assured whether relevant documentation is up to date
  • Fits CONTRIBUTING.md.

resize2fs is not the only utility complaining about missing mtab,
most e2fsprogs do that, including fsck.ext4.
@samueldr
Copy link
Member

This is an annoying issue...

The hydra max output size is 2LL << 30 or exactly two gibibytes.

The output size of sd_image has been slowly flirting with the limit, that change initially was implemented to buy some more time.

With this change, the output is now 14.13MiB over the limit.

nix path-info -s ./result*
with-changes      2162304232
before-changes      2078430440

I say it is annoying because even without having seen and explored the repro, I have no doubts that it could happen. I don't remember what, but I seem to recall having seen something similar with an ext tool when cutting down the slack in the image.

Tangential to your issue (I think) improvements could be made so that sd_image uses the ext4 partition for boot, reducing some duplication, and allowing to reduce the FAT32 partition size to the minimum required for the Raspberry Pi. That would allow the gained space to be redistributed to the ext4 partition.

(And obviously, the better solution would be to explore and trim the installer image, if still possible.)

@lukateras
Copy link
Member Author

Meanwhile, I found another block count that requires a bump to 128 MiB.

I agree this solution is not workable. I'll keep this open while I try to pin down the bug in resize2fs.

@lukateras
Copy link
Member Author

Going to close this for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
NixOS on ARM
Awaiting triage
Development

Successfully merging this pull request may close these issues.

None yet

2 participants