-
Notifications
You must be signed in to change notification settings - Fork 10
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
Build Fails 1/4/2023 #179
Comments
I confirmed now, at 8:43 AM, that my fork is still in sync with the project. |
You seem to be hitting a snag with qemu as |
I'm testing distcc and, accordingly, modified my make.conf. Here's what is the current configuration:
|
Discussion on the project Discord channel suggests pychroot may be a source of the problem. Here's what I have installed:
There was an investigation into an early failure at environment setup where "arm" registration is made for qemu, turns out the "arm" registration was not necessary and the code line rem'd out and a build attempted thereafter. Result was failure: https://pastebin.com/C1WnM6g1 |
I recommend that you stop attempting to run build.dist's build.sh script until you've completely solved your qemu issue. Just run the equivelent of the following commands, adjusted for your local environment (and any syntax errors I may have written), after a fresh reboot
and then see whether or not qemu fails to be engaged as your aarch64 code executor. if it works, you'll be in the chroot. But i really do not recommend continually running the |
Thank you, Mike. qemu looks to be working. See log executing your instructions + running nano + compiling a Hello World file and running same in chroot and then in native x86_64 where is failed as expected. What is your suggestion I do next? |
alright, that's great. So now that you've got a working aarch64 emulator that works without having to be copied into the chroot environment (the F flag in the binfmt text), the next step is to try re-running the build.dist |
I have determined that the problem concerns the command to be executed in the new environment:
To learn what's going on, and to verify that chroot.py is doing what it is supposed to be doing, I created a similar file to the one that parsers/rawcommand/rawcommand [a Bash script] creates and tries to execute for the task "locale". My file is suitably named "jlp_was_here" and was placed in the chroot environment at build/GenPi64OpenRC/chroot/jlp_was_here.
To simulate the build script, I created another test script:
The results of the session run were successful (note: the eselect command was rem'd out):
I'm not at the finish line, but felt what I have done here might be instructive to others who might encounter the issues I did and want a way to test. Seeing all the output of chroot.py is fascinating and ought to provide further insight into what is going on. I think the next test would be to compile and then run a Hello World program via a script similar to test_chroot.sh, that ought to help answer questions about whether qemu is working or not. |
Qemu appears to be working, too. I created three files, similar to my previous experiment, to test invoking qemu.
|
change root into the environment and executing the command did not trigger any errors:
|
That's great that you have it working now! |
No. Something in the build script process does not provide me the same environment I just demonstrated below. From a build.sh standpoint, the problem still exists.
So, I need to understand why the disparity of results and fix something. |
Perhaps the most efficient way to figure this out is to have either myself or @samip5 ssh into this machine and do some diagnostics. You had this working in the past. |
Unfortunately, as the system is running systemd, it wouldn't be a good idea for me to try to use pychroot there. The same exact step is working fine inside Jenkins. Unless you're not talking about that but rather to their machine? |
I also have a strong feeling that only part of the issue is pychroot which we have had issues with in the past and systemd-nspawn at least is not recommended to even try on openrc as it will screw up things. EDIT: Our builders use systemd-nspawn and not pychroot so that maybe why you're facing issues as it's not getting tested much. |
My understanding was that jlpoole used openrc, not systemd ? |
Correct. all my Gentoo systems are OpenRC. |
I'm saying that as our builders use systemd, the pychroot one doesn't get as much testing so could definitely be broken in one way or another. |
I may have found the problem, and it may be a misplaced double quotation mark in rawcommand. My question is, I got the locale step?/task? which creates a little file executing:
and after I successfully ran it, it looks like the results are cached somewhere so on my next run it skips that step. I want to force the step/task to be reperformed to trigger the error as I want to test a difference in the code for rawcommand. What file stores previous results and what do I do to force that step to be performed again, and again? Obviously, I do not want the 15 minute huge download and processing steps that precede this step. |
found the cached file: build/GenPi64/completed-gentoo-base @jonesmz also suggested on Discord just as I found it. I'm getting mixed results with the placement of the double quote on line 22 rawcommand. Still experimenting. |
Here I am a year later, attempting to build on a new and faster machine with the current Gentoo image and ran into the same problem. Referencing this comment of this bug, I attempted to chroot into the new environment and my attempt failed:
A search suggests that problem is that the command '/bin/bash' is not present in the new environment, but the above proves that it is. I'll update this bug when I am able to successfully chroot and overcome this problem. |
It is in fact present (otherwise it would tell you it did not find it rather than the current error), just wrong architecture one. I think you're building on amd64, and the bash binary is arm64, so you should setup qemu properly for user land emulation. |
That is correct assessment, @samip5. I did not have qemu configured for "aarch64" and will be re-emerging accordingly. |
I setup qemu properly:
and then proceeded to build anew. In other words, I erased the prior build directory and ran the ./build.sh script which started all over again. I ran into this same problem just now:
I recall a problem, before, about white space (tabs vs. spaces) in a script file wreaking havoc by nullifying the command that was intended. This looks a lot like it might be the same issue. I'll have to go back and review my notes. |
I kept getting failures trying Jenkins and concluded I must have some setting in Jenkins different from the GenPi64's project. I requested access to the project's server so I could compare the configuration settings of the OSU jenkins vs. mine. While I await a response, I decided to try building the project without Jenkins to anticipate any problems and see if i could fix them outside of a Jenkins environment.
On January 4, 2023, at around 8:18 AM, I pulled a copy of my fork which was updated yesterday and confirmed to be in sync this morning and the build failed. Log at https://pastebin.com/Rt0ATBN9
The text was updated successfully, but these errors were encountered: