Bug 169012

Summary: hotplug mount of (eg) USB thumb drive fails on diskless client
Product: [Fedora] Fedora Reporter: Andrew Bartlett <abartlet>
Component: halAssignee: David Zeuthen <davidz>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 4CC: biggie_biggz, god, jvdias, mclasen
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: fc6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-11-09 02:01:38 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:

Description Andrew Bartlett 2005-09-22 06:24:17 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050909 Fedora/1.0.6-1.2.fc4 Firefox/1.0.6

Description of problem:
The diskless environment provided by system-config-netboot sources certain files from the server, while keeping others local.  However, when the hotplug-triggered HAL events try to modify /etc/fstab, they do so by creating a tempory file in /etc and an atomic rename.

Because /etc is read-only from the server, creating the tmp file fails.

Version-Release number of selected component (if applicable):
system-config-netboot-0.1.30-1_FC4

How reproducible:
Always

Steps to Reproduce:
1. Standard install on prototype client
2. Upload to server (rsync)
3. Book diskless client, root on NFS
4. Plug in USB drive
  

Actual Results:  Drive fails to mount, or appear on desktop

Expected Results:  Drive appears on desktop as per disk-based install on prototype client

Additional info:

An strace of hald and it's children shows the tmp file creation failure.  The file in question is /etc/.fstab.hal.S

Comment 1 Jason Vas Dias 2005-09-22 16:02:25 UTC
With the current HAL system, the fstab-sync(8) program is unusable if the /etc
directory is mounted read-only. You must either mount the /etc directory RW, or
not use HAL . HAL's fstab-sync's open_temp_fstab_file() uses a temporary file
name with the prefix ".fstab.hal.", with a randomised suffix, so
system-config-netboot cannot predict exactly what this filename will be, 
and this file is always located in the /etc directory.

fstab-sync could use /tmp or a specific directory (eg. /var/lib/hal) to create 
its temporary fstab files, but then cannot use rename(2) to replace the fstab,
as  rename(2) will only work if the files are on the same filesystem device, 
which they cannot be if /etc is mounted read only in a netboot environment.

To clarify for the HAL maintainers: system-config-netboot mounts /etc/fstab
as a RW "snapshot" file. Each netboot client host has a RW NFS mount under
/.snapshot/`hostname` , and the diskless client init script does 
'mount -n -o bind /.snapshot/${HOST}/etc/fstab /etc/fstab'
to internally replace references to the '/etc/fstab' path with 
/.snapshot/`hostname`/etc/fstab.

Either hal must have an option to use a different directory for its temporary
files (eg. /tmp or /var/lib/hal), and then cannot use rename(2), OR it must
have an option to disable the randomisation of the fstab temporary file name,
so that this also can be made into a snapshot file on the same device as 
/etc/fstab, and rename() can continue to be used.

Another option is that system-config-netboot could replace HAL's fstab-sync 
program with a program that can be used with /etc mounted read-only.  

Please can the HAL maintainers let me know which way they want to fix this.

Comment 2 Andrew Bartlett 2005-09-23 22:44:09 UTC
Could we solve this by having the bind mount be of a symlink to the copied fstab
file?  Then update-fstab could know to follow symlinks to find where to put the
tmp file, and do the normal rename-in-place, at the symlink target dir.

(BTW, in my case we don't have the RW NFS mount, as I don't trust students, and
this file ends up in the tmpfs mounted on /).

Comment 3 Andrew Bartlett 2005-11-03 06:04:52 UTC
We worked around this problem by use of unionfs, loading it in rc.local and
taking over the /etc and /media directories

Comment 4 biggie_biggz 2005-11-03 06:06:43 UTC
This is what we used in /etc/rc.d/rc.local

kernel=`uname -r`
insmod /lib/modules/$kernel/kernel/fs/unionfs.ko
mkdir /tmp/media
mkdir /tmp/etc
mount -t unionfs -o dirs=/tmp/media=rw:/media/=ro none /media/
mount -t unionfs -o dirs=/tmp/etc=rw:/etc/=ro none /etc

Aside from kernel bugs (we will seperatly chase up USB robustness) it works fine
now.

Comment 5 Christian Iseli 2007-01-22 11:30:45 UTC
This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Thanks.

Comment 6 Andrew Bartlett 2007-07-25 01:22:40 UTC
I no longer have access to the diskless trial setup at the college, so sadly I
can't easily look into this for current releases. 

Comment 7 Andrew Bartlett 2007-11-09 02:01:38 UTC
I'm pretty sure this particular issue can't happen any more.  The new handling
(eg FC6) of USB disks in more recent versions does not use fstab-sync.