busybox build giving problems

[protectivedad]

I built just the kernel, mtdutils and busybox (as static) for use as an initramfs that switch roots to my network rootfs. I did this no problem using the RidgeRun tools the leapster and busybox source 1.20.2 from busybox.net.

I was porting this over to use OpenLF (great work by the way). I find that at the point that the init script, using my init ram busybox, hands off to the network share busybox as the "real" init it resets. Doesn't even get to the inittab.

The net busybox is the same compiled version as the initram busybox retrieved from the output/target directory. Exact same. And it was compiled statically. In fact the network share is a copy of the build/target.

After some digging I found the file
output/build/busybox-1.20.2/busybox
is not the same as
output/target/bin/busybox

If I use the output/build/busybox-1.20.2/busybox on my netshare the system boot correctly, replace with output/target/bin/busybox it busts. Very reproducible.

Out of OpenLF-Buildroot the make install goes through strips crypt and produces:
busybox_unstripped (large)
busybox (smaller) = busybox (installed)

In OpenLF-Buildroot make busybox-rebuild goes through strips crypt (well says it does anyway) and produces:
busybox_unstripped (large) = busybox
busybox (installed smaller)

Thanks.

[jrspruitt]

Sounds like your making some good progress, nice to hear. As for
buildroot/output/target/ It shouldn't be used, its not your actual rootfs.
There is still some processing that is required of the files. What I
usually do, is in the main menuconfig, where you set the image files it
creates for output, you can set it to create a tar archive of the rootfs, I
then extract that, as it is the finalized rootfs, and will have all the
permissions, and from what you've found final processing of files.
-Jason

On Sun, Jan 12, 2014 at 5:25 PM, protectivedad notifications@github.comwrote:

I built just the kernel, mtdutils and busybox (as static) for use as an
initramfs that switch roots to my network rootfs. I did this no problem
using the RidgeRun tools the leapster and busybox source 1.20.2 from
busybox.net.

I was porting this over to use OpenLF (great work by the way). I find that
at the point that the init script, using my init ram busybox, hands off to
the network share busybox as the "real" init it resets. Doesn't even get to
the inittab.

The net busybox is the same compiled version as the initram busybox
retrieved from the output/target directory. Exact same. And it was compiled
statically. In fact the network share is a copy of the build/target.

After some digging I found the file
output/build/busybox-1.20.2/busybox
is not the same as
output/target/bin/busybox

If I use the output/build/busybox-1.20.2/busybox on my netshare the system
boot correctly, replace with output/target/bin/busybox it busts. Very
reproducible.

Out of OpenLF-Buildroot the make install goes through strips crypt and
produces:
busybox_unstripped (large)
busybox (smaller) = busybox (installed)

In OpenLF-Buildroot make busybox-rebuild goes through strips crypt (well
says it does anyway) and produces:
busybox_unstripped (large) = busybox
busybox (installed smaller)

Thanks.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2
.

[protectivedad]

Nope, exact same problem. The busybox programs in the /output/target, output/image/rootfs.tar are the same and all are broken in some way. If I replace it with the one in the build/busybox directory it works. Or if I recompile outside of the OpenLF-Buildroot env.

[protectivedad]

Just to clarify, I used the rootfs.tar file and will from now on (thanks), but with that change the busybox is still borken. I also did a make clean before my last try. After I build everything if I set my cross compile environment to use the RidgeRun and go into the output/build/busybox-1.20.1 and make install again it will recompile and the binary will work.

[jrspruitt]

Weird, no idea what would cause the issue, but I'm not well versed in this
side of things. Would be interested to know, linking, stripping, toolchain
setting, or what?
-Jason

On Sun, Jan 12, 2014 at 6:55 PM, protectivedad notifications@github.comwrote:

Just to clarify, I used the rootfs.tar file and will from now on (thanks),
but with that change the busybox is still borken. I also did a make clean
before my last try. After I build everything if I set my cross compile
environment to use the RidgeRun and go into the output/build/busybox-1.20.1
and make install again it will recompile and the binary will work.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-32142767
.

[protectivedad]

I ported the OpenLF configs over to the buildroot-2013.11. It updates fairly simply adds the newer busybox, etc. I still have the same problem so I open a bug with buildroot.

It might be useful to others to update the OpenLF-Buildroot. Though I don't know how much. Let me know if I can do anything to help update it.

[jrspruitt]

I actually started an update, using 2013.08 which was to include the
LeapPad2/GS hardware, this was just prior to the release of 2013.11, but
never finished it, as other things came up. I'm hoping to get back to it,
as OpenLFConnect needs some tending to also. But for now that is probably a
ways off.

Feel free to create your own OpenLF Buildroot, or call it what ever you
want, we can post a link on the wiki to it as the updated version. An
update would be nice to include the newer Buildroot features, and of course
any bug fixes. I know what you are trying to do, has been a talked about
feature by quite a few people, so it'll be greatly appreciated. Thanks.
-Jason

On Mon, Jan 13, 2014 at 1:34 PM, protectivedad notifications@github.comwrote:

I ported the OpenLF configs over to the buildroot-2013.11. It updates
fairly simply adds the newer busybox, etc. I still have the same problem so
I open a bug with buildroot.

It might be useful to others to update the OpenLF-Buildroot. Though I
don't know how much. Let me know if I can do anything to help update it.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-32213879
.

[protectivedad]

So I thought I was rolling along until I found that I lost the ability to
erase the mtd devices. I created a toolchain with the newest buildroot and
used it to compile the kernel and busybox in the old buildroot. Ran it and
there is no problem. I bring the configuration files over to the new build
root using the same toolchain everything goes fine until I try to
flash_eraseall /dev/mtd3 and I get a:
flash_eraseall: can't open '/dev/mtd3': No such device or address

The device exists everything seems the same. Any ideas? Have you seen
anything similar?

Arrggg!

On 13 January 2014 18:09, Jason Pruitt notifications@github.com wrote:

I actually started an update, using 2013.08 which was to include the
LeapPad2/GS hardware, this was just prior to the release of 2013.11, but
never finished it, as other things came up. I'm hoping to get back to it,
as OpenLFConnect needs some tending to also. But for now that is probably
a
ways off.

Feel free to create your own OpenLF Buildroot, or call it what ever you
want, we can post a link on the wiki to it as the updated version. An
update would be nice to include the newer Buildroot features, and of
course
any bug fixes. I know what you are trying to do, has been a talked about
feature by quite a few people, so it'll be greatly appreciated. Thanks.
-Jason

On Mon, Jan 13, 2014 at 1:34 PM, protectivedad notifications@github.comwrote:

I ported the OpenLF configs over to the buildroot-2013.11. It updates
fairly simply adds the newer busybox, etc. I still have the same problem
so
I open a bug with buildroot.

It might be useful to others to update the OpenLF-Buildroot. Though I
don't know how much. Let me know if I can do anything to help update it.

—
Reply to this email directly or view it on GitHub<
https://github.com/jrspruitt/OpenLF-Buildroot/issues/2#issuecomment-32213879>

.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-32217131
.

[jrspruitt]

Can't say I've ever run into this particular issue, are you trying this
using surgeon? If not it could be blocked cause you're trying to erase the
system in use. On the LF systems, they have two mtd devices for every
actual one, like a set of symbolic ones, that is used during flashing with
surgeon. I've wondered about why, but never investigated it, perhaps
something to do with this? Otherwise, unless perhaps its mounted read only,
not sure why there would be issues with it.
-Jason

On Tue, Jan 14, 2014 at 4:11 PM, protectivedad notifications@github.comwrote:

So I thought I was rolling along until I found that I lost the ability to
erase the mtd devices. I created a toolchain with the newest buildroot and
used it to compile the kernel and busybox in the old buildroot. Ran it and
there is no problem. I bring the configuration files over to the new build
root using the same toolchain everything goes fine until I try to
flash_eraseall /dev/mtd3 and I get a:
flash_eraseall: can't open '/dev/mtd3': No such device or address

The device exists everything seems the same. Any ideas? Have you seen
anything similar?

Arrggg!

On 13 January 2014 18:09, Jason Pruitt notifications@github.com wrote:

I actually started an update, using 2013.08 which was to include the
LeapPad2/GS hardware, this was just prior to the release of 2013.11, but
never finished it, as other things came up. I'm hoping to get back to
it,
as OpenLFConnect needs some tending to also. But for now that is
probably
a
ways off.

Feel free to create your own OpenLF Buildroot, or call it what ever you
want, we can post a link on the wiki to it as the updated version. An
update would be nice to include the newer Buildroot features, and of
course
any bug fixes. I know what you are trying to do, has been a talked about
feature by quite a few people, so it'll be greatly appreciated. Thanks.
-Jason

On Mon, Jan 13, 2014 at 1:34 PM, protectivedad notifications@github.comwrote:

I ported the OpenLF configs over to the buildroot-2013.11. It updates
fairly simply adds the newer busybox, etc. I still have the same
problem
so
I open a bug with buildroot.

It might be useful to others to update the OpenLF-Buildroot. Though I
don't know how much. Let me know if I can do anything to help update
it.

—
Reply to this email directly or view it on GitHub<

https://github.com/jrspruitt/OpenLF-Buildroot/issues/2#issuecomment-32213879>

.

—
Reply to this email directly or view it on GitHub<
https://github.com/jrspruitt/OpenLF-Buildroot/issues/2#issuecomment-32217131>

.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-32322338
.

[protectivedad]

Well, I've setup things using the 2013.11 buildroot. I ported over your
files and used some of the newer features in the buildroot such as directly
overlays, patch directory, etc. I structured it by building a toolchain in
buildroot and then moving it out and pointing buildroot to it as an
external toolchain. This way saving from recompiling the toolchain all the
time. I wish I had found this solution a lot earlier.

I made three defconfigs
openlf-toolchain-defconfig - builds the toolchain
openlf-didj-initramfs-defconfig - creates an initramfs kernel that is
written to the kernel partition, but can be triggered to produce a telnet
session, boot netork rootfs or use the internal rootfs, and will act as an
emergency surgeon lite
openlf-didj-full-defconfig - all the packages you had in yours and a
starting point for playing around.

I looked over you blog posts (too late :) ) great work. My porting is a
little pedestrian in comparison.

I did find answers to some problems that might be usefull (newest busybox
caused my flash problems), the mtd partitions in your openlf-buildroot
won't work with the emerald bootloader, the kernel has the wrong offset. I
don't want to add to the confusion (there is a lot of info and what is new
and what is 3 years old is hard to find). I'd thing my information would be
useful to someone who has an old Didj and wants to turn it into a general
linux box to play with (no hardware mods, or breakout cards required).

Let me know if you think it'd be useful in a wiki? Do you know if anyone
has gotten the 2.6.20 kernel to boot from emerald bootloader, everything
seems to be lightning to boot 2.6.20 or 2.6.31 and only emerald to boot
2.6.31?

Thanks for all the help,
Anthony.

On 14 January 2014 21:26, Jason Pruitt notifications@github.com wrote:

Can't say I've ever run into this particular issue, are you trying this
using surgeon? If not it could be blocked cause you're trying to erase the
system in use. On the LF systems, they have two mtd devices for every
actual one, like a set of symbolic ones, that is used during flashing with
surgeon. I've wondered about why, but never investigated it, perhaps
something to do with this? Otherwise, unless perhaps its mounted read
only,
not sure why there would be issues with it.
-Jason

On Tue, Jan 14, 2014 at 4:11 PM, protectivedad notifications@github.comwrote:

So I thought I was rolling along until I found that I lost the ability
to
erase the mtd devices. I created a toolchain with the newest buildroot
and
used it to compile the kernel and busybox in the old buildroot. Ran it
and
there is no problem. I bring the configuration files over to the new
build
root using the same toolchain everything goes fine until I try to
flash_eraseall /dev/mtd3 and I get a:
flash_eraseall: can't open '/dev/mtd3': No such device or address

The device exists everything seems the same. Any ideas? Have you seen
anything similar?

Arrggg!

On 13 January 2014 18:09, Jason Pruitt notifications@github.com
wrote:

I actually started an update, using 2013.08 which was to include the
LeapPad2/GS hardware, this was just prior to the release of 2013.11,
but
never finished it, as other things came up. I'm hoping to get back to
it,
as OpenLFConnect needs some tending to also. But for now that is
probably
a
ways off.

Feel free to create your own OpenLF Buildroot, or call it what ever
you
want, we can post a link on the wiki to it as the updated version. An
update would be nice to include the newer Buildroot features, and of
course
any bug fixes. I know what you are trying to do, has been a talked
about
feature by quite a few people, so it'll be greatly appreciated.
Thanks.
-Jason

On Mon, Jan 13, 2014 at 1:34 PM, protectivedad <
notifications@github.com>wrote:

I ported the OpenLF configs over to the buildroot-2013.11. It
updates
fairly simply adds the newer busybox, etc. I still have the same
problem
so
I open a bug with buildroot.

It might be useful to others to update the OpenLF-Buildroot. Though
I
don't know how much. Let me know if I can do anything to help update
it.

—
Reply to this email directly or view it on GitHub<

https://github.com/jrspruitt/OpenLF-Buildroot/issues/2#issuecomment-32213879>

.

—
Reply to this email directly or view it on GitHub<

https://github.com/jrspruitt/OpenLF-Buildroot/issues/2#issuecomment-32217131>

.

—
Reply to this email directly or view it on GitHub<
https://github.com/jrspruitt/OpenLF-Buildroot/issues/2#issuecomment-32322338>

.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-32326636
.

[jrspruitt]

Please by all means put your work up on the elinux wiki, that would be
great. Feel free to mention what you're up to on the OpenLF G+ too, it
could use some updates.

I don't recall anyone booting 2.6.20 with emerald boot, but I can't think
of a reason it wouldn't work, as long as the kernel is found where
expected. Sorry about the mtd partitions, I thought I had fixed that, as
initially I had set them up to be different than the standard Explorer
layout, then changed them back, must have missed something.

The external toolchain is the way to go, especially during the development
phase, once you got things sorted out, and are just adding stuff, or making
small tweaks, its not as important. That is one of my major complaints with
buildroot, you can install packages, but you can't remove with out
rebuilding everything.

Good to hear things are working out, thanks for keeping me up to date,
-Jason

On Fri, Jan 17, 2014 at 5:20 PM, protectivedad notifications@github.comwrote:

Well, I've setup things using the 2013.11 buildroot. I ported over your
files and used some of the newer features in the buildroot such as
directly
overlays, patch directory, etc. I structured it by building a toolchain in
buildroot and then moving it out and pointing buildroot to it as an
external toolchain. This way saving from recompiling the toolchain all the
time. I wish I had found this solution a lot earlier.

I made three defconfigs
openlf-toolchain-defconfig - builds the toolchain
openlf-didj-initramfs-defconfig - creates an initramfs kernel that is
written to the kernel partition, but can be triggered to produce a telnet
session, boot netork rootfs or use the internal rootfs, and will act as an
emergency surgeon lite
openlf-didj-full-defconfig - all the packages you had in yours and a
starting point for playing around.

I looked over you blog posts (too late :) ) great work. My porting is a
little pedestrian in comparison.

I did find answers to some problems that might be usefull (newest busybox
caused my flash problems), the mtd partitions in your openlf-buildroot
won't work with the emerald bootloader, the kernel has the wrong offset. I
don't want to add to the confusion (there is a lot of info and what is new
and what is 3 years old is hard to find). I'd thing my information would
be
useful to someone who has an old Didj and wants to turn it into a general
linux box to play with (no hardware mods, or breakout cards required).

Let me know if you think it'd be useful in a wiki? Do you know if anyone
has gotten the 2.6.20 kernel to boot from emerald bootloader, everything
seems to be lightning to boot 2.6.20 or 2.6.31 and only emerald to boot
2.6.31?

Thanks for all the help,
Anthony.

On 14 January 2014 21:26, Jason Pruitt notifications@github.com wrote:

Can't say I've ever run into this particular issue, are you trying this
using surgeon? If not it could be blocked cause you're trying to erase
the
system in use. On the LF systems, they have two mtd devices for every
actual one, like a set of symbolic ones, that is used during flashing
with
surgeon. I've wondered about why, but never investigated it, perhaps
something to do with this? Otherwise, unless perhaps its mounted read
only,
not sure why there would be issues with it.
-Jason

On Tue, Jan 14, 2014 at 4:11 PM, protectivedad notifications@github.comwrote:

So I thought I was rolling along until I found that I lost the ability
to
erase the mtd devices. I created a toolchain with the newest buildroot
and
used it to compile the kernel and busybox in the old buildroot. Ran it
and
there is no problem. I bring the configuration files over to the new
build
root using the same toolchain everything goes fine until I try to
flash_eraseall /dev/mtd3 and I get a:
flash_eraseall: can't open '/dev/mtd3': No such device or address

The device exists everything seems the same. Any ideas? Have you seen
anything similar?

Arrggg!

On 13 January 2014 18:09, Jason Pruitt notifications@github.com
wrote:

I actually started an update, using 2013.08 which was to include the
LeapPad2/GS hardware, this was just prior to the release of 2013.11,
but
never finished it, as other things came up. I'm hoping to get back
to
it,
as OpenLFConnect needs some tending to also. But for now that is
probably
a
ways off.

Feel free to create your own OpenLF Buildroot, or call it what ever
you
want, we can post a link on the wiki to it as the updated version.
An
update would be nice to include the newer Buildroot features, and of
course
any bug fixes. I know what you are trying to do, has been a talked
about
feature by quite a few people, so it'll be greatly appreciated.
Thanks.
-Jason

On Mon, Jan 13, 2014 at 1:34 PM, protectivedad <
notifications@github.com>wrote:

I ported the OpenLF configs over to the buildroot-2013.11. It
updates
fairly simply adds the newer busybox, etc. I still have the same
problem
so
I open a bug with buildroot.

It might be useful to others to update the OpenLF-Buildroot.
Though
I
don't know how much. Let me know if I can do anything to help
update
it.

—
Reply to this email directly or view it on GitHub<

https://github.com/jrspruitt/OpenLF-Buildroot/issues/2#issuecomment-32213879>

.

—
Reply to this email directly or view it on GitHub<

https://github.com/jrspruitt/OpenLF-Buildroot/issues/2#issuecomment-32217131>

.

—
Reply to this email directly or view it on GitHub<

https://github.com/jrspruitt/OpenLF-Buildroot/issues/2#issuecomment-32322338>

.

—
Reply to this email directly or view it on GitHub<
https://github.com/jrspruitt/OpenLF-Buildroot/issues/2#issuecomment-32326636>

.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-32670646
.