On Thu, Jan 02, 2020 at 03:29:26PM -0500, Robbie Harwood wrote: > Kairui Song <kas...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
