Red Hat Bugzilla – Bug 153069
Files left in rootfs
Last modified: 2007-11-30 17:11:03 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114
Description of problem:
When booting, the nash script leaves a number of files in the rootfs file system hidden under the real root. Since rootfs is based on ramfs, this essentially means that 1.2MB of RAM is leaked during boot.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Make the hidden rootfs the current directory
2. Type: du -ch *
Actual Results: 1.2M total
Expected Results: 0 total
Since the file system containing these files is hidden, actually getting a list of the files is a bit tricky. I'll attach a module that will chdir into this hidden directory.
Created attachment 112575 [details]
Kernel module to help debugging the problem
Compile and load the module, then type "echo </dev/hack" to chdir into the
hidden directory. No guarantees - this module mess with VFS data structures.
Yeah, I saw this when I put in the changes to fix the /sys,/proc, and /dev
mounts. The solution is to make a "cleanup rootfs" function in nash, and make
switchrootCommand() call it. But at 1.2M, that's a very low priority right now.
Created attachment 113084 [details]
Patch as suggested by pjones
Here is my suggestion for at patch solving this problem. It follows the
principle suggested by Peter Jones in the previous comment. It works for me,
though it may require additional filenames for other scenarios.
It really needs to remove *everything* on the filesystem except the directories
being used as mountpoints...
My patch removes everything except directories. At least in the configuration
where I tested it, it does. Is it infeasible to include a list of all filenames
to remove? The alternative would be something similar to rm -rf, which I was
afraid would be too error prone.
Well, if we're to include it, then mkinitrd needs to generate it -- the users
can add whatever kernel modules they'd like, so we have to be able to handle that.
In general, a dynamic solution would be best (be it dynamic at boot time or
during mkinitrd) would be best, as maintaining a list of files is a nightmare.
Created attachment 115174 [details]
Patch from #159636 by Jeff Layton (email@example.com)
*** Bug 159636 has been marked as a duplicate of this bug. ***
Tried out the new mkinitrd (4.2.16) on a test box today, and hacked some small
changes into it for testing. I enabled -DDEBUG in the build process and added
this just after the recursiveRemove():
After that, I booted to an initramfs with my test nash, and it showed
Switching to new root
unmounting old /proc
unmounting old /sys
So it looks like only /proc,/sys, and /sysroot were still in the root
directory just before switching roots. I suppose this means we can call the
recursiveRemove() a (tentative) success.