-
Notifications
You must be signed in to change notification settings - Fork 12
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
[Rebuild only] e2fsdroid: Could not allocate block in ext2 filesystem while populating file system #9
Comments
I hit this issue again (very similar) with the 2020-01 security patches and this time a clean build did not help. If anybody either runs into this same issue or if you are not affected, please comment so that I can either check what I am doing wrong or so that we can together search for a solution. Build logs: https://gist.github.com/ypid/580160332bf465ee9aa74336e748ea70
cc: @ubergeek77 |
Does this only happen when you try to do a "re" build against a new security patch? Or is it happening for any rebuild, even if you haven't done a new I've been doing local rebuilds to test some cherry-picks for my device, and I haven't run into anything like this. A full build takes about 3-4 hours on my hardware, but a rebuild with cherry picks takes ~15 minutes. Since my cherry-picked rebuilds are done in that much shorter time frame of 15 minutes, and the resulting images flash just fine, I know for certain that my rebuilds are working properly. However, I haven't gone from one upstream build reference to another, so I'll be able to comment on that when the February one rolls around. I'm building for I know this is a longshot, but you do have enough disk space, right? That particular error looks like it could happen on lack of space. |
That error output from your first comment caught my eye:
I'm not aware of this, but is there a limit on the number of inodes a Linux filesystem can have, regardless of location? It's a stretch, but perhaps you're hitting this limit. If that was what was going on, deleting Or, if they aren't talking about your system, but instead the filesystem that the build process is trying to create, maybe there's a bug in the python script that's over-active to the number of files/inodes in the If you're sure your local filesystem has no issues, then my recommendation would be to see if "e2fsdroid" or "e2fsprogs" has any notable changes between device trees (such as on crosshatch), and if there are, modify your build manifest to pull down crosshatch's branch versions of those instead. If there really is a bug there, considering this isn't happening to me, maybe that will fix it. |
I checked the obvious things already I hope.
That is also my understanding. I guess I will need to investigate further. Thank you already for your help 👍 |
Thanks, btrfs does not use inodes :)
|
Oh cool, that's a TIL for me, I didn't know that. |
I fixed it in the third clean build. I changed two things:
I will leave the issue open for now because the original one has probably a different cause. |
I'm running into this issue on coral as well when building AOSP (not the kernel). I'll try
|
I have the same problem as above, except it fails on My error:
|
Jup, that also happened to me this month.
The second build attempt was successful. But I can not see anything being wrong with my first build attempt either. Both were clean builds. My hope is that those errors go away with #4 (GrapheneOS also lists Debian buster as supported). You might try that. |
For me, this was a result of attempting to write to a zfs drive. As soon as I pointed to an ext4 drive the build succeeded. |
I should also mention that I always have this failure on a NFS drive too (backed by ZFS). Occasionally I've had the issue on a a non-clean build (as mentioned in #9 (comment)) on ext4. |
Interesting. ZFS is only partly involved in my setup. My build machine looks like this:
The VM was still on 4.9.0-12-amd64 until this day. My next build will be on linux-image-4.19.0-0.bpo.9-amd64. |
I wonder if it's btrfs that's breaking the build for you. The error messages are pretty confusing and I had a hard time narrowing down where the issue is with e2fsdroid. |
BOARD_VENDORIMAGE_PARTITION_SIZE might be the right one? |
guys iv encountered this same error when doing a dirty build of aospa https://del.dog/stilyfugov.txt any fix for it? |
Yes, this is the right solution, make sure that BOARD_VENDORIMAGE_PARTITION_SIZE is a bit larger than the total size of out/target/product/xxx/vendor |
This the error I got looks similar how to fix it ?? Edit(ypid): Use Markdown code blocks. |
Well:
Are you sure you are using https://github.com/hashbang/aosp-build ;-) ? |
i am facing the same du: unknown option b error... |
First step would be to post what exact build environment you are using. I just found evidence that @zoldycc is not using Hashbang OS, ref:
When you have confirmed that you are actually using Hashbang OS, open a new issue. The |
Possible root cause in the ZFS on linux implementation: |
Refer to this: releasetools: Use du -b
toybox commit: landley/toybox#177 Test: m, builds and boots. |
For me, it was caused by the ROM I was building, including gapps. I solved it by removing some of the google apps that do not neccessarily need to be inbuilt in the ROM from |
I now hit this issue the third time. This only happens when I make changes in the source code and the then do
make build
again. Any idea how to solve this instead of deletingout
? A clean build does not have this issue.The text was updated successfully, but these errors were encountered: