As noted in bug 750357, /run/initramfs is still populated after booting, using up a lot of memory. Perhaps a systemd startup service that prunes it after handing over to the real init is needed ?
On shutdown, we go back to the initramfs now. It is needed to properly disassemble raid devices or log out of network servers that provide filesystems. Dracut should probably delete itself, like it did in earlier releases, when there was nothing to assemble during bootup.
even when there is something to assemble, there's a ton of crap left there taking up ram that isn't going to get used. not only dracut, but the bulk of it is stuff like plymouth themes, keymaps, and kernel modules. just keep around the bare minimum that's needed to do what you need.
yes, you are right... and for those who don't want it right now: # echo "unset prefix" >> /etc/dracut.conf.d/99-my.conf
(In reply to comment #2) > even when there is something to assemble, there's a ton of crap left there > taking up ram that isn't going to get used. > > not only dracut, but the bulk of it is stuff like plymouth themes, keymaps, and > kernel modules. It's huge. # du -s -k /run/initramfs 42076 /run/initramfs Forty two megs on my machine.
dracut-014-61.git20120123.fc17
*** Bug 785538 has been marked as a duplicate of this bug. ***
$ du -ch /run/initramfs 12M /run/initramfs for a hostonly dracut image.
I still somehow don't get it - My machine could run for a week with just suspending - I'm not using swap. And now I don't get the point of blocking 12MB of memory just because maybe I want to reboot once in a week? Why is problem to decompress image to ramdisk BEFORE doing a reboot - and then run needed binaries from there - yeah it may delay reboot for 0.1 second....
(In reply to comment #8) > I still somehow don't get it - > > My machine could run for a week with just suspending - I'm not using swap. > And now I don't get the point of blocking 12MB of memory just because maybe I > want to reboot once in a week? > > Why is problem to decompress image to ramdisk BEFORE doing a reboot - and then > run needed binaries from there - yeah it may delay reboot for 0.1 second.... Actually, the idea of compressing, saving and restoring has also come to my mind. Have to think about it a little bit more.
$ du -ch /run/initramfs/ 8.0K /run/initramfs/ 8.0K total fixed with dracut-015-8.git20120210.fc17