Created attachment 318388 [details] sys-kernel/mkinitramfs-ll-{0.10.4,9999} consider adding sys-kernel/mkinitramfs-ll: https://github.com/tokiclover/bar-overlay/tree/master/sys-kernel/mkinitramfs-ll why mkinitramfs-ll? * it's a little flexible and efficient initramfs generating tool; * with full LUKS (crypted key file (LUKS, GnuPG), detached headers), LVM, aufs+squashfs, fbsplash (fbcondecor), RAID (dm-raid and software raid (mdadm) and ZFS support; * nothing close to dracut or mkinitcpio or even genkernel with thousends of lines; * everythng is hold on ~550 lines init scripts with a few module/scripts (e.g. zfs).
can this bug assigned to maintainer-wanted?
Created attachment 318446 [details] sys-kernel/mkinitramfs-ll-{0.10.4,9999} new version (little clean up) thanks to floppym.
Created attachment 318452 [details] sys-kernel/mkinitramfs-ll-{0.10.4,9999} newer with src_unpack()...default... helper fix (did work at all); and default values depending on USE flag fix.
Created attachment 318576 [details] sys-kernel/mkinitramfs-ll-9999 edited thanks to Tommy[D] with separate live version.
Created attachment 318578 [details] sys-kernel/mkinitramfs-ll-0.10.5 edited thanks to Tommy[D] with separate versioned.
Created attachment 319554 [details] sys-kernel/mkinitramfs-ll-9999 fix e2fs USE flag issue
Created attachment 319556 [details] sys-kernel/mkinitramfs-ll-0.10.6 fix e2fs USE flag issue and version bump
Created attachment 319722 [details] sys-kernel/mkinitramfs-ll-0.10.8 version bump and edit thanks to floppym
Created attachment 319724 [details] sys-kernel/mkinitramfs-ll-9999 edit thanks to floppym.
Created attachment 390760 [details] sys-kernel/mkinitramfs-ll-0.14.8
Created attachment 390762 [details] sys-kernel/mkinitramfs-ll-9999
Just bumping this request and I volonteer for proxy-maintaiing this ebuild.
Why, advantages of this little projet: A powerfull and yet modular initramfs generating tools keeping KISS principle. This is not a big/huge monolitic tool that fits all a la genkernel way nor a big modular tool a la dracut which depends on udev as well. This tool solely rely on mdev/ash to boot up a system plus user selected tools/scripts and binaries. There is a few default *profiles* e.g. dm-crypt, device-mapper, md-raid, ATA-raid, zfs, zram, bcache and GnuPG to be able to get an initramfs ready in matter of seconds if a busybox binary is available which can be tailored/tuned to user needs. The only short coming is gpg-0.1.4 static binary requirement because the package even support a custom busybox binary along with a dynamic shared object binary support even if it is not adviced to use a dynamic one. The project is mature enough and debugged... So, it should *just works(TM)*.
(In reply to tokiclover from comment #13) > The only short coming is gpg-0.1.4 static binary requirement because the Not true anymore because dynamic GnuPG are also supported. I don't remember when I added this, but it's there since... a while ago.
BUMP. Of course I am calling this initramfs generating tools because there is no dependency/internal bash, util-linux nor coreutils. (I don't remember exactly what genkernel/dracut bundle... but one can easily guess by looking at it. I guess SystemD is in the next list, sight...)
there is a missing _light weight_ in the first sentence, put it anywhere... or after initramfs to make sense.
Created attachment 393830 [details] mkinitramfs-ll-0.16.2 A big clean up (documentation & init service script) went smoothly; and two manual pages (section 1 & 8) were added (the end of a painful ~500 lines(--novel!--)README.textile.) A minor update with (current) btrfs hook (with dm-crypt LUKS support) took its way underneath the clean up. Fair enough, the ebuilds were cleaned up as well (no more automatic configuration depending on USE flags.) Big clean up, I was saying.
Created attachment 393832 [details] mkinitramfs-ll-9999 Same (as above.)
BUMP. There is a new version (0.18.0) available which brought in kernel cmdline names... for clarity! (Legacy cmdline option was not used for incompatibility reasons... but it wasn't a wise move because the init behaved as one could expect when using the equivalent argument supported by the legacy _root,swap,resume,splash,console|CONSOLE,rw|ro,single_... Still following? Anyway, those legacy cmdline name are now used instead of... unecessary confusion!) Please _be_ alive and react. (Seems like, talking to dead or _deaf_(?) people.)