Bug 894241
| Summary: | aug-init fail with the newest augeas package | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Mohua Li <moli> |
| Component: | libguestfs | Assignee: | Richard W.M. Jones <rjones> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | urgent | Docs Contact: | |
| Priority: | urgent | ||
| Version: | 7.0 | CC: | bfan, dcleal, enakai, leiwang, rjones, sagarun, sbaker, shardy, wshi |
| Target Milestone: | rc | Keywords: | TestBlocker |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | libguestfs-1.20.1-6.el7 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-06-13 11:56:20 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: | |||
I can reproduce this on Fedora 18 with: libguestfs-1.20.1-2.fc18.x86_64 augeas-1.0.0-1.fc18.x86_64 It'd be really useful to call aug_init with the AUG_NO_ERR_CLOSE flag and then call aug_error* when initialisation fails. See for instance: https://github.com/hercules-team/augeas/blob/master/src/augtool.c#L593 https://github.com/hercules-team/augeas/blob/master/src/augtool.c#L412 This _might_ be caused by attempting to read files with funky filenames. To get more information about the error, pass the AUG_NO_LOAD flag to aug_init, and then issue a separate aug_load and look at the errors from that. You can also try to trigger the error by running augtool -A 'load' on the affected system. Is there any way you could send me the /etc from the machine to help me analyze this ? (In reply to comment #3) > This _might_ be caused by attempting to read files with funky filenames. To > get more information about the error, pass the AUG_NO_LOAD flag to aug_init, > and then issue a separate aug_load and look at the errors from that. You can > also try to trigger the error by running augtool -A 'load' on the affected > system. > > Is there any way you could send me the /etc from the machine to help me > analyze this ? i didn't find a way to send you the /etc so far, as it's in the libguestfs appliance env, (In reply to comment #6) > i didn't find a way to send you the /etc so far, as it's in the libguestfs > appliance env, Whoa wait ... you're doing aug-init on the libguestfs appliance *itself*? Well, I guess that should work, but I'm not sure why you'd want to ever do that. In any case, you can extract the libguestfs appliance /etc using libguestfs (naturally): cd /var/tmp/.guestfs-`id -u` guestfish -a root -m /dev/sda --ro tar-out /etc /tmp/etc.tar ls -l /tmp/etc.tar To extract /etc from a regular disk image, do this instead: virt-tar-out -d disk.img /etc /tmp/etc.tar (In reply to comment #7) > To extract /etc from a regular disk image, do this instead: Correction: virt-tar-out -a disk.img /etc /tmp/etc.tar (In reply to comment #7) > (In reply to comment #6) > > i didn't find a way to send you the /etc so far, as it's in the libguestfs > > appliance env, > > Whoa wait ... you're doing aug-init on the libguestfs appliance *itself*? > > Well, I guess that should work, but I'm not sure why you'd want > to ever do that. no, not the appliance itself, but aug-init on a disk image which add with "-a" to guestfish > > In any case, you can extract the libguestfs appliance /etc using > libguestfs (naturally): > > cd /var/tmp/.guestfs-`id -u` > guestfish -a root -m /dev/sda --ro tar-out /etc /tmp/etc.tar > ls -l /tmp/etc.tar > > To extract /etc from a regular disk image, do this instead: > > virt-tar-out -d disk.img /etc /tmp/etc.tar yup, just forgot i could hack the appliance disk image, thanks for remind *** Bug 901439 has been marked as a duplicate of this bug. *** The issue is the hostfiles list to build the contents of the libguestfs appliance is out of date with respect to the contents of the augeas packages. By adding augtool into the appliance and running it, I was able to get the detailed error messages. A number of modules were added in Augeas 1.0.0, two of which (Quote and Simplevars) are new dependencies for existing modules. ><rescue> augtool Failed to initialize Augeas error: Syntax error in lens definition /usr/share/augeas/lenses/dist/dhcpd.aug:95.14-.28:Could not load module Quote for Quote.do_quote /usr/share/augeas/lenses/dist/dhcpd.aug:95.14-.28:Undefined variable Quote.do_quote ><rescue> augtool Failed to initialize Augeas error: Syntax error in lens definition /usr/share/augeas/lenses/dist/sysctl.aug:36.34-.50:Could not load module Simplevars for Simplevars.entry /usr/share/augeas/lenses/dist/sysctl.aug:36.34-.50:Undefined variable Simplevars.entry Adding these to the supermin hostfiles (/usr/lib64/guestfs/supermin.d/hostfiles) resolved the issue: /usr/share/augeas/lenses/dist/quote.aug /usr/share/augeas/lenses/dist/simplevars.aug I guess rebuilding libguestfs would resolve the issue, as it'd pick up the new package list from Augeas 1.0.0. It seems though that either the dependency between the built libguestfs RPM and the packages it's pulling into the appliance should be tighter, or the hostfiles list made more dynamic. I see, not good. Let's go for the rebuild option (Fedora 18 and RHEL 7 should cover it). For Fedora 18: libguestfs-1.20.1-3.fc18 is building here: http://koji.fedoraproject.org/koji/taskinfo?taskID=4880583 Can't build on RHEL 7 at the moment because qemu is broken (bug 901542). Sorry I don't have a separate bug for the Fedora 18 issue, but please try this package and mod it up if it works for you: https://admin.fedoraproject.org/updates/libguestfs-1.20.1-3.fc18 $ egrep 'augeas.*(quote|simplevars)' /usr/lib64/guestfs/supermin.d/hostfiles /usr/share/augeas/lenses/dist/quote.aug /usr/share/augeas/lenses/dist/simplevars.aug /usr/share/augeas/lenses/dist/tests/test_quote.aug /usr/share/augeas/lenses/dist/tests/test_simplevars.aug Fedora 17 is also affected by this I've kicked off an F17 rebuild: http://koji.fedoraproject.org/koji/taskinfo?taskID=4888499 I just added a --trace option to augparse (commit 85db83cd) so that it will print which modules are loaded - hopefully that will be useful in generating hostfiles. Fedora 17 build worked for me, Thanks! The problem now happens in RHEL5 $ rpm -q augeas augeas-1.0.0-1.el5 $ rpm -q python-augeas python-augeas-0.4.1-1.el5 $ rpm -q libguestfs libguestfs-1.19.37-4.el5 (In reply to comment #21) > The problem now happens in RHEL5 > > $ rpm -q augeas > augeas-1.0.0-1.el5 > > $ rpm -q python-augeas > python-augeas-0.4.1-1.el5 > > $ rpm -q libguestfs > libguestfs-1.19.37-4.el5 You mean EPEL 5? Please file a separate bug about it. (In reply to comment #22) > You mean EPEL 5? Please file a separate bug about it. Done https://bugzilla.redhat.com/show_bug.cgi?id=906361 Thanks! Verified: libguestfs-1.22.2-1.el7.x86_64 augeas-1.0.0-2.el7.x86_64 # guestfish -N fs mount /dev/sda1 / : aug-init / 1 No error feedback. 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. |
Description of problem: aug-init fail with "Augeas initialization failed", this fail occur on the latest augeas package augeas-1.0.0-1.el7, no problem with augeas-0.10.0-5.el7, on libguestfs, just simply call the aug_init api, so it's probably a augeas problem, daemon/augeas.c 83 84 aug = aug_init (buf, NULL, flags); 85 free (buf); 86 87 if (!aug) { 88 reply_with_error ("Augeas initialization failed"); 89 return -1; 90 } Version-Release number of selected component (if applicable): libguestfs-1.20.1-4.el7.x86_64 augeas-1.0.0-1.el7 How reproducible: always Steps to Reproduce: 1.guestfish -x -v -N fs mount /dev/sda1 / : aug-init / 1 Actual results: Expected results: Additional info: