Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 153069 - Files left in rootfs
Summary: Files left in rootfs
Alias: None
Product: Fedora
Classification: Fedora
Component: mkinitrd
Version: 3
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Peter Jones
QA Contact: David Lawrence
: 159636 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2005-04-01 11:15 UTC by Kasper Dupont
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version: 5.0.0
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-02-03 22:39:44 UTC

Attachments (Terms of Use)
Kernel module to help debugging the problem (deleted)
2005-04-01 11:22 UTC, Kasper Dupont
no flags Details
Patch as suggested by pjones (deleted)
2005-04-13 09:46 UTC, Kasper Dupont
no flags Details | Diff
recursiveRemove() (deleted)
2005-06-06 19:40 UTC, Peter Jones
no flags Details | Diff

Description Kasper Dupont 2005-04-01 11:15:28 UTC
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 11:22:24 UTC
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 16:42:28 UTC
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 09:46:31 UTC
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 18:38:12 UTC
It really needs to remove *everything* on the filesystem except the directories
being used as mountpoints...

Comment 5 Kasper Dupont 2005-05-04 11:35:35 UTC
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-06 02:17:44 UTC
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 19:40:08 UTC
Created attachment 115174 [details]

Patch from #159636 by Jeff Layton (

Comment 8 Peter Jones 2005-06-06 20:06:13 UTC
*** Bug 159636 has been marked as a duplicate of this bug. ***

Comment 9 Jeff Layton 2005-06-10 18:53:32 UTC
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.