[systemd-devel] Minimize systemd for kdump's initramfs

Zbigniew Jędrzejewski-Szmek zbyszek at in.waw.pl
Thu Jan 2 22:59:45 UTC 2020


On Thu, Jan 02, 2020 at 03:29:26PM -0500, Robbie Harwood wrote:
> Kairui Song <kasong at redhat.com> writes:
> 
> > What I'm trying to do is reduce the initramfs size used for kdump.
> > Kdump loads a crash kernel and kdump initramfs image in a prereseved
> > memory region, which get booted when current kernel crashed and
> > perform crash dump. The prereserved memory is limited, so initramfs
> > shouldn't go too big.
> >
> > Kdump in Fedora use Dracut to create bootable initramfs, just hook the
> > final step to do kdump things instead of switch root. And to reduce
> > the size only the binaries and drivers required to boot and perform
> > kdump on current machine is installed. So long it have been working
> > very well.
> >
> > But problem is Dracut works by reusing binaries and libraries from the
> > currently running system, and many userspace binaries and libraries is
> > keep growing and using more space. So the initramfs is also growing.
> >
> > /root/image/bin/bash
> > 4.8M    .
> > /root/image/bin/sh
> > 4.8M    .
> 
> So it's not a direct comparison, but:
> 
> $ du -sh /bin/bash /bin/dash
> 1.2M /bin/bash
> 132K /bin/dash
> 
> This suggests to me that 1-3 MB could be reduced by using dash as the
> shell.  (dash's library dependencies are also smaller since it drops
> requirements on libtinfo (200K) and libdl (36K); whether this matters I
> don't know.)

dash doesn't support various bash extensions and syntaxes. The problem
is that many scripts which use #!/bin/sh really require #!/bin/bash.
So after switching to dash as the provider of /bin/sh various scripts
would suddenly behave differently, and those bugs would only be detected
at runtime.

Debian went through a long process of switching to dash as the default
init shell and fixing various scripts to remove bashisms so things
would run on dash (or any other /bin/sh). This was way more work than
anyone excepted and took a long time. IMO the gain of 1 MB that we
would get is not nearly enough to offset the work required and the
destabilization.

(In Debian the motivation was speed, rather than installation footprint.
So that work was mostly wasted because of the switch from sysvinit to systemd
and ensuing avoidance of shell during boot. Instead of trying to switch
shells, we should instead try to avoid shell in boot as much as possible.)

Zbyszek


More information about the systemd-devel mailing list