Bug 169012 - hotplug mount of (eg) USB thumb drive fails on diskless client
hotplug mount of (eg) USB thumb drive fails on diskless client
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
4
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: David Zeuthen
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-22 02:24 EDT by Andrew Bartlett
Modified: 2013-03-05 22:44 EST (History)
4 users (show)

See Also:
Fixed In Version: fc6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-08 21:01:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Andrew Bartlett 2005-09-22 02:24:17 EDT
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 12:02:25 EDT
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 18:44:09 EDT
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 01:04:52 EST
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 01:06:43 EST
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 06:30:45 EST
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-24 21:22:40 EDT
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-08 21:01:38 EST
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. 

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