Error Handling Which Preserves Possible Problem File? #180
Comments
|
make a pull request that modifies all instances of the keyword "trap" in the folder parsers/* to preserve the file on failure. |
|
I wanted to run the command manually to see if I catch any STDERR messages that might be missed when in Jenkins. So, continuing in manual mode I accomplished the following. What is interesting is the: Here's my test session: |
|
The exec format error means that something is wrong with how you have qemu setup. Try rebooting. |
|
Three items:
I'll proceed with a reboot now. |
|
rebooted and got same result: |
|
Please see Please try to rerun only that script manually. |
|
What #180 (comment) is referring to is at the outset of my run of buid.sh, specifically line 3 below [I added line line numbers]: The "write error" message is generated by line 35 of binfmt.sh which currently has [I added line line numbers]: The variable $cpu is set earlier in binfmt.sh from a system call to "uname -m". So, I'm guessing that Qemu causes "uname -m" to produce something that matches "armv[4-9]*" thereby triggering the "if" clause at binfmt.sh@33. So the failure at line 35 is the echo command populating /proc/sys/fs/binfmt_misc/register:
The last line, #40, of env.sh, invokes binfmt.sh:
env.sh, in turn, is called by build.sh at line 14:
Note: immediately following line 14 in build.sh are the following: I recall from my previous successful build experience in January 2022, performed in a VM, that I had to manually load a module for btrfs since it was not built into my kernel, there was a requirement the btrfs be working. The lynchpin here looks to be the binfmt.sh@35 failure that is reported out, but does not halt the process. I will try experimenting with the "btrfs subvolume create" and determine what the current system is on my ...chroot. It seems that if echo line fails, everything should halt. I'll update further as I learn more. Thank you, @samip5 for catching this. |
|
The if clause is looking for "arm" under /proc/sys/fs/binfmt_misc/ Since "arm" does not exist, "register" is present, to the "No such file..." message may be referring to /usr/bin/qemu-arm? Has there been a name change from qemu-arm to qemu-aarch64? |
|
https://codepyre.com/2019/12/arming-yourself/ under "Configuration" notes a difference: ... I'm wondering if the reference to qemu-arm is something that needs to be replaced with qemu-aarch64? I'm in an area (qemu) where I know practically nothing, other than arm has been developing and the fact that my qemu installation has no qemu-arm, yet has a qemu-aarch64 has me wondering if the problem I face is a result of progress and deprecation. |
|
You don't want "arm". That's the 32bit version of the arm architecture. You want aarch64. The " arm" check is only there for completeness sake, if someone decides they really want to bother with 32 bit. |
So the execution of binfrmt.sh@35 is for completeness sake and if it errors outs, then the ensuing error message "/home/jlpoole/local/Build.Dist/scripts/binfmt.sh: line 35: echo: write error: No such file or directory" is an expected and/or tolerated error message? |
That means that the writing to the binfmt registry (used to register the qemu instance for arm64 binaries) failed and you should look into why it failed as that's why qemu is not working for you. |
|
I'm confused. @jonesmz says I should not want the arm32 architecture (I agree) and I'm presuming the binfrmt.sh@35 line is for that purpose, yet @samip5 says that the failure at line 35 to write a stream or characters which includes a reference to "arm" to the registry is the essence of my problem. I was thinking the stream needs to be modified for aarch64. What's the point of writing to a registry with "arm" when you are building for "aarch64"? Or am I missing something here? |
The issue with the script is that both should be successful as both will be tried to enable if CPU is not aarch64 nor arm but something else. Does that make sense? |
|
@samip5 , could you be more specific. "the script" is a reference to binfrmt.sh? "both" is reference to what? Also, just for my case, running on an X86_64 platform trying to build for an aarch64, would there be any impact on my build is binfrmt.sh line 35 were rem'd out? |
Yes, the script is referring to You should be able to just comment it out yes. |
Enhancement Request
During failed Build (not running under Jenkins, but in a console as root), a clean-up is performed which removes a temporary file of interest. For example, from Issue #179:
The file of interest is em-5481, but a higher level handler removes the file.
the "+ ret=1" suggests that the handler which then executes the "rm -f..." would know the script is in error mode and likewise might do something that makes the file, em-5481, available. I'm thinking maybe cp the file to /tmp and print out a status report of doing so. I'll take a look and the code and see if what I'm thinking of is possible. I thought filing an enhancement request might highlight this type of approach. If it can be done, I'll do it and see if I can preserve the temporary file for forensic analysis on a future failure.
The text was updated successfully, but these errors were encountered: