Problem with busybox compilation in buildroot

[pielgrzym]

Hi,

I'm trying to fry my own version of Interlock with buildroot. Unfortunately the build fails during busybox compilation:

  CC      applets/applets.o

In file included from include/busybox.h:8:0,

                 from applets/applets.c:9:

include/libbb.h:279:7: error: size of array ‘BUG_off_t_size_is_misdetected’ is negative

  char BUG_off_t_size_is_misdetected[sizeof(off_t) == sizeof(uoff_t) ? 1 : -1];

       ^

scripts/Makefile.build:197: polecenia dla obiektu 'applets/applets.o' nie powiodły się

I'm running Debian Jessie. Tried explicitly passing CONFIG_LFS=n but no luck - build still fails :(

How can I fix this?

-- 

Thanks, P.

[Andrea Barisani]

Hello,

I assume that you want to build the whole embedded INTERLOCK distribution (if you require just the INTERLOCK app you can just compile the application directly from its repository).

I managed to reproduce the issue you are reporting on Debian stable (in doing so I had to tweak our conf a little as it was triggering some errors, it has been improved and just committed). These issues pop up from time to time as our instructions tell to use the git HEAD branch for buildroot, however as you prove this results too experimental in certain branches and prone to introduce build errors.

Interestingly enough it seems that CONFIG_LFS is always overridden to "=y" despite the fact that our busybox.config does disable it. I will investigate this further to address it.

In the meantime I recommend that you test with a buildroot branch that we verified, I just noted this in our related README file:

git clone git://git.buildroot.net/buildroot
# NOTE: you are welcome to try the current branch and report any issues that
# you may encounter, for the last tested branch checkout the following one:
# git checkout cf28e23e317fc449b280fcc299f8d6fd8c0506c5

If you would be so kind to update your usbarmory repository and start from scratch you could also test the bump to kernel 4.4.3 which I've also introduced in the commit.

Thanks!

 

-- 

Thanks, P.

[Andrea Barisani]

On Sunday, March 6, 2016 at 10:28:02 PM UTC+1, Andrea Barisani wrote:

On Saturday, March 5, 2016 at 8:02:22 PM UTC+1, pielgrzym wrote:

Hi,

I'm trying to fry my own version of Interlock with buildroot. Unfortunately the build fails during busybox compilation:

  CC      applets/applets.o

In file included from include/busybox.h:8:0,

                 from applets/applets.c:9:

include/libbb.h:279:7: error: size of array ‘BUG_off_t_size_is_misdetected’ is negative

  char BUG_off_t_size_is_misdetected[sizeof(off_t) == sizeof(uoff_t) ? 1 : -1];

       ^

scripts/Makefile.build:197: polecenia dla obiektu 'applets/applets.o' nie powiodły się

I'm running Debian Jessie. Tried explicitly passing CONFIG_LFS=n but no luck - build still fails :(

How can I fix this?

Hello,

I assume that you want to build the whole embedded INTERLOCK distribution (if you require just the INTERLOCK app you can just compile the application directly from its repository).

I managed to reproduce the issue you are reporting on Debian stable (in doing so I had to tweak our conf a little as it was triggering some errors, it has been improved and just committed). These issues pop up from time to time as our instructions tell to use the git HEAD branch for buildroot, however as you prove this results too experimental in certain branches and prone to introduce build errors.

Interestingly enough it seems that CONFIG_LFS is always overridden to "=y" despite the fact that our busybox.config does disable it. I will investigate this further to address it.

Sorry, it's actually the other way around.

On the latest buildroot HEAD, with CONFIG_LFS=y the issue is solved, the problem is in fact that our configuration unsets CONFIG_LFS.

I will re-test this tomorrow to confirm it and commit a working configuration.

[pielgrzym]

Hi :)

On Sunday, March 6, 2016 at 10:28:02 PM UTC+1, Andrea Barisani wrote:

On Saturday, March 5, 2016 at 8:02:22 PM UTC+1, pielgrzym wrote:

Hi,

I'm trying to fry my own version of Interlock with buildroot. Unfortunately the build fails during busybox compilation:

  CC      applets/applets.o

In file included from include/busybox.h:8:0,

                 from applets/applets.c:9:

include/libbb.h:279:7: error: size of array ‘BUG_off_t_size_is_misdetected’ is negative

  char BUG_off_t_size_is_misdetected[sizeof(off_t) == sizeof(uoff_t) ? 1 : -1];

       ^

scripts/Makefile.build:197: polecenia dla obiektu 'applets/applets.o' nie powiodły się

I'm running Debian Jessie. Tried explicitly passing CONFIG_LFS=n but no luck - build still fails :(

How can I fix this?

Hello,

I assume that you want to build the whole embedded INTERLOCK distribution (if you require just the INTERLOCK app you can just compile the application directly from its repository).

Yes, I want to bake some additional packages into zImage. I assume there is no way to change interlock binary without running full buildroot since the root filesystem is embedded in zImage?

 

I managed to reproduce the issue you are reporting on Debian stable (in doing so I had to tweak our conf a little as it was triggering some errors, it has been improved and just committed). These issues pop up from time to time as our instructions tell to use the git HEAD branch for buildroot, however as you prove this results too experimental in certain branches and prone to introduce build errors.

Interestingly enough it seems that CONFIG_LFS is always overridden to "=y" despite the fact that our busybox.config does disable it. I will investigate this further to address it.

In the meantime I recommend that you test with a buildroot branch that we verified, I just noted this in our related README file:

git clone git://git.buildroot.net/buildroot
# NOTE: you are welcome to try the current branch and report any issues that
# you may encounter, for the last tested branch checkout the following one:
# git checkout cf28e23e317fc449b280fcc299f8d6fd8c0506c5

If you would be so kind to update your usbarmory repository and start from scratch you could also test the bump to kernel 4.4.3 which I've also introduced in the commit.

I completely missed this part of README. Now it worked flawlessly - everything builds and works perfectly now :) Thanks!!

 

Thanks!

 

-- 

Thanks, P.

[pielgrzym]

On Sunday, March 6, 2016 at 11:47:05 PM UTC+1, Andrea Barisani wrote:

On Sunday, March 6, 2016 at 10:28:02 PM UTC+1, Andrea Barisani wrote:

On Saturday, March 5, 2016 at 8:02:22 PM UTC+1, pielgrzym wrote:

Hi,

I'm trying to fry my own version of Interlock with buildroot. Unfortunately the build fails during busybox compilation:

  CC      applets/applets.o

In file included from include/busybox.h:8:0,

                 from applets/applets.c:9:

include/libbb.h:279:7: error: size of array ‘BUG_off_t_size_is_misdetected’ is negative

  char BUG_off_t_size_is_misdetected[sizeof(off_t) == sizeof(uoff_t) ? 1 : -1];

       ^

scripts/Makefile.build:197: polecenia dla obiektu 'applets/applets.o' nie powiodły się

I'm running Debian Jessie. Tried explicitly passing CONFIG_LFS=n but no luck - build still fails :(

How can I fix this?

Hello,

I assume that you want to build the whole embedded INTERLOCK distribution (if you require just the INTERLOCK app you can just compile the application directly from its repository).

I managed to reproduce the issue you are reporting on Debian stable (in doing so I had to tweak our conf a little as it was triggering some errors, it has been improved and just committed). These issues pop up from time to time as our instructions tell to use the git HEAD branch for buildroot, however as you prove this results too experimental in certain branches and prone to introduce build errors.

Interestingly enough it seems that CONFIG_LFS is always overridden to "=y" despite the fact that our busybox.config does disable it. I will investigate this further to address it.

Sorry, it's actually the other way around.

On the latest buildroot HEAD, with CONFIG_LFS=y the issue is solved, the problem is in fact that our configuration unsets CONFIG_LFS.

I will re-test this tomorrow to confirm it and commit a working configuration.

This is even better - I'll test this tomorrow as soon as I get back from work :)

[Andrea Barisani]

On 6 Mar 2016 11:52 p.m., "'pielgrzym' via USB armory" <usba...@googlegroups.com> wrote:
>
> Hi :)
>
>
> On Sunday, March 6, 2016 at 10:28:02 PM UTC+1, Andrea Barisani wrote:
>>
>> On Saturday, March 5, 2016 at 8:02:22 PM UTC+1, pielgrzym wrote:
>>>
>>> Hi,
>>>
>>> I'm trying to fry my own version of Interlock with buildroot. Unfortunately the build fails during busybox compilation:
>>>
>>>   CC      applets/applets.o
>>> In file included from include/busybox.h:8:0,
>>>                  from applets/applets.c:9:
>>> include/libbb.h:279:7: error: size of array ‘BUG_off_t_size_is_misdetected’ is negative
>>>   char BUG_off_t_size_is_misdetected[sizeof(off_t) == sizeof(uoff_t) ? 1 : -1];
>>>        ^
>>> scripts/Makefile.build:197: polecenia dla obiektu 'applets/applets.o' nie powiodły się
>>>
>>> I'm running Debian Jessie. Tried explicitly passing CONFIG_LFS=n but no luck - build still fails :(
>>>
>>> How can I fix this?
>>>
>>
>> Hello,
>>
>> I assume that you want to build the whole embedded INTERLOCK distribution (if you require just the INTERLOCK app you can just compile the application directly from its repository).
>
>
> Yes, I want to bake some additional packages into zImage. I assume there is no way to change interlock binary without running full buildroot since the root filesystem is embedded in zImage?
>  

Correct, the only way is to rebuild the zImage. This is a feature as it means that with verified boot the whole rootfs + app is signed.

>>
>>
>> I managed to reproduce the issue you are reporting on Debian stable (in doing so I had to tweak our conf a little as it was triggering some errors, it has been improved and just committed). These issues pop up from time to time as our instructions tell to use the git HEAD branch for buildroot, however as you prove this results too experimental in certain branches and prone to introduce build errors.
>>
>> Interestingly enough it seems that CONFIG_LFS is always overridden to "=y" despite the fact that our busybox.config does disable it. I will investigate this further to address it.
>>
>> In the meantime I recommend that you test with a buildroot branch that we verified, I just noted this in our related README file:
>>
>> git clone git://git.buildroot.net/buildroot
>> # NOTE: you are welcome to try the current branch and report any issues that
>> # you may encounter, for the last tested branch checkout the following one:
>> # git checkout cf28e23e317fc449b280fcc299f8d6fd8c0506c5
>>
>>
>> If you would be so kind to update your usbarmory repository and start from scratch you could also test the bump to kernel 4.4.3 which I've also introduced in the commit.
>
>
> I completely missed this part of README. Now it worked flawlessly - everything builds and works perfectly now :) Thanks!!
>  

That's because I added it yesterday after debugging your issue ;)

>>
>>
>> Thanks!
>>
>>  
>>>
>>> -- 
>>> Thanks, P.
>
> --
> You received this message because you are subscribed to the Google Groups "USB armory" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to usbarmory+...@googlegroups.com.
> To post to this group, send email to usba...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/usbarmory/a36ca3d0-eda7-4c97-ada4-29ee5b5ce383%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

[Andrea Barisani]

On Sunday, March 6, 2016 at 11:54:15 PM UTC+1, pielgrzym wrote:

On Sunday, March 6, 2016 at 11:47:05 PM UTC+1, Andrea Barisani wrote:

On Sunday, March 6, 2016 at 10:28:02 PM UTC+1, Andrea Barisani wrote:

On Saturday, March 5, 2016 at 8:02:22 PM UTC+1, pielgrzym wrote:

Hi,

I'm trying to fry my own version of Interlock with buildroot. Unfortunately the build fails during busybox compilation:

  CC      applets/applets.o

In file included from include/busybox.h:8:0,

                 from applets/applets.c:9:

include/libbb.h:279:7: error: size of array ‘BUG_off_t_size_is_misdetected’ is negative

  char BUG_off_t_size_is_misdetected[sizeof(off_t) == sizeof(uoff_t) ? 1 : -1];

       ^

scripts/Makefile.build:197: polecenia dla obiektu 'applets/applets.o' nie powiodły się

I'm running Debian Jessie. Tried explicitly passing CONFIG_LFS=n but no luck - build still fails :(

How can I fix this?

Hello,

I assume that you want to build the whole embedded INTERLOCK distribution (if you require just the INTERLOCK app you can just compile the application directly from its repository).

I managed to reproduce the issue you are reporting on Debian stable (in doing so I had to tweak our conf a little as it was triggering some errors, it has been improved and just committed). These issues pop up from time to time as our instructions tell to use the git HEAD branch for buildroot, however as you prove this results too experimental in certain branches and prone to introduce build errors.

Interestingly enough it seems that CONFIG_LFS is always overridden to "=y" despite the fact that our busybox.config does disable it. I will investigate this further to address it.

Sorry, it's actually the other way around.

On the latest buildroot HEAD, with CONFIG_LFS=y the issue is solved, the problem is in fact that our configuration unsets CONFIG_LFS.

I will re-test this tomorrow to confirm it and commit a working configuration.

This is even better - I'll test this tomorrow as soon as I get back from work :)

Ok, I fully tested this and it works fine even with latest HEAD.

I just committed in our repository the updated busybox config and README file which reflects a more updated checkout (which it's optional for you to align to or not).

Cheers!

[pielgrzym]

Hi,

I can build the zImage with my own Interlock build and it works perfectly! When I enable tor package in buildroot the build goes fine, but usbarmory does not boot. When I attached serial console to armory I can see it hangs at 'Loading kernel'. I tried setting 'DEBUG_LL' in kernel-4.4.config, but I don't get any helpful output this way. Any idea where did I fail this time? ;) or how can I get some better debug? :)

Thanks!

Of course when I remove tor package and make clean all, the image works flawlessly again :) 

[Andrea Barisani]

On Monday, March 7, 2016 at 11:59:37 PM UTC+1, pielgrzym wrote:

Hi,

I can build the zImage with my own Interlock build and it works perfectly! When I enable tor package in buildroot the build goes fine, but usbarmory does not boot. When I attached serial console to armory I can see it hangs at 'Loading kernel'. I tried setting 'DEBUG_LL' in kernel-4.4.config, but I don't get any helpful output this way. Any idea where did I fail this time? ;) or how can I get some better debug? :)

Thanks!

Of course when I remove tor package and make clean all, the image works flawlessly again :) 

I think this relates to the size of the resulting kernel.

By adding packages you are probably hitting the configured uboot limit for the kernel size, which if exceeded results in the hanging that you see.

We do tune the maximum allowed size but evidently is not enough for your needs, you can see our change in the following file:

https://github.com/inversepath/usbarmory/blob/master/software/buildroot/u-boot-increase_bootm_len.patch

You might want to tweak that and retry.

Cheers

[pielgrzym]

Hi :)

On Tuesday, March 8, 2016 at 10:06:39 AM UTC+1, Andrea Barisani wrote:

I think this relates to the size of the resulting kernel.

By adding packages you are probably hitting the configured uboot limit for the kernel size, which if exceeded results in the hanging that you see.

We do tune the maximum allowed size but evidently is not enough for your needs, you can see our change in the following file:

https://github.com/inversepath/usbarmory/blob/master/software/buildroot/u-boot-increase_bootm_len.patch

You might want to tweak that and retry.

I tried changing the CONFIG_SYS_BOOTM_LEN to 20, 32 and 64 megabytes, unfortunately the hang persists. I think that u-boot would pop a message that kernel is too big (http://git.denx.de/?p=u-boot.git;a=blob;f=common/bootm.c;h=df27089965c927bc625ed49c6be1ee03477ff7e5;hb=HEAD#l311). Shall I tweak the fdt_addr_r accordingly (I'm not sure how ;)).

I tried adding 'earlyprintk' to bootargs_default in u-boot as well as building with CONFIG_DEBUG_LL, so I assume that kernel is not loaded at all and all I see is u-boot message, right?

[Andrea Barisani]

On Tue, Mar 8, 2016 at 9:00 PM, 'pielgrzym' via USB armory <usba...@googlegroups.com> wrote:

Hi :)

On Tuesday, March 8, 2016 at 10:06:39 AM UTC+1, Andrea Barisani wrote:

I think this relates to the size of the resulting kernel.

By adding packages you are probably hitting the configured uboot limit for the kernel size, which if exceeded results in the hanging that you see.

We do tune the maximum allowed size but evidently is not enough for your needs, you can see our change in the following file:

https://github.com/inversepath/usbarmory/blob/master/software/buildroot/u-boot-increase_bootm_len.patch

You might want to tweak that and retry.

I tried changing the CONFIG_SYS_BOOTM_LEN to 20, 32 and 64 megabytes, unfortunately the hang persists. I think that u-boot would pop a message that kernel is too big (http://git.denx.de/?p=u-boot.git;a=blob;f=common/bootm.c;h=df27089965c927bc625ed49c6be1ee03477ff7e5;hb=HEAD#l311). Shall I tweak the fdt_addr_r accordingly (I'm not sure how ;)).

I tried adding 'earlyprintk' to bootargs_default in u-boot as well as building with CONFIG_DEBUG_LL, so I assume that kernel is not loaded at all and all I see is u-boot message, right?

You have to change both CONFIG_SYS_BOOTM_LEN and bump fdt_addr_r accordingly. U-boot might not pop a message if pointers are incorrect,

If you don't manage to find the right setting you can maybe send me the changes that you are doing to the buildroot environments to add Tor and then I can reproduce your error and fix accordingly.

Thanks!

 

--

You received this message because you are subscribed to the Google Groups "USB armory" group.
To unsubscribe from this group and stop receiving emails from it, send an email to usbarmory+...@googlegroups.com.
To post to this group, send email to usba...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/usbarmory/a1c5b666-1d36-49d0-869a-b8e2fe9dcc9e%40googlegroups.com.

[pielgrzym]

Hi,

Managed to get it working - fdt_addr_r was the fault (as you pointed out). Thankfully the u-boot echoes this address back to serial just before attempting to load the kernel. This way I found out that somehow my rebuilt u-boot did not change this address at all (despite i was dd'ing it to bootsetcor uppon every rebuild). Fortunately u-boot has a convenient setenv and saveenv commands that managed to fix the address and everything boots up flawlessly :)

I have built an image that has working tor client and electrum btc wallet - now I'm off to add some electrum control and tor control functionality to interlock. The idea is to have a fully functional offline, tor-backed, lightweight wallet on usbarmory :) This is the second stage - earlier I managed to get electrum and tor working in chrooted debian inside luks container, not it's time to package this into interlock ;) thankfully electrum already talks json, so it should be pretty simple :)

The only thing I didn't figure out is how to communicate with tor client, but this shouldn't be hard :)

Thanks for help!

[Andrea Barisani]

On Wednesday, March 9, 2016 at 10:32:10 PM UTC+1, pielgrzym wrote:

Hi,

Managed to get it working - fdt_addr_r was the fault (as you pointed out). Thankfully the u-boot echoes this address back to serial just before attempting to load the kernel. This way I found out that somehow my rebuilt u-boot did not change this address at all (despite i was dd'ing it to bootsetcor uppon every rebuild). Fortunately u-boot has a convenient setenv and saveenv commands that managed to fix the address and everything boots up flawlessly :)

Glad to hear that you sorted it out :)

 

I have built an image that has working tor client and electrum btc wallet - now I'm off to add some electrum control and tor control functionality to interlock. The idea is to have a fully functional offline, tor-backed, lightweight wallet on usbarmory :) This is the second stage - earlier I managed to get electrum and tor working in chrooted debian inside luks container, not it's time to package this into interlock ;) thankfully electrum already talks json, so it should be pretty simple :)

The only thing I didn't figure out is how to communicate with tor client, but this shouldn't be hard :)

Thanks for help!

Nice, just keep in mind that the larger the rootfs is the less RAM you will have available. I might expand the buildroot configurations that we provide and have one with Tor, I think lots of people would find that convenient.

Cheers