genkernel uses busybox 1.7.4, which was released 23 November 2007 - as of the time of this bug report, that's almost 3 years ago. Plenty of bugs have been fixed, and (standalone) busybox in portage is up to date.
Created an updated ebuild in my overlay, updating the genkernel dependencies.
Created attachment 248723 [details]
Created attachment 248725 [details, diff]
diff from previous
*** Bug 310785 has been marked as a duplicate of this bug. ***
Created attachment 255835 [details, diff]
May be busybox patches must be reworked too?
Next trivially fixed suitable patches:
Also may be copied unchanged:
Others fixed upstream.
Created attachment 255837 [details, diff]
Created attachment 255839 [details, diff]
Created attachment 255875 [details, diff]
Changed default & neboot busybox configs. Mainly removed printing, daemons & other big stuff. Sorry, no mips...
Created attachment 256047 [details, diff]
This is better. Key changes:
1) standard modutils (vs. "small"), compatible with genkernel's /etc/modules, have "-a", /etc/modprobe.d, etc;
2) raidautorun. Using mdadm/mdstart (2 patches) may be obsoleted and after script changing to use raidautorun - removed (future?);
3) revised utils set in netboot.
Created attachment 256348 [details, diff]
This is something not about busybox, but about initial patch: e2fsprogs 1.41.12 needs another LDFLAGS settings, attached...
Created attachment 258432 [details, diff]
Fix: return lost shell math ("let" command)
Created attachment 258945 [details, diff]
This is uncritical patch, removing message "sh: bad number" on [ "" -eq '1' ] comparing with 1.17.4.
PS: Adding keyword "Inclusion" and "[patch] " prefix to better show this bug's nature in searches...
I have just added an ebuild sys-kernel/genkernel-99999 (five nines) which uses busybox 1.18.1 and the new experimental branch of genkernel. Please give it a spin and report back problems.
I have not looked at your patches in detail, yet. If you could help me pick the parts that are still relevant with 1.18.1, that would be appreciated. Thanks in advance.
Created attachment 259650 [details, diff]
This is cumulative patch, removing patches/busybox/1.7.4, adding similar 1.18.1 and changing default configs. defaults/busy-config produced even smaller binary then original (useful features vs. new big stuff like printing daemons).
PS You forget to add GPG versioning & tarball into ebuild.
I prefer not deleting the 1.7.4 files, so potential users keep the level of comfort. What approach/goals did you follow when updating the busybox config? When I understand that, review becomes easier.
Also, I'd like to discuss the approach to take on mdadm and mdstart with you: In bug #260344 and bug #282100 people propose other directions. What do you think?
Please contact me on <firstname.lastname@example.org.> on this matter.
(I don't mean to hide conversation from the bug, but rather move to a better medium. I offer addition to the genkernel mail alias to anyone interested, just drop me a mail.)
> PS You forget to add GPG versioning & tarball into ebuild.
Excellent catch. Fixed.
I have pushed the busybox patches ported by Denis to the experimental branch now:
(In reply to comment #17)
> I have pushed the busybox patches ported by Denis to the experimental branch
Heh, you not add most useful mdadm patch... mdstart (IMHO equal to raidautorun) don't start raid1 on my proxy server (may be I was not enough shamanic). Ok, I will use mdadm patch self...
Created attachment 262061 [details, diff]
Just in case (IMHO better to add then not to add).
(In reply to comment #19)
> Created an attachment (id=262061) [details]
> Just in case (IMHO better to add then not to add).
Have you noticed that genkernel 3.4.12 an later com with the "real" mdadm?
With that in mind - do you still need busybox mdadm?
(In reply to comment #20)
> > Just in case (IMHO better to add then not to add).
> Have you noticed that genkernel 3.4.12 an later com with the "real" mdadm?
> With that in mind - do you still need busybox mdadm?
May be I need just CONFIG_BLK_DEV_MD=y (instead of =m) with CONFIG_MD_AUTODETECT=y ;) (and mdstart/raidautorun). Now rebuilding. If no - "real" mdadm sounds good, but much bigger then this.
In other words, unrelated to me, this patch may at least reduce default size of kernel in RAM (md_mod module) and image (busybox-only) without raid support
About "mdstart" patch - I will look to him with autodetection, but in first look it may be replaced by existsings "raidautorun" command.
raidautorun: "xioctl(xopen(single_argv(argv), O_RDONLY), RAID_AUTORUN, NULL);"
mdstart: "ioctl(fd, RAID_AUTORUN, part);" (for 'part' from cmdline).
But raidautorun say: "Usage: raidautorun DEVICE". Then, may be in future - send upstream mix from both commands to make configurable "raidautorun".
After testing I may say more (days, becouse testing possible only in evening, as raids on proxy).
Even with CONFIG_BLK_DEV_MD=y & CONFIG_MD_AUTODETECT=y mdstart don't want to start my raid1s. Then, I still on mdadm (while this patch - it just working on minimal requirements).
Are I must try something else? ;) (no, raidautorun not tested [while])
USE=static emerge -1q busybox
replacing in cpio image
aidautorun: RAID_AUTORUN: Inappropriate ioctl for device
(In reply to comment #22)
> Even with CONFIG_BLK_DEV_MD=y & CONFIG_MD_AUTODETECT=y mdstart don't want to
> start my raid1s. Then, I still on mdadm (while this patch - it just working on
> minimal requirements).
I think you also need to configure in the apropriate level of the raid (i.e. any of CONFIG_MD_RAID0=y CONFIG_MD_RAID1=y CONFIG_MD_RAID10=y CONFIG_MD_RAID456=y).
Try with the correct one enabled, as for me this works both for software raids and fake raids.
maybe add the raid modules to the list of modules that is included in genkernel if they are not already?
Please let's take this to a new bug. Busybox has been upgraded. If something broke on the way, that's a new bug.
Also, if you want me to help fixing I'll need information in more detail as the whole topic is complex and quite new to me. Thanks for understanding.