Bug 2387829 - FedoraLinux-42 for WSL is not detecting CPU Architecture
Summary: FedoraLinux-42 for WSL is not detecting CPU Architecture
Keywords:
Status: CLOSED DUPLICATE of bug 2386266
Alias: None
Product: Fedora
Classification: Fedora
Component: wsl-setup
Version: 42
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Jeremy Cline
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2025-08-12 13:25 UTC by Phil Dudley
Modified: 2025-08-12 19:49 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2025-08-12 19:49:38 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Phil Dudley 2025-08-12 13:25:39 UTC
When I attempt to use certain applications, like go-task, it says that it cannot determine the CPU Architecture. When I run uname -p I receive "unknown"

Reproducible: Always

Steps to Reproduce:
1. sudo dnf install --assumeyes go-task
2. sh -c go-task --list
3. receive error
Actual Results:
```bash
$ task --list
/usr/bin/go-task: line 1: syntax error near unexpected token `newline'
/usr/bin/go-task: line 1: `!<arch>'
```

Expected Results:
a list of tasks in the Taskfile.yaml

Additional Information:
```powershell
> wsl --version
WSL version: 2.5.10.0
Kernel version: 6.6.87.2-1
WSLg version: 1.0.66
MSRDC version: 1.2.6074
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.22631.5624
```

```bash
$ uname -p
unknown

$ cat /etc/os-release
NAME="Fedora Linux"
VERSION="42 (WSL)"
RELEASE_TYPE=stable
ID=fedora
VERSION_ID=42
VERSION_CODENAME=""
PLATFORM_ID="platform:f42"
PRETTY_NAME="Fedora Linux 42 (WSL)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:42"
DEFAULT_HOSTNAME="fedora"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f42/system-administrators-guide/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=42
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=42
SUPPORT_END=2026-05-13
VARIANT="WSL"
VARIANT_ID=wsl
```

Comment 1 Phil Dudley 2025-08-12 13:32:49 UTC
I didn't see a spot to upload my journalctl -b output. I have it, just cannot upload it.

Comment 2 Jeremy Cline 2025-08-12 14:21:28 UTC
Hey Phil,

Thanks for the report. Interestingly, this isn't WSL-specific and `uname -p` reports unknown on both Fedora Workstation and a Debian Trixie container. It's properly reported in Ubuntu 24.04 containers so my first guess is this is a coreutils bug introduced between 9.3 and 9.6. Running `strace uname -p` shows it never even calls `uname(2)`:

❯ strace uname -p
execve("/usr/bin/uname", ["uname", "-p"], 0x7fff83b9b7c8 /* 61 vars */) = 0
brk(NULL)                               = 0x556c6761b000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f5883027000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=103907, ...}) = 0
mmap(NULL, 103907, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f588300d000
close(3)                                = 0
openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\00007\0\0\0\0\0\0"..., 832) = 832
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784
fstat(3, {st_mode=S_IFREG|0755, st_size=2443336, ...}) = 0
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784
mmap(NULL, 2034736, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f5882e1c000
mmap(0x7f5882f8a000, 479232, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16e000) = 0x7f5882f8a000
mmap(0x7f5882fff000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e2000) = 0x7f5882fff000
mmap(0x7f5883005000, 31792, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f5883005000
close(3)                                = 0
mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f5882e19000
arch_prctl(ARCH_SET_FS, 0x7f5882e19740) = 0
set_tid_address(0x7f5882e19a10)         = 42812
set_robust_list(0x7f5882e19a20, 24)     = 0
rseq(0x7f5882e19680, 0x20, 0, 0x53053053) = 0
mprotect(0x7f5882fff000, 16384, PROT_READ) = 0
mprotect(0x556c4c01c000, 4096, PROT_READ) = 0
mprotect(0x7f5883065000, 8192, PROT_READ) = 0
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
munmap(0x7f588300d000, 103907)          = 0
getrandom("\x17\x85\xa2\x06\x35\x90\xab\x62", 8, GRND_NONBLOCK) = 8
brk(NULL)                               = 0x556c6761b000
brk(0x556c6763c000)                     = 0x556c6763c000
openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=233242544, ...}) = 0
mmap(NULL, 233242544, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f5874e00000
close(3)                                = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x1), ...}) = 0
write(1, "unknown\n", 8unknown
)                = 8
close(1)                                = 0
close(2)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++

But it's not like `uname(2)` is broken since the following program works:

dev in ~/tmp via C v15.1.1-gcc 
❯ cat test.c 
#include <stdio.h>
#include <sys/utsname.h>

int main () {
	struct utsname details;
	
	int ret = uname(&details);
	if (ret != 0)
		return ret;

	printf("Detected arch %s", details.machine);
	return 0;
}

dev in ~/tmp via C v15.1.1-gcc
❯ ./test
Detected arch x86_64⏎

Comment 3 Jeremy Cline 2025-08-12 14:37:32 UTC
I'm still waiting for the coreutils repository to clone, but looking at the manual page, `uname` has a `-m` option that prints the architecture, and `-p` says "print the processor type (non-portable)". Maybe non-portable is code for "just prints unknown" since -m works. It's possible `go-task` needs a fix to use -m.

Comment 4 Phil Dudley 2025-08-12 14:42:57 UTC
I wheeled over to my Fedora Silverblue/Kinote installs, and they also give an unknown result with uname -p and the x86_64 with uname -m. 

I don't know much about go-task under the surface.

Comment 5 Jeremy Cline 2025-08-12 14:52:25 UTC
Okay, so the issue with go-task has been fixed in https://bodhi.fedoraproject.org/updates/FEDORA-2025-585cfc0d61.

Looking at the coreutils code, it'll print unknown for `-p` in most cases. I've not unpacked all the #ifdefs but yeah, things should just use `-m` it seems.

Comment 6 Phil Dudley 2025-08-12 14:53:57 UTC
I'll make a backup of my WSLv2 Distribution and give this a try.

Comment 7 Phil Dudley 2025-08-12 14:59:23 UTC
Made a backup, and ran the command in the linked page you gave. Nothing happened.

```bash
➜  ~
sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-585cfc0d61
Updating and loading repositories:
 Fedora 42 openh264 (From Cisco) - x86_64                                                                                                                                                                                                                                           100% |   4.8 KiB/s | 986.0   B |  00m00s
 Fedora 42 - x86_64 - Updates                                                                                                                                                                                                                                                       100% | 129.8 KiB/s |  30.8 KiB |  00m00s
 Fedora 42 - x86_64                                                                                                                                                                                                                                                                 100% | 149.4 KiB/s |  31.5 KiB |  00m00s
 Hashicorp Stable - x86_64                                                                                                                                                                                                                                                          100% |  14.2 KiB/s |   1.5 KiB |  00m00s
 Fedora 42 - x86_64 - Test Updates                                                                                                                                                                                                                                                  100% |   1.6 MiB/s | 930.3 KiB |  00m01s
Repositories loaded.
Nothing to do.
```

Comment 8 Jeremy Cline 2025-08-12 15:04:39 UTC
Weird. It sure doesn't do anything. I'll go chase that down separately, I suppose.

You can run this instead: `sudo dnf upgrade --enablerepo=updates-testing go-task`

Comment 9 Phil Dudley 2025-08-12 15:16:25 UTC
(In reply to Jeremy Cline from comment #8)
> Weird. It sure doesn't do anything. I'll go chase that down separately, I
> suppose.
> 
> You can run this instead: `sudo dnf upgrade --enablerepo=updates-testing
> go-task`

That did update to a newer version and go-task did work as intended.

```bash
➜  ~
sudo dnf upgrade --enablerepo=updates-testing go-task
Updating and loading repositories:
Repositories loaded.
Package                                                                                                       Arch                   Version                                                                                                       Repository                                                           Size
Upgrading:
 go-task                                                                                                      x86_64                 3.44.1-3.fc42                                                                                                 updates-testing                                                  18.8 MiB
   replacing go-task                                                                                          x86_64                 3.44.1-2.fc42                                                                                                 updates                                                           2.6 MiB

Transaction Summary:
 Upgrading:          1 package
 Replacing:          1 package

Total size of inbound packages is 6 MiB. Need to download 6 MiB.
After this operation, 16 MiB extra will be used (install 19 MiB, remove 3 MiB).
Is this ok [y/N]: y
[1/1] go-task-0:3.44.1-3.fc42.x86_64                                                                                                                                                                                                                                                100% |   6.9 MiB/s |   5.5 MiB |  00m01s
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[1/1] Total                                                                                                                                                                                                                                                                         100% |   5.3 MiB/s |   5.5 MiB |  00m01s
Running transaction
[1/4] Verify package files                                                                                                                                                                                                                                                          100% |  66.0   B/s |   1.0   B |  00m00s
[2/4] Prepare transaction                                                                                                                                                                                                                                                           100% |  76.0   B/s |   2.0   B |  00m00s
[3/4] Upgrading go-task-0:3.44.1-3.fc42.x86_64                                                                                                                                                                                                                                      100% | 184.1 MiB/s |  18.8 MiB |  00m00s
[4/4] Removing go-task-0:3.44.1-2.fc42.x86_64                                                                                                                                                                                                                                       100% |  90.0   B/s |   6.0   B |  00m00s
Complete!
➜  ~
task
file does not exist
➜  ~
task --help
Usage: task [flags...] [task...]

Runs the specified task(s). Falls back to the "default" task if no task name
was specified, or lists all tasks if an unknown task name was specified.

Example: 'task hello' with the following 'Taskfile.yml' file will generate an
'output.txt' file with the content "hello".

'''
version: '3'
tasks:
  hello:
    cmds:
      - echo "I am going to write a file named 'output.txt' now."
      - echo "hello" > output.txt
    generates:
      - output.txt
'''

Options:
  -c, --color                       Colored output. Enabled by default. Set flag to false or use NO_COLOR=1 to disable. (default true)
      --completion string           Generates shell completion script.
  -C, --concurrency int             Limit number of tasks to run concurrently.
  -d, --dir string                  Sets the directory in which Task will execute and look for a Taskfile.
  -n, --dry                         Compiles and prints tasks in the order that they would be run, without executing them.
  -x, --exit-code                   Pass-through the exit code of the task command.
      --experiments                 Lists all the available experiments and whether or not they are enabled.
  -f, --force                       Forces execution even when the task is up-to-date.
  -g, --global                      Runs global Taskfile, from $HOME/{T,t}askfile.{yml,yaml}.
  -h, --help                        Shows Task usage.
  -i, --init                        Creates a new Taskfile.yml in the current folder.
      --insecure                    Forces Task to download Taskfiles over insecure connections.
  -I, --interval duration           Interval to watch for changes.
  -j, --json                        Formats task list as JSON.
  -l, --list                        Lists tasks with description of current Taskfile.
  -a, --list-all                    Lists tasks with or without a description.
      --no-status                   Ignore status when listing tasks as JSON
  -o, --output string               Sets output style: [interleaved|group|prefixed].
      --output-group-begin string   Message template to print before a task's grouped output.
      --output-group-end string     Message template to print after a task's grouped output.
      --output-group-error-only     Swallow output from successful tasks.
  -p, --parallel                    Executes tasks provided on command line in parallel.
  -s, --silent                      Disables echoing.
      --sort string                 Changes the order of the tasks when listed. [default|alphanumeric|none].
      --status                      Exits with non-zero exit code if any of the given tasks is not up-to-date.
      --summary                     Show summary about a task.
  -t, --taskfile string             Choose which Taskfile to run. Defaults to "Taskfile.yml".
  -v, --verbose                     Enables verbose mode.
      --version                     Show Task version.
  -w, --watch                       Enables watch of the given task.
  -y, --yes                         Assume "yes" as answer to all prompts.
```

Comment 10 Jeremy Cline 2025-08-12 19:49:38 UTC
Great, I appreciate you testing that out. Based on my reading, `uname -p` is "working" as intended (although it is weird, and I'm sure there's some terrifying history behind why it is the way it is), so I'm marking this as a duplicate of the go-task bug. Thanks again for taking the time to report the issue.

*** This bug has been marked as a duplicate of bug 2386266 ***


Note You need to log in before you can comment on or make changes to this bug.