search

jrspruitt / OpenLF-Buildroot

Buildroot set up for making a Root FS for the Didj
GNU General Public License v2.0
3 stars 1 forks source link

busybox build giving problems #2

Open protectivedad opened 10 years ago

protectivedad commented 10 years ago

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 commented 10 years ago

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/jrspruitt/OpenLF-Buildroot/issues/2 .

protectivedad commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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/jrspruitt/OpenLF-Buildroot/issues/2#issuecomment-32142767 .

protectivedad commented 10 years ago

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 commented 10 years ago

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/jrspruitt/OpenLF-Buildroot/issues/2#issuecomment-32213879 .

protectivedad commented 10 years ago

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/jrspruitt/OpenLF-Buildroot/issues/2#issuecomment-32217131 .

jrspruitt commented 10 years ago

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/jrspruitt/OpenLF-Buildroot/issues/2#issuecomment-32322338 .

protectivedad commented 10 years ago

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/jrspruitt/OpenLF-Buildroot/issues/2#issuecomment-32326636 .

jrspruitt commented 10 years ago

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/jrspruitt/OpenLF-Buildroot/issues/2#issuecomment-32670646 .