[distrobox] Run in Vanilla OS: fatal--not-a-git-repository--or-any-of-the-parent-directories----git-

[davidas13]

I tried to install on vanilla OS but something like this appears when I first run on the console:

Expected: username@vanilla ~ >

Current: Displays the following error username@vanilla ~ | fatal--not-a-git-repository--or-any-of-the-parent-directories----git-X >

But if you enter container mode it looks normal

What should I do to make it look normal?

[akinomyoga]

I'm not sure what is going on there, but what is the output of the following command in your home directory (~)?

$ command git symbolic-ref -q HEAD 2>/dev/null

[tamsyn548]

i have exactly the same issue..:(

[tamsyn548]

I'm not sure what is going on there, but what is the output of the following command in your home directory (~)?

$ command git symbolic-ref -q HEAD 2>/dev/null

[akinomyoga]

Thank you for the result of the command. This means that in your environment, the command outputs the error messages to stdout (1) instead of stderr (2). Or another possibility might be that /dev/null is actually connected to stdout.

[akinomyoga]

Could you also check the result of the following command?

$ echo test >/dev/null

[akinomyoga]

I tried the latest version of Vanilla OS Live Media, but the problem doesn't seem to be reproduced. Now I'm trying to install it in VirtualBox.

[akinomyoga]

I set up Vanilla OS and could reproduce the problem. I have installed git through apx install git. This creates a file at ~/.local/bin/git, but the file is actually a shell script to run the git command in some environment:

#!/bin/sh
# distrobox_binary
# name: apx_managed
if [ ! -f /run/.containerenv ] && [ ! -f /.dockerenv ]; then
        command="/usr/lib/apx/distrobox-enter  -n apx_managed --  /usr/bin/git  "
        for arg in "$@"; do
                if echo "${arg}" | grep -Eq "'|\""; then
                        command="${command} \
                                $(echo "${arg}" | sed 's|\\|\\\\|g' |
                                sed 's| |\\ |g' |
                                sed 's|\$|\\\$|g' |
                                sed "s|'|\\\'|g" |
                                sed 's|"|\\\"|g')"
                elif echo "${arg}" | grep -q "'"; then
                        command="${command} \"${arg}\""
                else
                        command="${command} '${arg}'"
                fi
        done
        eval ${command}
else
        /usr/bin/git "$@"
fi

The problem seems to be that stdout and stderr are combined in stdout by distrobox-enter

$ /usr/lib/apx/distrobox-enter -n apx_managed -- /usr/bin/bash -c 'echo hello >&2' >| stdout 2>| stderr
$ head stdout stderr
==> stdout <==
hello

==> stderr <==
$

The content originally written to stderr inside distrobox is redirected to stdout.

I believe this should be considered a bug of apx/distrobox.

[akinomyoga]

In Vanilla OS, distrobox-enter runs the command using podman exec.

The reason that stderr and stdout are merged into stdout seems to be that distrobox-enter passes the option --tty to podman exec, so podman creates an independent TTY and run the command inside the TTY. Because stderr and stdout are both connected to the TTY, the outputs to two streams are mixed. After that the TTY redirects the received data to the original stdout.

It seems that stdout and stderr will not mix if we do not pass --tty to podman exec. The distrobox-enter command accepts an option -T to do that. However, the call of distrobox-enter is hardcoded in ~/.local/bin/git, so there is no way to specify it to distribox-enter for the execution of git unless we directly edit ~/.local/bin/git.

Even when we decided to edit ~/.local/bin/git, we sometimes need -T and sometimes should not specify -T (e.g. when a TUI editor needs to be called to edit the commit message). It could be non-trivial to automatically decide whether to specify -T or not. Maybe we could test whether stdout is connected to a TTY or not.

However, when we need the TTY but the command can also fail, there seems to be no solution to the problem. If we specify -T, the text editor fails. If we do not specify -T, there is no way to distinguish error messages (stderr) from the output (stdout).

[akinomyoga]

Now I have general doubts about the overall design of the execution model adopted by Vanilla OS. With the current model, every execution of the commands installed in the user directory is done within an independent TTY, which means that it is impossible to run commands (installed in the user directory) in the current session.

I have also checked the implementations of distrobox-enter and distrobox-export, but these scripts are obviously written by beginners and have many security issues. I have submitted a few PRs (https://github.com/89luca89/distrobox/pull/697, https://github.com/89luca89/distrobox/pull/698, https://github.com/89luca89/distrobox/pull/699) to distrobox, but there are still many other issues in these scripts.

I have to say that this operating system is broken in many ways at the current stage.

[akinomyoga]

The only solution is to remove git in the user directory and install git in the host system using abroot.

$ apx remove git
$ sudo abroot exec apt install git
$ sudo reboot

[AlbertoFabbri93]

I have the same problem with OpenSuse Aeon (it also uses distrobox).

I changed to the theme "agnoster" which does not print the error (but it has other issues).

[akinomyoga]

What is the version of your distrobox? My patches seem to be applied to distrobox-1.5.0.

[AlbertoFabbri93]

I am using distrobox: 1.5.0.2

[akinomyoga]

Ah, OK. I've again read my replies to remember what has been the problem. The problem is not related to my patches but is related to the design of Distrbox executing commands with an independent TTY. This means that stdout and stderr of the command are not preserved separately. As far as Distrobox is used, it is impossible to separate the outputs to the original stdout and stderr.

This seems to be the design bug of Distrobox. We might have checked the output of the git command for every possible error message to judge whether it originated from stderr, but I wouldn't like to rely on such an unstable assumption about the detailed messages and wouldn't like to carry the database of error messages just for a bug of a specific framework.

[AlbertoFabbri93]

Did you file the issue with Distrobox? Maybe they can fix this upstream...

[akinomyoga]

No, I haven't. Actually, I don't have an idea if it is even possible to fix it, but maybe they have an idea. I don't usually use Distrobox and am unfamiliar with it, so maybe there could be a way to configure it properly. I can investigate whether there is an existing solution, and if I can't find any, I can ask upstream. Or if you are familiar with the detailed configurations and setups of Distrobox, could you instead summarize and report the issue to the upstream?

[AlbertoFabbri93]

I am very very new to Linux, I installed it 3 days ago so I think it is better if you file the issue. I am learning a lot of new things and if I found out something new I will report it here but I am very much a noob :)

[akinomyoga]

I see. Thanks for the reply. I'm not either a user of OpenSuse Aeon or Vanilla OS, so I also need to take time to understand the whole structure of the operating systems and who is responsible for the specific parts of the operating system. Actually, this matter of TTY might not be the one Distrobox is responsible for. Maybe some other people who configure the Distrobox settings could be responsible. Anyway, it might take time to check it.

If you are new to Linux, maybe OpenSuse Aeon might not be a good choice unless you are forced to do so for another reason. In my view, Vanilla OS and a system based on Distrobox seem to have not yet been sophisticated very well and are effectively still in the experimental stage. Also, it is not a common and typical setup of Linux, so I'm not sure if it is useful for learners.

[AlbertoFabbri93]

Thank you very much for sharing your opinion! Very interesting!

I agree with most of what you said but I chose Aeon for mainly two reasons:

• I want an OS that is as stable as possible yet as updated as possible. And my personal opinion is that an immutable rolling distro like Aeon should be able to provide both without things breaking as much as for example Arch. I like the idea of immutable systems because they are locked down and should prevent me from doing stupid things, I can not afford to break my OS... I only have 1 PC.
• I really like to use containers, on Windows I was using them as much as possible with WSL and Docker but, the experience is extremely frustrating because everything is so slow. Aeon offers podman and distrobox out of the box so they are very well supported and super fast!

I have to say that right now my experience has been very positive, most of the things worked right away and I did not have to spend much time making the hardware work. I know that immutable distros are harder to customize but I think that for now giving up on that front is worth all the other advantages I get.

I hope this makes sense!

[AlbertoFabbri93]

I see. Thanks for the reply. I'm not either a user of OpenSuse Aeon or Vanilla OS, so I also need to take time to understand the whole structure of the operating systems and who is responsible for the specific parts of the operating system. Actually, this matter of TTY might not be the one Distrobox is responsible for. Maybe some other people who configure the Distrobox settings could be responsible. Anyway, it might take time to check it.

I completely understand and if you have any question or I can help in any way feel free to ping me. It would be nice to resolve this issue once and for all.

[akinomyoga]

I was wondering why Distrobox creates an independent TTY so checked the Distrobox page again. Maybe Distrobox is not primarily designed for exporting the commands inside containers as independent commands. Then, maybe we could just specify the option --no-tty for the commands exported by distrobox-export.

I have a question. What is the current content of your git command? Your git commands is supposed to be replaced by a shell script generated by distrobox-export and is probably located in ~/.local/bin/git. What are the results of the following commands?

$ type -p git
$ cat "$(type -p git)"     # If it is a shell script (not binary)

[AlbertoFabbri93]

$ type -p git

/home/albi/.local/bin/git

$ cat "$(type -p git)" # If it is a shell script (not binary)

#!/bin/sh
# distrobox_binary
# name: atools
if [ -z "${CONTAINER_ID}" ]; then
    exec /usr/bin/distrobox-enter  -n atools --          /usr/bin/git  "$@"
else
    exec /usr/bin/git "$@"
fi

[akinomyoga]

Thank you.

What I would like to ask you to check is whether the problems reported here and #464 are solved by rewriting ~/.local/bin/git as follows (please notice that an option --no-tty is added to dropbox-enter):

#!/bin/sh
# distrobox_binary
# name: atools
if [ -z "${CONTAINER_ID}" ]; then
    exec /usr/bin/distrobox-enter --no-tty -n atools -- /usr/bin/git  "$@"
else
    exec /usr/bin/git "$@"
fi

[AlbertoFabbri93]

Yes, this resolves both problems! Awesome!

[akinomyoga]

Thanks for trying! Then, I may ask Dropbox whether it makes sense to make --no-tty default for the scripts generated by distrobox-export (Note: e.g., ~/.local/bin/git is generated by distrobox-export).

[AlbertoFabbri93]

Yes, I think it makes sense.

The command used for binary files like git is distrobox-export --bin.

[AlbertoFabbri93]

Thanks for trying! Then, I may ask Dropbox whether it makes sense to make --no-tty default for the scripts generated by distrobox-export (Note: e.g., ~/.local/bin/git is generated by distrobox-export).

Hi @akinomyoga, did you file a bug with Distrobox? If yes, can you share the link?

[akinomyoga]

Sorry, I'm now busy and haven't reported it in Distrobox.

[akinomyoga]

Thank you for creating an Issue in the upstream Distrobox!

[akinomyoga]

The problem has been fixed in the upstream Distrobox https://github.com/89luca89/distrobox/issues/965. It should be applied to the next release of Distrobox. Let me close the issue. Thank you for your reports!