Bug 584228

Summary: tgz-in/tar-in command hang when run with a vfat img
Product: [Community] Virtualization Tools Reporter: Pengzhen Cao <pcao>
Component: libguestfsAssignee: Richard W.M. Jones <rjones>
Status: CLOSED UPSTREAM QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: mbooth, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 584243 (view as bug list) Environment:
Last Closed: 2011-07-14 19:06: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:
Bug Depends On: 576879, 627835    
Bug Blocks: 584243    
Attachments:
Description Flags
tar-in behavior with latest v1.3.4 git version
none
Log file from guestfish -v output none

Description Pengzhen Cao 2010-04-21 03:42:45 UTC 
Description of problem:
tgz-in/tar-in command will hang when run with a vfat img

Version-Release number of selected component (if applicable):
libguestfs-1.0.85-1.fc12.3.x86_64

How reproducible:
100%

Steps to Reproduce:
1. mount a blank vfat img and run
2. run tgz-in/tar-in xxx.tgz/xxx.tar /
3. guestfish will hang there
  
Actual results:
guestfish hang there

Expected results:
there should not be error message or guestfish hang

Additional info:

I have tried with latest git version 1.3.4, behaviour is different. 
guestfish will not hang but give error message "libguestfs: error: tgz_in: tar subcommand failed on directory: /"
It seems this issue is caused by the chmod cmd

logs for guestfish v1.0.85
><fs> run
><fs> set-verbos 1
set-verbos: unknown command
><fs> set-verbose 1
><fs> set-trace 1
><fs> mount /dev/vda1 /
mount "/dev/vda1" "/"
send_to_daemon: 0x28549e0 g->state = 3, n = 52
recv_from_daemon: 0x28549e0 g->state = 3, size_rtn = 0x7fff3960507c, buf_rtn = 0x7fff39605070
><fs> ll /
ll "/"
send_to_daemon: 0x28549e0 g->state = 3, n = 36
recv_from_daemon: 0x28549e0 g->state = 3, size_rtn = 0x7fff3960507c, buf_rtn = 0x7fff39605070
total 8
drwxr-xr-x  2 root root 8192 Dec 31  1969 .
dr-xr-xr-x 20 root root    0 Mar 12 10:39 ..

><fs> tgz-in file_ops_simple2.tgz /
tgz_in "file_ops_simple2.tgz" "/"
send_to_daemon: 0x28549e0 g->state = 3, n = 36
send_to_daemon: 0x28549e0 g->state = 3, n = 276
send_to_daemon: 0x28549e0 g->state = 3, n = 12
recv_from_daemon: 0x28549e0 g->state = 3, size_rtn = 0x7fff3960507c, buf_rtn = 0x7fff39605070
tar: file_ops/file_ascii: Cannot change ownership to uid 500, gid 500: Operation not permitted
tar: Exiting with failure status due to previous errors
recv_from_daemon: 0x28549e0 g->state = 3, size_rtn = 0x7fff3960507c, buf_rtn = 0x7fff39605070
^C
Comment 1 Pengzhen Cao 2010-04-21 05:35:39 UTC 
I noticed there are two git commits on Apr.8th that changed the tar-in behavior：
07f4b20ae959069fca41756b0dc103ec5fa99754
de7ef2a0fdcbcddfd35ecb8ee2804e1ca0968454
one comment is:
"(b) Use write instead of fwrite to write out the tar file.  This is
     just because the error handling of write seems to be better
     specified and easier to use."
Is this changeset that fix the hang issue?

But do we need to throw out error message like"
libguestfsd: error:  tgz-in: tar subcommand failed on directory: /" when run with vfat images? I think we should not do chown on vfat images.
Comment 2 Pengzhen Cao 2010-04-21 05:55:01 UTC 
Created attachment 407990 [details]
tar-in behavior with latest v1.3.4 git version

add log file of tgz-in behaviour with latest v1.3.4 libguestfs
Comment 3 Richard W.M. Jones 2010-04-21 09:27:37 UTC 
I think this is an instance of bug 576879.

'tar-in' generally fails if the target is a vfat partition.  The reason is
that the 'tar' command tries to change the ownership of files to
match what is in the tarball (ie. calling chown(2)), but vfat doesn't
support chown and gives an error.

This is further compounded by the fact that we still don't
handle errors in upload/*-in commands properly, which is
bug 576879.
Comment 4 Richard W.M. Jones 2010-05-12 16:35:16 UTC 
*** Bug 584243 has been marked as a duplicate of this bug. ***
Comment 5 Richard W.M. Jones 2010-05-20 08:42:20 UTC 
Reproducer:

guestfish -N fs:vfat:1G -m /dev/sda1 upload /tmp/libguestfs-1.3.13.tar.gz /

(where /tmp/libguestfs-1.3.13.tar.gz is any largish tarball)
Comment 6 Richard W.M. Jones 2010-05-20 09:01:27 UTC 
Created attachment 415350 [details]
Log file from guestfish -v output
Comment 7 Richard W.M. Jones 2011-03-18 19:04:42 UTC 
The reproducer in comment 5 is *WRONG*.  It contains an error
because the command should be "tar-in" or "tgz-in", not "upload".

A corrected reproducer is:

guestfish -N fs:vfat:1G -m /dev/sda1 tgz-in /tmp/libguestfs-1.3.13.tar.gz /

(where again "/tmp/libguestfs-1.3.13.tar.gz" is any tarball
which is large but much smaller than 1G).

In the error case, this hangs.

In the fixed case, this does not hang but will either succeed
(if tar in the daemon is ignoring UIDs like a good boy) or
will give a suitable error message and not lose protocol synch.

Note that for me this is all fixed by the patch series discussed in
https://bugzilla.redhat.com/show_bug.cgi?id=576879#c9
https://bugzilla.redhat.com/show_bug.cgi?id=576879#c10
Comment 8 Richard W.M. Jones 2011-03-18 20:03:47 UTC 
This fix is included in libguestfs 1.9.12.
Comment 9 Richard W.M. Jones 2011-07-14 19:06:29 UTC 
I've tested this again with libguestfs 1.11.16 and
it is fixed.