Bug 56979

Summary: mkinitrd does not like /tmp on tmpfs
Product: [Retired] Red Hat Linux Reporter: Michal Jaegermann <michal>
Component: mkinitrdAssignee: Matt Wilson <msw>
Status: CLOSED RAWHIDE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.2Keywords: FutureFeature
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-01-16 20:26:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Patch to use /var/tmp, with a possible override, in mkinitrd none

Description Michal Jaegermann 2001-12-01 22:38:34 UTC
Description of Problem:

If tmpfs happens to be used for /tmp then mkinitrd, hence also
mkbootdisk and kernel updates, fail because one cannot, at least
currently, to mount over a loop device a file which resides on a file
system of a tmpfs type.

A quick workaround, which has pretty good chances to work, is it use
/var/tmp instead with a possible override in an evironmental variable.
An attached patch does just that.

Somewhat better would be to allow to specify other then a default
temporary directory on a command line.  But to make this work reasonably
reliably with kernel updates mkinitrd should test if it tries to use
files on tmpfs and switch to another file system if this is the case
(or / could be simply used here as chances that it is of a tmpfs type on
a normal installation are rather slim :-).

Comment 1 Michal Jaegermann 2001-12-01 22:40:20 UTC
Created attachment 39304 [details]
Patch to use /var/tmp, with a possible override, in mkinitrd

Comment 2 Erik Troan 2002-01-16 20:26:24 UTC
This is fixed in mkinird-3.3.1 properly (in rawhide soon), but I can't seem to
close bugs right now.

Comment 3 Erik Troan 2002-01-16 20:29:43 UTC
Galeon better :-)