Bug 1890478
| Summary: | inspect_os raised a Hivex.Error | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Community] Virtualization Tools | Reporter: | zhang yuxing <zyx1069958401> | ||||||||||
| Component: | hivex | Assignee: | Richard W.M. Jones <rjones> | ||||||||||
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||
| Priority: | unspecified | ||||||||||||
| Version: | unspecified | CC: | mhicks, ptoscano, rjones | ||||||||||
| Target Milestone: | --- | ||||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | aarch64 | ||||||||||||
| OS: | Unspecified | ||||||||||||
| Whiteboard: | |||||||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2020-10-23 06:27:35 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: | |||||||||||||
| Attachments: |
|
||||||||||||
|
Description
zhang yuxing
2020-10-22 11:14:44 UTC
Can you try the following, hopefully they will reveal more information
about what is wrong with the registry:
><fs> download /Windows/System32/config/SOFTWARE /tmp/software
><fs> download /Windows/System32/config/SYSTEM /tmp/system
And then in the regular shell:
$ hivexml /tmp/software > /tmp/software.xml
$ hivexml /tmp/system > /tmp/system.xml
In particular see if hivexml prints any error messages.
If you can't see what's going on then attach /tmp/software and /tmp/system
to this bug, marked as private attachments.
Created attachment 1723500 [details]
download from /Windows/System32/config/SYSTEM
I tried these commands. ><fs> download /Windows/System32/config/SOFTWARE /tmp/software libguestfs: trace: download "/Windows/System32/config/SOFTWARE" "/tmp/software" guestfsd: => ll (0x5) took 0.02 secs guestfsd: <= download (0x43) request length 80 bytes commandrvf: stdout=n stderr=y flags=0x0 commandrvf: udevadm --debug settle -E /Windows/System32/config/SOFTWARE Unknown filesystem type 62656572 mounted on /sys/fs/cgroup. commandrvf: stdout=n stderr=y flags=0x0 commandrvf: udevadm --debug settle -E /Windows/System32/config/SOFTWARE Unknown filesystem type 62656572 mounted on /sys/fs/cgroup. guestfsd: => download (0x43) took 0.49 secs libguestfs: trace: download = 0 ><fs> download /Windows/System32/config/SYSTEM /tmp/system libguestfs: trace: download "/Windows/System32/config/SYSTEM" "/tmp/system" guestfsd: <= download (0x43) request length 76 bytes commandrvf: stdout=n stderr=y flags=0x0 commandrvf: udevadm --debug settle -E /Windows/System32/config/SYSTEM Unknown filesystem type 62656572 mounted on /sys/fs/cgroup. commandrvf: stdout=n stderr=y flags=0x0 commandrvf: udevadm --debug settle -E /Windows/System32/config/SYSTEM Unknown filesystem type 62656572 mounted on /sys/fs/cgroup. libguestfs: trace: download = 0 And then the reguler shell reveals: [root@xxx src]# hivexml /tmp/software > /tmp/software.xml hivex_visit: /tmp/software: Bad file descriptor [root@xxx src]# hivexml /tmp/system > /tmp/system.xml hivex_visit: /tmp/system: Bad file descriptor There seems to be a problem with the encoding format of the file. And I submitted the software document. File system is too large to upload. I'm not able to reproduce any problem with the system hive that you attached. You could compress the software hive before attaching it. Created attachment 1723515 [details]
download from /Windows/System32/config/SYSTEM and /SOFTWARE
There doesn't seem to be anything wrong with the hives themselves. However: $ hivexml software > /tmp/software.xml $ hivexml system > /tmp/system.xml I do not see the "Bad file descriptor" errors, so I guess that might be related to this problem. Where did you get hivex from? I guess it's the same problem, so I tried to get hivex from https://download.libguestfs.org/hivex/ to compile it manually. But the following error occurred when I run the make command. Making all in images make[2]: Entering directory '/root/hivex-1.3.19/images' CC mklarge-mklarge.o CCLD mklarge cmp -s ./minimal ./minimal || \ cp ./minimal ./minimal ./mklarge ./minimal ./large mklarge: hivex_node_add_child: Invalid argument make[2]: *** [Makefile:1749: large] Error 1 make[2]: Leaving directory '/root/hivex-1.3.19/images' make[1]: *** [Makefile:1611: all-recursive] Error 1 make[1]: Leaving directory '/root/hivex-1.3.19' make: *** [Makefile:1518: all] Error 2 As always, I need to see the full log from the configure && make in order to say anything useful. Created attachment 1723532 [details]
configure and make hivex
There's something very odd going on with the development environment. I cannot reproduce anything like this error on Fedora/aarch64. Can you try: $ HIVEX_DEBUG=1 ./images/mklarge images/minimal images/large This will produce a lot of debug output which is useful to see, completely. You could also try: $ valgrind ./images/mklarge images/minimal images/large in order to see if the binary or library has been built incorrectly. Also please answer some of the previous questions about this environment. What is the hardware? Operating system? Where did the original hivex come from? [root@dataenableengine-server-0 hivex-1.3.19]# HIVEX_DEBUG=1 ./images/mklarge images/minimal images/large
hivex: hivex_open: created handle 0x2a01d260
hivex_open: header fields:
file version 1.5
sequence nos 256 256
(sequences nos should match if hive was synched at shutdown)
last modified 129095917722700000
(Windows filetime, x 100 ns since 1601-01-01)
original file name (conversion failed)
(only 32 chars are stored, name is probably truncated)
root offset 0x20 + 0x1000
end of last page 0x1000 + 0x1000 (total file size 0x2000)
checksum 0xfa3859bf (calculated 0xfa3859bf)
hivex: hivex_open: root offset = 0x1020
hivex: hivex_open: page at 0x1000, size 4096
hivex: hivex_open: used block id 110,107 (nk) at 0x1020 size 96 (root)
hivex: hivex_open: used block id 115,107 (sk) at 0x1080 size 312
hivex: hivex_open: free block id 0,0 (..) at 0x11b8 size 3656
hivex: hivex_open: successfully read Windows Registry hive file:
pages: 1 [sml: 4096, lge: 4096]
blocks: 3 [sml: 96, avg: 1354, lge: 3656]
blocks used: 2
bytes used: 408
hivex: hivex_node_add_child: returning EINVAL because: malformed name
mklarge: hivex_node_add_child: Invalid argument
The EulerOS aarch64 is used. The Hivex package is obtained from the open source community.
I tried to compile hivex on another computer and found that the compilation was successful, but the hivexml binary file was missing. The attachment has been uploaded.
Created attachment 1723548 [details]
hivex
So this is very good information, I think we are starting to get to the bottom of the problem: > hivex: hivex_node_add_child: returning EINVAL because: malformed name https://github.com/libguestfs/hivex/blob/1bb4b0fd05f316e029760d1efd6b7ee97020ae82/lib/write.c#L615 This must happen because the previous call to _hivex_encode_string failed: https://github.com/libguestfs/hivex/blob/1bb4b0fd05f316e029760d1efd6b7ee97020ae82/lib/utf16.c#L94 You might want to try adding some debugging prints to that function and also _hivex_recode to see if you can narrow down the problem. It might be because of your locale settings? Or iconv is broken in some way? This seems to work for me. My local time is already very late, I will check the issue tomorrow and thanks again for your help! This is the source of my hivex package https://repo.openeuler.org/openEuler-20.03-LTS/everything/aarch64/Packages/hivex-1.3.17-2.oe1.aarch64.rpm Hello, Mr. Rich. Your last comment is correct. I upgraded the glibc-common software package in the container. The iconv contained in the package can solve the Hivex.Error problem. Thank you very much for your help. I will try to write a demo program for the umount_local() problem mentioned in the previous email. Thank you again for your help! |