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

Linux installers are not creating /etc/dotnet/install_location file #82858

Open
NikolaMilosavljevic opened this issue Mar 1, 2023 · 17 comments

Comments

@NikolaMilosavljevic
Copy link
Member

NikolaMilosavljevic commented Mar 1, 2023

It appears that Microsoft-built .NET installers, provided on https://packages.microsoft.com, are not creating /etc/dotnet/install_location file on Linux systems. The file gets created on OSX.

This causes issues for customers that want to customize the install location due to 1) missing file, and 2) default permissions for new file, created by customer.

.NET installer should create this file, according to design document: https://github.com/dotnet/designs/blob/main/accepted/2020/install-locations.md

@ghost ghost added the untriaged New issue has not been triaged by the area owner label Mar 1, 2023
@NikolaMilosavljevic
Copy link
Member Author

This should be backported to all supported releases.

@richlander
Copy link
Member

This is technically a breaking change, so we should document that.

@richlander
Copy link
Member

richlander commented Mar 1, 2023

What Ubuntu looks like:

$ docker run --rm -it  ubuntu:jammy
root@4da5efec1e6f:/# apt update && apt install -y dotnet6
root@4da5efec1e6f:/# ls /etc/dotnet
install_location  install_location_x64
root@4da5efec1e6f:/# cat /etc/dotnet/install_location
/usr/lib/dotnet
root@4da5efec1e6f:/# export | grep DOTNET
root@4da5efec1e6f:/#

@NikolaMilosavljevic
Copy link
Member Author

What Ubuntu looks like:

$ docker run --rm -it  ubuntu:jammy
root@4da5efec1e6f:/# apt update && apt install -y dotnet6
root@4da5efec1e6f:/# ls /etc/dotnet
install_location  install_location_x64
root@4da5efec1e6f:/# cat /etc/dotnet/install_location
/usr/lib/dotnet
root@4da5efec1e6f:/# export | grep DOTNET
root@4da5efec1e6f:/#

DEB packages built by Ubuntu and provided in Ubuntu feeds do have /etc/dotnet/install_location file. Packages built by Microsoft and provided on https://packages.microsoft.com do not. I've clarified the issue description.

@richlander
Copy link
Member

Exactly. That is what I meant, but didn't say. Thanks for clarifying.

Does our guidance cover this case?

@NikolaMilosavljevic
Copy link
Member Author

NikolaMilosavljevic commented Mar 2, 2023

Our packaging guidance (https://learn.microsoft.com/en-us/dotnet/core/distribution-packaging) has a section about this file:

(16) /etc/dotnet/install_location is a file that contains the full path for {dotnet_root}. The path may end with a newline. It's not necessary to add this file when the root is /usr/share/dotnet.

However, it does not require it, if .NET root is /usr/share/dotnet, which is considered a fallback location by the design doc:

Linux - the host searches in /usr/share/dotnet as a fallback, but the installer may pick a different default based on the requirements of the specific distro/configuration. In such case the install is effectively just like the global install to custom location described below. If correctly registered the host will search the custom location first.

The fix for this issue is likely not needed.

@mcallaghan-geotab
Copy link

mcallaghan-geotab commented Mar 6, 2023

If a system has migrated from Ubuntu distro package installation for dotnet, we found that /etc/dotnet/install_location(_x64) were still set to /usr/lib/dotnet ; but after using the Microsoft distribution package PMC ... this is now wrong because the installation directory should be /usr/share/dotnet.

A fix is required.

EDIT: NOTE: Not sure entirely what all will depend on this, but we found Rider IDE relies on it and thus doesn't function properly in this scenario/state.

@NikolaMilosavljevic
Copy link
Member Author

If a system has migrated from Ubuntu distro package installation for dotnet, we found that /etc/dotnet/install_location(_x64) were still set to /usr/lib/dotnet ; but after using the Microsoft distribution package PMC ... this is now wrong because the installation directory should be /usr/share/dotnet.

A fix is required.

This sounds like a "Mixed state scenario 2" from our Ubuntu guidance document: dotnet/core#7699. Switching from Ubuntu to Microsoft-built packages require complete uninstall of .NET related packages before installing packages from https://packages.microsoft.com. Uninstall would correctly remove /etc/dotnet/install_location(_x64) file(s).

@mcallaghan-geotab
Copy link

If a system has migrated from Ubuntu distro package installation for dotnet, we found that /etc/dotnet/install_location(_x64) were still set to /usr/lib/dotnet ; but after using the Microsoft distribution package PMC ... this is now wrong because the installation directory should be /usr/share/dotnet.
A fix is required.

This sounds like a "Mixed state scenario 2" from our Ubuntu guidance document: dotnet/core#7699. Switching from Ubuntu to Microsoft-built packages require complete uninstall of .NET related packages before installing packages from https://packages.microsoft.com. Uninstall would correctly remove /etc/dotnet/install_location(_x64) file(s).

did apt remove dotnet* aspnet* netstandard* - and re-installed .NET6 & .NET7 from PMC - install_location is wrong after that (x)

@mcallaghan-geotab
Copy link

mcallaghan-geotab commented Mar 6, 2023

is the recommendation to REMOVE these files, or ensure they point to /usr/share/dotnet when using Microsoft PMC?

either way the Microsoft package installers should probably be checking the system against whatever the requirement is

@NikolaMilosavljevic
Copy link
Member Author

NikolaMilosavljevic commented Mar 6, 2023

If a system has migrated from Ubuntu distro package installation for dotnet, we found that /etc/dotnet/install_location(_x64) were still set to /usr/lib/dotnet ; but after using the Microsoft distribution package PMC ... this is now wrong because the installation directory should be /usr/share/dotnet.
A fix is required.

This sounds like a "Mixed state scenario 2" from our Ubuntu guidance document: dotnet/core#7699. Switching from Ubuntu to Microsoft-built packages require complete uninstall of .NET related packages before installing packages from https://packages.microsoft.com. Uninstall would correctly remove /etc/dotnet/install_location(_x64) file(s).

did apt remove dotnet* aspnet* netstandard* - and re-installed .NET6 & .NET7 from PMC - install_location is wrong after that (x)

Thanks. I see the same issue on 22.04. It seems that Ubuntu-built .NET packages are not cleaning these files from the machine. This seems by design, as plain apt remove command does not remove configuration files, i.e. anything under /etc. To remove those, you'd run the command with --purge switch, i.e. apt remove --purge dotnet* aspnet* netstandard*. I'll update the guidance document.

@mcallaghan-geotab
Copy link

Beyond updating the guidance doc tho; Shouldn't the PMC packages also verify this state? (otherwise users will forever be plagued by this problem and likely we'll be spurring more github issue submissions in the future ...)

@mcallaghan-geotab
Copy link

Maybe also consider: https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-environment-variables#dotnet_root-dotnet_rootx86 (default location varies now on Linux)

@mcallaghan-geotab
Copy link

mcallaghan-geotab commented Mar 6, 2023

Also just found this ... finally figured out what was setting DOTNET_ROOT to the old path

$ grep DOTNET_ROOT /etc/profile.d/dotnet*
/etc/profile.d/dotnet.sh:export DOTNET_ROOT=/usr/lib/dotnet

EDIT: there is also some dotnet tool ENV var items in there ... here's a snip of the script that is left on a Ubuntu 22.04 system (after having installed the packages from Ubuntu package source)

$ cat /etc/profile.d/dotnet.sh

# Set location for AppHost lookup
export DOTNET_ROOT=/usr/lib/dotnet

# Add dotnet tools directory to PATH
DOTNET_TOOLS_PATH="$HOME/.dotnet/tools"
case "$PATH" in
    *"$DOTNET_TOOLS_PATH"* ) true ;;
    * ) PATH="$PATH:$DOTNET_TOOLS_PATH" ;;
esac

# Extract self-contained executables under HOME
# to avoid multi-user issues from using the default '/var/tmp'.
[ -z "$DOTNET_BUNDLE_EXTRACT_BASE_DIR" ] && export DOTNET_BUNDLE_EXTRACT_BASE_DIR="${XDG_CACHE_HOME:-"$HOME"/.cache}/dotnet_bundle_extract"

@NikolaMilosavljevic NikolaMilosavljevic added untriaged New issue has not been triaged by the area owner and removed untriaged New issue has not been triaged by the area owner labels Apr 25, 2023
@NikolaMilosavljevic
Copy link
Member Author

[Triage] @mirespace, this file should not be left on user's machine when .NET is uninstalled. Is this something that should be fixed in Ubuntu's .NET packages?

@mirespace
Copy link
Contributor

mirespace commented Sep 20, 2023

Hi @NikolaMilosavljevic ,

Using --purge, as you mentioned below, remove anything the dotnet{6,7} package installed under /etc directory.

Thanks. I see the same issue on 22.04. It seems that Ubuntu-built .NET packages are not cleaning these files from the machine. This seems by design, as plain apt remove command does not remove configuration files, i.e. anything under /etc. To remove those, you'd run the command with --purge switch, i.e. apt remove --purge dotnet* aspnet* netstandard*. I'll update the guidance document.

Just in case, I checked the steps you provided there, and they are working fine:

# Checking dotnet6 is not installed
root@Jdotnet:~# dpkg -l | grep dotnet
root@Jdotnet:~# 

# Installing dotnet6 on Jammy
root@Jdotnet:~# apt install dotnet6
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  aspnetcore-runtime-6.0 aspnetcore-targeting-pack-6.0 dotnet-apphost-pack-6.0 dotnet-host dotnet-hostfxr-6.0 dotnet-runtime-6.0 dotnet-sdk-6.0 dotnet-targeting-pack-6.0
  dotnet-templates-6.0 liblttng-ust-common1 liblttng-ust-ctl5 liblttng-ust1 netstandard-targeting-pack-2.1
The following NEW packages will be installed:
  aspnetcore-runtime-6.0 aspnetcore-targeting-pack-6.0 dotnet-apphost-pack-6.0 dotnet-host dotnet-hostfxr-6.0 dotnet-runtime-6.0 dotnet-sdk-6.0 dotnet-targeting-pack-6.0
  dotnet-templates-6.0 dotnet6 liblttng-ust-common1 liblttng-ust-ctl5 liblttng-ust1 netstandard-targeting-pack-2.1
0 upgraded, 14 newly installed, 0 to remove and 0 not upgraded.
Need to get 1853 kB/124 MB of archives.
After this operation, 454 MB of additional disk space will be used.
Do you want to continue? [Y/n] 
[...]

# Checking installation
root@Jdotnet:~# dotnet --info
.NET SDK (reflecting any global.json):
 Version:   6.0.122
 Commit:    dc5a76ad5c

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  22.04
 OS Platform: Linux
 RID:         ubuntu.22.04-x64
 Base Path:   /usr/lib/dotnet/sdk/6.0.122/

global.json file:
  Not found

Host:
  Version:      6.0.22
  Architecture: x64
  Commit:       4bb6dc195c

.NET SDKs installed:
  6.0.122 [/usr/lib/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.22 [/usr/lib/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.22 [/usr/lib/dotnet/shared/Microsoft.NETCore.App]

Download .NET:
  https://aka.ms/dotnet-download

Learn about .NET Runtimes and SDKs:
  https://aka.ms/dotnet/runtimes-sdk-info


# Checking configuration files under /etc
root@Jdotnet:~# find /etc -name "*dotnet*" 
/etc/profile.d/dotnet.sh
/etc/dotnet
root@Jdotnet:~# l /etc/dotnet
install_location  install_location_x64

# Removing dotnet6 
root@Jdotnet:~# apt remove --purge dotnet* aspnet* netstandard*
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
[...]
The following packages were automatically installed and are no longer required:
  liblttng-ust-common1 liblttng-ust-ctl5 liblttng-ust1
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
  aspnetcore-runtime-6.0* aspnetcore-targeting-pack-6.0* dotnet-apphost-pack-6.0* dotnet-host* dotnet-hostfxr-6.0* dotnet-runtime-6.0* dotnet-sdk-6.0* dotnet-targeting-pack-6.0*
  dotnet-templates-6.0* dotnet6* netstandard-targeting-pack-2.1*
0 upgraded, 0 newly installed, 11 to remove and 0 not upgraded.
After this operation, 453 MB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 104126 files and directories currently installed.)
Removing dotnet6 (6.0.122-0ubuntu1~22.04.1) ...
Removing dotnet-sdk-6.0 (6.0.122-0ubuntu1~22.04.1) ...
Removing aspnetcore-runtime-6.0 (6.0.122-0ubuntu1~22.04.1) ...
Removing aspnetcore-targeting-pack-6.0 (6.0.122-0ubuntu1~22.04.1) ...
Removing dotnet-apphost-pack-6.0 (6.0.122-0ubuntu1~22.04.1) ...
Removing dotnet-templates-6.0 (6.0.122-0ubuntu1~22.04.1) ...
Removing dotnet-runtime-6.0 (6.0.122-0ubuntu1~22.04.1) ...
Removing dotnet-hostfxr-6.0 (6.0.122-0ubuntu1~22.04.1) ...
Removing dotnet-host (6.0.122-0ubuntu1~22.04.1) ...
Removing dotnet-targeting-pack-6.0 (6.0.122-0ubuntu1~22.04.1) ...
Removing netstandard-targeting-pack-2.1 (6.0.122-0ubuntu1~22.04.1) ...
Processing triggers for man-db (2.10.2-1) ...
(Reading database ... 100800 files and directories currently installed.)
Purging configuration files for dotnet-host (6.0.122-0ubuntu1~22.04.1) ...

# Checking all configuration files are removed
root@Jdotnet:~# find /etc -name "*dotnet*"
root@Jdotnet:~#

The most relevant line there is Purging configuration files for dotnet-host (6.0.122-0ubuntu1~22.04.1) ..., thrown due to the use of the --purge flag, as you mentioned. The package behaves normally, following the use of apt.

I'm afraid that removing the configuration files under /etc without using --purge is a different request because it wouldn't follow the standards.

@NikolaMilosavljevic NikolaMilosavljevic removed the untriaged New issue has not been triaged by the area owner label Sep 26, 2023
@karim1safan
Copy link

Screenshot from 2024-06-29 05-15-40

Screenshot from 2024-06-29 03-40-18

I have everything installed [.Net Sdk v8 and .Net Runtime], but I face this problem when I press the Run button

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

No branches or pull requests

5 participants