-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Cannot build kernel with debug symbol if build box has only 8GB or RAM #5218
Comments
Jira ticket: AR-1743 |
The build process is fine once I comment out the line:
from prepare_host_init in lib/functions/main/start-end.sh. With the commented-out line, I get a linux image with a data.tar of 3.2GB on its own. So with the copy dpkg-deb imports this makes 6.4GB of minimum required memory for the build system for a debug kernel. |
Yep, we could add a way to skip tmpfs for those specialized debug builds. |
Building the debug kernel is broken with armbian default CONFIG_MODULE_COMPRESS_XZ=y. The kernel scripts/package/buildded strip and resigning the modules after the modules_install stage. Plus armbian instance of this script had a bug in that it was doing "make clean" before copying vmlinux into the debug build directory (thus the debug files like vmlinux were already cleaned and their copy failed). This is for the BUILD_DEBUB in the non-native case:
back then I made a modification of the script to move the debug package creation before the make clean. So I believe you will find nobody that was building armbian kernel with debug info as that was broken. The thing is with SSD, with the tmpfs or without it seems to make no difference speed wise for the work directory. |
Hmm, I thought I had explicitly forced How are you getting around these? (I suppose, "by editing config after those changes are done").
Indeed. After armbian-next, we work on a copy of the build dir, and only for packaging, not for building -- that's half the reason we've a tmpfs, so we can clean/work/massage the built tree for packaging, without throwing away the build cache itself.
Much to the opposite. Igor has some beasts, yes, but I myself build on more constrained devices, even on SD/eMMC cards, and I/O slowness is as much a factor as CPU-limitedness.... :-D Either way this is very interesting and supporting debug builds are something we should revisit for 23.08. Thanks for the investigations |
I have a copy of the armbian kernel config from back then with my two changes (compression and debug). I copied it into userpatches/linux-rockchip64-edge.config from back when I first build with debug info. Might be outdated. Also, now that I doubled checked the -dbg package is not built by armbian-next build framework. This is not a matter of simply adding back the CONFIG_DEBUG_INFO=y back as I already have it in my config. The modules are still built with debug symbols thus the bigger build size. So maybe the debug symbols are still shipped but in the non -dbg package, this is as there is no symbol stripping command.
|
Yes. Thanks for explanation. I, in fact, failed to port over the -dbg .deb packaging from back when we had 17+ different mkdebian/builddeb patches. (also happened to libc-headers, but that's a different story). Looks to me we need simple yet official way to, simultaneously
could be something as simple as
Actually, in our Docker impl, (temporary) Logs are also handled the same tmpfs way -- that makes a huge difference on slow I/O machines.
On fast I/O subsystem, indeed. A lot of us build on small SBCs with only eMMC/SD, believe it or not. (definitely not debug kernels, though). |
Not for now. But I definitely added already added it to my todo.
This might not be required. The debug symbols are stored in /usr/lib/debug
I would keep it only the linux-image debug symbol package with the -dbg suffix as upstream does, wouldn't you?
if there is already tooling to detect the RAM size we could keep the tmpfs if 10G is available. It is just that the dpkg-deb step duplicates the whole kernel. 8G is not enough though.
What do you mean by "account for"
I noted that PAHOLE config needs to be set, though the correct values are above my league. I simply refreshed the config with pahole installed. Without that, the build fails. |
A few items I noticed, I still cannot work on adding the -dbg support though.
I have an issue that triggers at least when I build with the debug symbols but not stripped from the kernel image and modules (ie not in a -dbg package), that is the image and initramfs get too big for default armbian u-boot offset settings and thus u-boot fails to load the kernel and initramfs with invalid image errors. It could be that having these symbols splt in /usr/lib/debug -dbg would avoid this issue. Maybe this bug report should be renamed to encompass a request to implement -dbg package generation. |
What happened?
Linux debug kernel package build abort in dpkg-deb on no space left on device. It turns out that
armbian mount
/armbian/.tmp/work-<id>
as tmpfs at 99% of the RAM.But on my box there is only 8GB of RAM and the debug kernel and its debian package directory are bigger than that amount.
Just before error, running
for i in $(seq 1 100); do date; df -h ; sleep 2 ; done
in the build container (docker exec -ti stupefied_dijkstra bash
) I see that WORKDIR tmpfs gets full. No way to see that from the docker host it seems.How to reproduce?
./compile.sh BOARD=helios64 BRANCH=edge RELEASE=bullseye kernel
with in userpatches an edge kernel config with debug info enabled:
Branch
main (main development branch)
On which host OS are you observing this problem?
Bullseye
Relevant log URL
https://paste.next.armbian.com/zibewonidu
Code of Conduct
The text was updated successfully, but these errors were encountered: