Bug 2387829
| Summary: | FedoraLinux-42 for WSL is not detecting CPU Architecture | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Phil Dudley <Predatorian3> |
| Component: | wsl-setup | Assignee: | Jeremy Cline <jeremy> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 42 | CC: | cloud-sig, jeremy, tdawson |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | --- | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2025-08-12 19:49:38 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Phil Dudley
2025-08-12 13:25:39 UTC
I didn't see a spot to upload my journalctl -b output. I have it, just cannot upload it. 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⏎
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. 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. 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. I'll make a backup of my WSLv2 Distribution and give this a try. 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. ``` 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` (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. ``` 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 *** |