4:15 p.m.
On Mon, Dec 17, 2012 at 04:46:02PM -0500, Skippy VonDrake wrote:
> As far as we know, this means the registry is really corrupt
(or
> something odd has happened, such as it's been zero-padded).
It appears that the registry did have something wrong with it.
I booted the image in Xen and saw a message window pop up:
"Registry Recovery - One of the files containing the system's
Registry data had to be recovered by use of a log or alternate copy
The recovery was successful."
And after I shut the VM back down, guestfs was able to load
and continue past the call to guestfs_inspect_os() with no
problems.
Is there a way I can get more data to determine exactly where
the hivex calls are failing? Maybe then a fix could be made to
still return the root devices even when the registry is a little
"off".
It's possible we could add a HIVEX_OPEN_FIXUP flag or something like
that. In this case (empty hbins) it would probably be safe, but I'd
worry about trying to "fix" more egregious registry errors,
particularly since we don't fully understand the format.
With this in mind I altered 'hivex.c', function
do_hivex_open(),
by commenting out the code around the statements:
flags |= HIVEX_OPEN_VERBOSE;
flags |= HIVEX_OPEN_DEBUG;
Effectively hard-coding them. Hoping that more info would be
generated. However that obviously wasn't enough for the
process just seemed to "hang".
You'll also need to enable libguestfs verbose messages:
guestfs_set_verbose (g, 1);
That should dump everything to stderr, and with hivex debug you really
will get a very large amount of debugging info. If it hangs again,
let us know where (please file a bug with all the verbose output until
the hang).
What else would need changing to get more details generated
from guestfs_inspect_os->hivex_open?
If you were feeling very adventurous, you could run the "visualizer"
program from:
https://github.com/libguestfs/hivex/tree/master/lib/tools
That's the program I used when I was reverse-engineering the registry
format, and the source of the program has lots of useful information
about the format. However I don't think it will tell you anything
very interesting in this case.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
5:01 p.m.
New subject: inspect_os error with Win7 image
It's possible we could add a HIVEX_OPEN_FIXUP flag or something
like
that. In this case (empty hbins) it would probably be safe, but I'd
worry about trying to "fix" more egregious registry errors,
particularly since we don't fully understand the format.
That would be very useful... with obvious caveats.
You'll also need to enable libguestfs verbose messages:
guestfs_set_verbose (g, 1);
That should dump everything to stderr, and with hivex debug you really
will get a very large amount of debugging info. If it hangs again,
let us know where (please file a bug with all the verbose output until
the hang).
But report filed.
If you were feeling very adventurous, you could run the
"visualizer"
program from:
That does appear adventurous! ;) Who know. Maybe...
Thanks for the help.
2:16 a.m.
New subject: inspect_os error with Win7 image
On Mon, Dec 17, 2012 at 06:01:14PM -0500, Skippy VonDrake wrote:
> You'll also need to enable libguestfs verbose messages:
>
> guestfs_set_verbose (g, 1);
>
> That should dump everything to stderr, and with hivex debug you really
> will get a very large amount of debugging info. If it hangs again,
> let us know where (please file a bug with all the verbose output until
> the hang).
Bug report filed.
OK, but this is not the bug I'm interested in.
The bug filed:
https://bugzilla.redhat.com/show_bug.cgi?id=888059
is caused by the registry being faulty:
hivex: /sysroot/Windows/System32/config/SOFTWARE: trailing garbage at end of file (at
0x245b000, after 8557 pages)
which is fixed upstream already.
The bug I'm interested in is if libguestfs hangs when you enable
debugging in hivex.
A feature for hivex to be more tolerant of faulty registries should be
filed with 'RFE' in the subject against the 'hivex' component.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
9:32 a.m.
New subject: inspect_os error with Win7 image
> Bug report filed.
OK, but this is not the bug I'm interested in.
The bug filed:
https://bugzilla.redhat.com/show_bug.cgi?id=888059
is caused by the registry being faulty:
hivex: /sysroot/Windows/System32/config/SOFTWARE: trailing garbage at end of file (at
0x245b000, after 8557 pages)
which is fixed upstream already.
The bug I'm interested in is if libguestfs hangs when you enable
debugging in hivex.
I see. Sorry for the confusion.
A feature for hivex to be more tolerant of faulty registries should
be
filed with 'RFE' in the subject against the 'hivex' component.
OK. Did that. Thanks again.
10:18 a.m.
New subject: inspect_os error with Win7 image
On Tue, Dec 18, 2012 at 10:32:47AM -0500, Skippy VonDrake wrote:
>> Bug report filed.
>
> OK, but this is not the bug I'm interested in.
>
> The bug filed:
> https://bugzilla.redhat.com/show_bug.cgi?id=888059
> is caused by the registry being faulty:
> hivex: /sysroot/Windows/System32/config/SOFTWARE: trailing garbage at end of file
(at 0x245b000, after 8557 pages)
> which is fixed upstream already.
>
> The bug I'm interested in is if libguestfs hangs when you enable
> debugging in hivex.
I see. Sorry for the confusion.
> A feature for hivex to be more tolerant of faulty registries should be
> filed with 'RFE' in the subject against the 'hivex' component.
OK. Did that. Thanks again.
Thanks, it's sorted out now.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
4171
days inactive
4172
days old
4 comments
2 participants
participants (2)
-
Richard W.M. Jones -
Skippy VonDrake