This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 153069 - Files left in rootfs
Files left in rootfs
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Jones
David Lawrence
: 159636 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2005-04-01 06:15 EST by Kasper Dupont
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version: 5.0.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-03 17:39:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Kernel module to help debugging the problem (2.57 KB, text/x-csrc)
2005-04-01 06:22 EST, Kasper Dupont
no flags Details
Patch as suggested by pjones (1.37 KB, patch)
2005-04-13 05:46 EDT, Kasper Dupont
no flags Details | Diff
recursiveRemove() (1.99 KB, patch)
2005-06-06 15:40 EDT, Peter Jones
no flags Details | Diff

  None (edit)
Description Kasper Dupont 2005-04-01 06:15:28 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):

How reproducible:

Steps to Reproduce:
1. Make the hidden rootfs the current directory
2. Type: du -ch *

Actual Results:  1.2M    total

Expected Results:  0       total

Additional info:

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.
Comment 1 Kasper Dupont 2005-04-01 06:22:24 EST
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.
Comment 2 Peter Jones 2005-04-01 11:42:28 EST
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.
Comment 3 Kasper Dupont 2005-04-13 05:46:31 EDT
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.
Comment 4 Peter Jones 2005-05-03 14:38:12 EDT
It really needs to remove *everything* on the filesystem except the directories
being used as mountpoints...
Comment 5 Kasper Dupont 2005-05-04 07:35:35 EDT
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.
Comment 6 Peter Jones 2005-05-05 22:17:44 EDT
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.
Comment 7 Peter Jones 2005-06-06 15:40:08 EDT
Created attachment 115174 [details]

Patch from #159636 by Jeff Layton (
Comment 8 Peter Jones 2005-06-06 16:06:13 EDT
*** Bug 159636 has been marked as a duplicate of this bug. ***
Comment 9 Jeff Layton 2005-06-10 14:53:32 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.