Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

V3 non-ansi paths installation support #68

Closed
Domduv opened this issue Dec 19, 2018 · 6 comments
Closed

V3 non-ansi paths installation support #68

Domduv opened this issue Dec 19, 2018 · 6 comments

Comments

@Domduv
Copy link

Domduv commented Dec 19, 2018

Hello,

I had an image that I could install on Windows 1709 with V2.
But since 1803 and V3, the same image does not work anymore.

After debugging some, it seems that the peculiarity of that image is that it has openssl-server installed, and this package installs certificates that use non ansi character, like Ü.
V2 was ignoring these characters, but V3 just exits on them (I get it's related to the switch to libarchive).

As a workaround, removing the certificates produces a working image, but I thought others might have the same issue

@DDoSolitary
Copy link
Owner

Couldn't reproduce. I can install Unicode images properly. Could you please provide the error message and the image that you're having trouble with so that I can find out what's wrong?

@Domduv
Copy link
Author

Domduv commented Dec 19, 2018

Thanks for the quick answer!

There is no error message, the installation just stops in the middle of the progress bar (and the resulting installation does not work, rootfs being far smaller than the tar file)

I put a test case here https://github.com/Domduv/test-LxRunOffline

Interesting that it works on your side...
It must be a problem on my side when using docker for toolbox to generate the image (it comes with a pretty old tar version 1.28 / 2014, that might explain the issue?)

@Domduv
Copy link
Author

Domduv commented Dec 19, 2018

BTW, some more precision

  • First I was mistaken, Ü works, but ğ does not (they're both part of the name of a turkish certificate, and Ü is in fact ANSI char 220).

  • The exit comes (at the root) from the function archive_string_append_from_wcs_in_codepage in libarchive, where I end up getting into the tp_cp == CP_C_LOCALE case.
    There, any non-ansi char will end up being translated as '?', and def_char being set to 1.
    archive_entry_symlink then detects the error code and return NULL.
    The returned value is used by writer.write_symlink, and this crashes because of the null pointer.

@DDoSolitary
Copy link
Owner

DDoSolitary commented Dec 19, 2018

I just tried your image and now I can reproduce it. It seems that libarchive returns the strings as-is by default but the image you provided has PAX headers so it is trying to perform some encoding conversion, which makes things broken. I'm still investigating.

@DDoSolitary
Copy link
Owner

Fixed. You can try the dev builds mentioned in README.

@Domduv
Copy link
Author

Domduv commented Dec 20, 2018

Hello,

this is indeed working now, thanks for the prompt fix!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants