Bug 153069 - Files left in rootfs
Summary: Files left in rootfs
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
(Show other bugs)
Version: 3
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Peter Jones
QA Contact: David Lawrence
URL:
Whiteboard:
Keywords:
: 159636 (view as bug list)
Depends On:
Blocks:
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:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-03 22:39:44 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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 11:22 UTC, Kasper Dupont
no flags Details
Patch as suggested by pjones (1.37 KB, patch)
2005-04-13 09:46 UTC, Kasper Dupont
no flags Details | Diff
recursiveRemove() (1.99 KB, patch)
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):
mkinitrd-4.2.7-1

How reproducible:
Always

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]
recursiveRemove()

Patch from #159636 by Jeff Layton (jlayton@redhat.com)

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():

lsdir("/","");

After that, I booted to an initramfs with my test nash, and it showed
this:

Switching to new root
//proc/
//sys/
//sysroot/
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.