Opened 7 years ago

Closed 7 years ago

#8603 closed bug (fixed)

[wpa_supplicant] binary is corrupted in the nightlies

Reported by: diver Owned by: mmadia
Priority: normal Milestone: R1/alpha4
Component: - General Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All


This is haiku-nightly-hrev44204-x86gcc2hybrid-anyboot.tar.xz

ifconfig /dev/net/atheroswifi/0 join $SSID $WPAKEY
ifconfig: Joining network failed: Application could not be found
du -b /boot/common/bin/wpa_supplicant
230205  /boot/common/bin/wpa_supplicant
unzip -o -d /boot
du -b /boot/common/bin/wpa_supplicant
235940  /boot/common/bin/wpa_supplicant

Change History (9)

comment:1 by humdinger, 7 years ago

Milestone: R1R1/alpha4

I confirm, haiku-nightly-hrev44214-x86gcc2hybrid-cd.tar.xz shows the same wrong filesize. Strange. My own builds, that also add the wpa_supplicant optional package, result in the correctly sized binary... They should download/use the same current package...

comment:2 by diver, 7 years ago

My own builds are also ok. Maybe this file is corrupted on the Buildbot?

comment:3 by anevilyak, 7 years ago

Owner: changed from nobody to mmadia
Status: newassigned

The odd thing is that BuildBot should be completely cleaning it out on each build and doing a fresh download, as far as I'm aware.

comment:4 by mmadia, 7 years ago

A few things for clarity: The nightly-uploader script is completely independent of Buildbot. They both just happen to run on the same partition. The nightly-uploader script does a complete process every time (checkout, build, etc) and no files are re-used from one build to another.

An initial look at the log files reveal no errors/warnings/oddities. The md5sum of the local archive matches the copy on and the extracted binary matches diver's md5sum as well.

# md5 -r 
# unzip -q -d wpa/ 
# md5 -r wpa/common/bin/wpa_supplicant 
3f4e8f3d121ef38aa680712a5fcd8163 wpa/common/bin/wpa_supplicant

Over the weekend, i'll look more into it.

comment:5 by tidux, 7 years ago

I can confirm this on hrev44913 gcc2hybrid. A few of the guys on IRC helped me through it. What happened is that somehow the wpa_supplicant binary never got a MIME type signature, which is why Network can't find it. Try installing a different version of the wpa_supplicant package.

comment:6 by pulkomandy, 7 years ago

Not having a MIME signature is a consequence of the file being corrupted and thus not a valid executable file.

Anyway, AFAIK the nightly uploader (and buildbot) are on a FreeBSD machine. So it may be a problem with bfs_shell on freeBSD or something like that. Anyone tried building on FreeBSD to see if the result is the same ? We need more info on this computer :) Which FS is used ? Which config (attribute overlay, or native xattrs) ? Any other custom things ?

comment:7 by mmadia, 7 years ago

Some more information on the build machine:

  • FreeBSD 8.2-RELEASE-p3 i386
  • UFS filessytem
  • --use-xattr is enabled
  • --use-gcc-pipe is enabled

I've compared an image built from the nightly-uploader bash script, to an image built by BuildBot -- both were equally affected. Looking at ps -aux, i don't see any stray bfs_shell processes or any other oddities.

comment:8 by mmadia, 7 years ago

Status: assignedin-progress

HAIKU_STRIP_DEBUG_FROM_OPTIONAL_PACKAGES = 1 ; is the culprit! Arrgh! (changeset to be committed tonight, with further testing)

comment:9 by mmadia, 7 years ago

Resolution: fixed
Status: in-progressclosed

fixed in hrev44240.

Note: See TracTickets for help on using tickets.