Bug 920609

Summary: inspect-get-hostname return unknown for linux guest
Product: Red Hat Enterprise Linux 7 Reporter: Mohua Li <moli>
Component: augeasAssignee: Dominic Cleal <dcleal>
Status: CLOSED CURRENTRELEASE QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.0CC: bfan, dcleal, leiwang, rjones, wshi
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: augeas-1.1.0-1.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-13 12:09:53 UTC Type: Bug
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: 904222    
Bug Blocks:    
Attachments:
Description Flags
libguestfs debug log none

Description Mohua Li 2013-03-12 12:48:11 UTC
Description of problem:

inspect-get-hostname return unknown for all linux guest, but function correctly with windows guest


[root@hp-z220-02 images]# root=`guestfish --remote -- inspect-os`
[root@hp-z220-02 images]# guestfish --remote -- inspect-get-hostname $root
unknown




Version-Release number of selected component (if applicable):
libguestfs-1.20.2-1.el7.x86_64

How reproducible:
always

Steps to Reproduce:
eval `guestfish --listen`                                                                       107   guestfish --remote -- add $GSTEST_image_path
108   guestfish --remote -- run
109   root=`guestfish --remote -- inspect-os`
110   hostname=`guestfish --remote -- inspect-get-hostname $root`

Comment 2 Richard W.M. Jones 2013-03-12 12:53:51 UTC
(In reply to comment #0)
> Description of problem:
> 
> inspect-get-hostname return unknown for all linux guest,

*All* Linux guests?  Can you give me a specific version
of a Linux guest that fails?

Does this still happen when you're not using guestfish --listen?
(The reason is that it's rather harder to debug this in remote
mode).  Try:

  guestfish -v -x --add $GSTEST_image_path
  ><fs> run
  ><fs> inspect-os
  [it prints a root here]
  ><fs> inspect-get-hostname [root]

That will produce a lot of debug output, because of -v and -x
options, so attach all of it to the bug report.

Comment 4 Mohua Li 2013-03-12 13:14:51 UTC
(In reply to comment #2)
> (In reply to comment #0)
> > Description of problem:
> > 
> > inspect-get-hostname return unknown for all linux guest,
> 
> *All* Linux guests?  Can you give me a specific version
> of a Linux guest that fails?

yes, all linux guestfs, 4.8, 5.x, 6.3

> 
> Does this still happen when you're not using guestfish --listen?
> (The reason is that it's rather harder to debug this in remote
> mode).  Try:
> 
>   guestfish -v -x --add $GSTEST_image_path
>   ><fs> run
>   ><fs> inspect-os
>   [it prints a root here]

there is another problem i'm going to report, the return is empty if not in remote mode,

>   ><fs> inspect-get-hostname [root]
> 
> That will produce a lot of debug output, because of -v and -x
> options, so attach all of it to the bug report.

as above

Comment 5 Richard W.M. Jones 2013-03-12 14:24:27 UTC
(In reply to comment #4)
> (In reply to comment #2)
> > Does this still happen when you're not using guestfish --listen?
> > (The reason is that it's rather harder to debug this in remote
> > mode).  Try:
> > 
> >   guestfish -v -x --add $GSTEST_image_path
> >   ><fs> run
> >   ><fs> inspect-os
> >   [it prints a root here]
> 
> there is another problem i'm going to report, the return is empty if not in
> remote mode,

That's peculiar.  What is the output of:

guestfish -v -x --add /path/to/the/linux.img run : inspect-os

?

Comment 6 Mohua Li 2013-03-15 04:07:13 UTC
i just can't reproduce the inspect-os return empty problem, maybe just some display problem, i will mark it down.

now here is full debug log for inspect-get-hostname, for more pls see the attachment, 



libguestfs: trace: vfs_type = "swap"
libguestfs: check_for_filesystem_on: /dev/vg_dhcp669266/lv_swap 0 0 (swap)
libguestfs: trace: inspect_os = ["/dev/vg_dhcp669266/lv_root"]
/dev/vg_dhcp669266/lv_root

><fs> inspect-get-hostname /dev/vg_dhcp669266/lv_root                                                                                                                                                            
libguestfs: trace: inspect_get_hostname "/dev/vg_dhcp669266/lv_root"
libguestfs: trace: inspect_get_hostname = "unknown"
unknown

Comment 7 Mohua Li 2013-03-15 04:10:38 UTC
Created attachment 710408 [details]
libguestfs debug log

Comment 8 Richard W.M. Jones 2013-03-15 10:41:31 UTC
From the log what happens is that we read /etc/sysconfig/network
looking for a HOSTNAME=... entry in this file.  Augeas says there
is no such entry.

So it could be:

 - There really is no HOSTNAME entry in /etc/sysconfig/network

 - Augeas is broken in some way

 - Some other file contains the hostname [however I know this is
   not true for all RHEL <= 6]

Can you let us know the contents of /etc/sysconfig/network?  ie:

  virt-cat -a /path/to/the/linux.img /etc/sysconfig/network

Comment 9 Mohua Li 2013-03-18 07:53:55 UTC
(In reply to comment #8)
> From the log what happens is that we read /etc/sysconfig/network
> looking for a HOSTNAME=... entry in this file.  Augeas says there
> is no such entry.
> 
> So it could be:
> 
>  - There really is no HOSTNAME entry in /etc/sysconfig/network
> 
>  - Augeas is broken in some way

actually we have the hostname in /etc/sysconfig/network, 

[root@hp-z220-02 images]# virt-cat -a RHEL-Server-6.0-32-hvm.raw /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=dhcp-66-92-66.nay.redhat.com
[root@hp-z220-02 images]# virt-cat -a RHEL-Server-6.0-64-hvm.raw /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=dhcp-66-92-66.nay.redhat.com



> 
>  - Some other file contains the hostname [however I know this is
>    not true for all RHEL <= 6]
> 
> Can you let us know the contents of /etc/sysconfig/network?  ie:
> 
>   virt-cat -a /path/to/the/linux.img /etc/sysconfig/network

Comment 10 Richard W.M. Jones 2013-03-18 09:07:26 UTC
$ mkdir -p /tmp/p/etc/sysconfig
$ cat > /tmp/p/etc/sysconfig/network
NETWORKING=yes
HOSTNAME=dhcp-66-92-66.nay.redhat.com
$ augtool -r /tmp/p
augtool> ls /files
[no output ... wtf?]

It looks as if Augeas in RHEL 7 doesn't parse /etc/sysconfig/network
at all?

augeas-1.0.0-1.el7.x86_64

Comment 11 Richard W.M. Jones 2013-03-18 10:57:22 UTC
(In reply to comment #10)
> $ mkdir -p /tmp/p/etc/sysconfig
> $ cat > /tmp/p/etc/sysconfig/network
> NETWORKING=yes
> HOSTNAME=dhcp-66-92-66.nay.redhat.com
> $ augtool -r /tmp/p
> augtool> ls /files
> [no output ... wtf?]
> 
> It looks as if Augeas in RHEL 7 doesn't parse /etc/sysconfig/network
> at all?
> 
> augeas-1.0.0-1.el7.x86_64

This doesn't work on F18 either.  However it does work in RHEL 6.

Comment 12 Dominic Cleal 2013-03-21 23:19:14 UTC
Same issue reported in bug #904222.

Fixed upstream: https://github.com/hercules-team/augeas/commit/d6959e62

Comment 16 bfan 2013-08-06 06:34:02 UTC
Verified with augeas-1.1.0-1.el7.x86_64,

[root@hp-dl385g7-13 home]# guestfish -a RHEL-Server-5.9-64-hvm.raw 

Welcome to guestfish, the guest filesystem shell for
editing virtual machine filesystems and disk images.

Type: 'help' for help on commands
      'man' to read the manual
      'quit' to quit the shell

><fs> run
 100% ⟦▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒⟧ 00:00
><fs> inspect-os
/dev/VolGroup00/LogVol00
><fs> inspect-get-hostname /dev/VolGroup00/LogVol00
localhost.localdomain
><fs> quit

[root@hp-dl385g7-13 home]# virt-cat -a RHEL-Server-5.9-64-hvm.raw /etc/sysconfig/network
NETWORKING=yes
NETWORKING_IPV6=no
HOSTNAME=localhost.localdomain

Also works for rhel6, rhel7. for rhel7, it parses /etc/hostname instead of /etc/sysconfig/network

So change the status to verified

Comment 17 Ludek Smid 2014-06-13 12:09:53 UTC
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.