Gustavoz whipped up a patch against busybox-1.4.2 and I rolled a source tarball and patched the ebuild to make it easier to change the busybox version. The ebuild patch is attached.
Created attachment 120006 [details, diff] patch to genkernel-3.4.8.ebuild
Before this goes into a release, we probably need new default busybox configs.
what the deuce is that stuff ... are we still hacking the crap out of busybox ? openvt: what is this ? this cant be Gentoo specific and i dont see any mention of it upstream mdev: what are you trying to do ? add support for loading firmware ?
I have no idea about the openvt stuff, but yes, the mdev stuff is for firmware loading. It's required to boot some sparc machines with a specific fc controller with >=2.6.18 due to the firmware being moved out of the kernel.
I Just forward-ported the old busybox apps from plasmaroo, didn't look into usage-specifics. As Andrew said the mdev+firmware stuff is needed if sparc wants a newer kernel (>=2.6.18) for some machine models. It could also come handy for other boot scenarios that require firmware (qla2xxx is the culprit in sparc and they're used for SAN on x86/amd64 too).
why does it need to be in C ? cant it be done by an external shell script ?
The firmware is requested by the driver via a hotplug event and setting the requested firmware file in ENV. It seems busybox-1.4.2's mdev doesn't do anything besides creating the device "if (!strcmp(action, "add")) make_device(temp,0);" so busybox should at least be patched too to call a helper script to do this.
i see what you mean ... i'll look at getting that mdev fixed upstream so what's the deal with openvt ? if no one knows, then i say just drop it
I'll grep genkernel's initramfs/initrd scripts to check it out, but yeah it may just be a deprecated thing from the past.
this should do it i think ... plus it's much smaller/cleaner ;) http://busybox.net/cgi-bin/viewcvs.cgi?rev=18810&view=rev i just dont have any actual devices that need firmware so my testing was limited: env ACTION="add" DEVPATH="/block/nbd10" FIRMWARE="foo" ./busybox mdev
the mini mdstart applet is not needed anymore either ... busybox already has "raidautorun"
as for getdvhoff, you can implement it with shell: echo $(( $(hexdump -n 4 -s $((316 + 12 * $2)) -e '"%i"' $1) * 512)) you'll need to enable the hexdump applet in busybox, but i think that's fine
so i think vanilla busybox-1.7.0 should meet all of genkernel's demands ? is there anything else ?
Mike, can you also check if the new busybox would resolve bug #178756 also?
(In reply to comment #12) > as for getdvhoff, you can implement it with shell: > > echo $(( $(hexdump -n 4 -s $((316 + 12 * $2)) -e '"%i"' $1) * 512)) > > you'll need to enable the hexdump applet in busybox, but i think that's fine Only problem with this, is it doesn't return a proper value on little-endian systems for some reason. Now it's extremely rare to ever need to be run on a LE system, but there have been occasional cases where I need to manually fetch the offset value (usually for debugging purposes). It's not a blocker by any means, but I thought I'd point this out. I'll likely keep sys-boot/getdvhoff around for these purposes (And maybe mod it to no longer link against any libc or something).
as i mentioned on irc, the reason you cant do that on a LE machine is that the filesystem is BE and you're extracting a 32bit BE quantity from the disk this is never an issue in the target system as getdvhoff is only used on a BE machine to access a BE disk
What/when is the next version of busybox coming out? You mentioned 1.7.0, but the busybox.net frontpage mentions something about a forthcoming 1.6.1. Will this stuff be in it?
no idea on schedule and no, my work has only been added to trunk, not 1.6.x branch so if you need these things right now, i'd just merge what you've got and move to 1.7.0 when it does come out
(In reply to comment #16) > as i mentioned on irc, the reason you cant do that on a LE machine is that the > filesystem is BE and you're extracting a 32bit BE quantity from the disk > > this is never an issue in the target system as getdvhoff is only used on a BE > machine to access a BE disk Hmm, so even the resulting ISO file we burn to CD is BE? Only the squashfs image itself should be BE; I thought the rest would be endian-agnostic, for the most part. Oh well.
it's got to be some endian ... i imagine if you read the ISO9660 specs, they state the expected endianness of quantities
T(In reply to comment #20) > it's got to be some endian ... i imagine if you read the ISO9660 specs, they > state the expected endianness of quantities Actually, the resultant output image isn't an ISO9660 image at all. It's a disk image with an SGI Disklabel, the DVH partition and whole disk partition, plus the one data partition (w/ squashfs), and a few kernels + bootloader stuffed into the volume header. You can even open it in fdisk or extract kernels/bootloader/config from the volume header w/ dvhtool (just can't write them back).
fdisk knows how to handle SGI disk labels and thus knows to detect the endianness which is why it works on your LE host
How about that new busybox? Is it ready?
We still need a new arch-generic busybox config for the new version. Gustavoz? :P
Created attachment 128892 [details] Busybox config for genkernel This should be it, loosely based on the previous busybox config.
Adding notes for myself so I won't forget what needs to be done (again)... <agaffney> wolf31o2: we just need to get http://dev.gentoo.org/~agaffney/misc/busybox-1.4.2+gentoo.tar.bz2 on the mirrors and update the ebuild to change the busybox version in genkernel.conf like it does for all other utils (it's currently done differently for some reason) <agaffney> and then add that generic busybox config in the bug to all the arch dirs under genkernel <agaffney> I've also got a generic nb-busybox.cf for 1.4.2+gentoo to go into catalyst
Also, enable CONFIG_INSMOD before I commit the updated configs...
You'll need to make another change in the bb config. To get the initramfs to start up mdraid devices (assuming this even works properly now), you'll either have to enable CONFIG_RAIDAUTORUN and then s/mdstart/raidautorun/ in generic/initrd.scripts or just enable CONFIG_MDSTART, instead. The former is probably better, since raidautorun is in vanilla busybox, and mdstart is just a holdover from when we were patching it into older busyboxes that didn't have raid autorun. We'll want to use raidautorun when we switch to using an even newer busybox (1.7.0 will probably be the next, since it should have the mdev firmware loading). I just took a look, and it looks like busybox-1.7.1 is out now, and it has everything we need in vanilla busybox. However, we'd still have to replace the mips-specific applet with a shell script version in the initramfs. Should we do 1.4.2+gentoo now and do 1.7.1 (or higher) in 3.5? Should we even bother with this busybox version bump for now?
Unless 1.4.2+gentoo resolves some issue that we would want resolved for 2007.1, I don't see a point in the upgrade. Of course, it also isn't exactly hard, so it won't hurt to do the upgrade now.
Busybox has now been upgraded to 1.7.4 in genkernel in SVN.
OK. This is resolved in genkernel 3.4.10, which is now in the tree and stable.
