uname has become less useful

nathanb · 2013-12-03 21:28:48

The uname command used to give me useful hardware information:

[nathanb@nathanb-box ~] uname -snrip
Linux nathanb-box 3.1.1-1-ARCH Intel(R) Xeon(R) CPU W3520 @ 2.67GHz GenuineIntel

Now, I got a new motherboard and processor, and not so much:

[nathanb@nathanb-box ~] uname -snrip
Linux nathanb-box 3.12.0-1-ARCH unknown unknown

I thought it might be related to the hw identifier database, but that seems fine:

[root@nathanb-box ~]# pacman -S hwids
warning: hwids-20130607-1 is up to date -- reinstalling

Obviously something recognizes this processor, since it shows up in dmesg:

[root@nathanb-box ~]# dmesg | grep Xeon
[    0.068103] smpboot: CPU0: Intel(R) Xeon(R) CPU E5-1620 0 @ 3.60GHz (fam: 06, model: 2d, stepping: 07)

(If I'm recalling correctly, and I may not be, the CPU actually has at least part of that identification information encoded in hardware anyway).

Is there something I can do to make uname become useful again?

skottish · 2013-12-03 21:50:34

A simple rebuild of coreutils fixes this. I'll file a bug report.

**EDIT**

I was mistaken on this. Sorry for the noise. Some info here by falconindy:

https://bugs.archlinux.org/task/37993?s … &closedto=

Last edited by skottish (2013-12-03 22:55:38)

WorMzy · 2013-12-03 23:02:31

nathanb wrote:

The uname command used to give me useful hardware information:
[nathanb@nathanb-box ~] uname -snrip
Linux nathanb-box 3.1.1-1-ARCH Intel(R) Xeon(R) CPU W3520 @ 2.67GHz GenuineIntel
Now, I got a new motherboard and processor, and not so much:
[nathanb@nathanb-box ~] uname -snrip
Linux nathanb-box 3.12.0-1-ARCH unknown unknown
I thought it might be related to the hw identifier database, but that seems fine:
[root@nathanb-box ~]# pacman -S hwids
warning: hwids-20130607-1 is up to date -- reinstalling
Obviously something recognizes this processor, since it shows up in dmesg:
[root@nathanb-box ~]# dmesg | grep Xeon
[    0.068103] smpboot: CPU0: Intel(R) Xeon(R) CPU E5-1620 0 @ 3.60GHz (fam: 06, model: 2d, stepping: 07)
(If I'm recalling correctly, and I may not be, the CPU actually has at least part of that identification information encoded in hardware anyway).
Is there something I can do to make uname become useful again?

You can rebuild it on your machine, with the patch applied. Here's the patch:
https://projects.archlinux.org/svntogit … 1c63395918

nathanb · 2013-12-04 03:08:11

Cool, thanks folks!

Is this the sort of thing which would be useful to put in the AUR? A version of uname with this patch applied?

WonderWoofy · 2013-12-04 03:49:40

@nathanb, no this is not the kind of thing that should be put in the AUR. Let things get sorted out properly by upstream or the Arch packager. Putting this in the AUR would result in an outdated and useless package as soon as a fix is pushed. Considering that it is part of both the [core] repo and base package group, I imagine this should be fixed somewhat quickly.

nathanb · 2013-12-04 03:59:06

@WonderWoofy, please see this discussion: http://lists.gnu.org/archive/html/bug-c … 00063.html

Looks like the upstream devs don't see this as something they're interested in fixing because uname is a common code base across multiple platforms and the fix is Linux-specific. Note that the discussion is from 2005, and the patch linked in the bug is from 2012.

In other words, I don't think this is going to get fixed as quickly as you think, or perhaps ever.

x33a · 2013-12-04 05:01:54

nathanb wrote:

Cool, thanks folks!
Is this the sort of thing which would be useful to put in the AUR? A version of uname with this patch applied?

Yes, but then you'll need to maintain a full version of coreutils just for a single patch. Maybe you can convince the maintainer of one of these packages to use the patch.

https://aur.archlinux.org/packages/coreutils-icp/

https://aur.archlinux.org/packages/coreutils-git/

nathanb · 2013-12-04 13:59:46

x33a wrote:

Maybe you can convince the maintainer of one of these packages to use the patch.

The reason the bug report that skottish filed was rejected is that Arch wants uname to be as close to upstream as possible....so I don't think I'd have much luck with that argument.

x33a wrote:

Yes, but then you'll need to maintain a full version of coreutils just for a single patch. Maybe you can convince the maintainer of one of these packages to use the patch.

I don't know much about AUR, so excuse my ignorance, but here's what I was thinking: the package uname-useful depends on package coreutils. Pacman would presumably then guarantee that coreutils was installed before uname-useful. Then, the install script for uname-useful would rename /usr/bin/uname as /usr/bin/uname.old and put the patched uname in /usr/bin/uname.

My ignorance may be causing me to miss some way this approach would fail, though...

WorMzy · 2013-12-04 15:22:44

No, that wouldn't work. pacman would balk while installating the package, because /usr/bin/uname will already exist. You shouldn't do anything like moving files that are tracked by pacman in any case. You could install the binary to /usr/bin/uname-useful, then tell users that they should manually set up an alias in their shell's config file.

nathanb wrote:

x33a wrote:
Maybe you can convince the maintainer of one of these packages to use the patch.
The reason the bug report that skottish filed was rejected is that Arch wants uname to be as close to upstream as possible....so I don't think I'd have much luck with that argument.

All packages in the AUR are unsupported, just because the official package maintainer doesn't want to include the patch doesn't mean that the AUR package maintainers will do the same.

Last edited by WorMzy (2013-12-04 15:23:14)

x33a · 2013-12-04 18:28:21

nathanb wrote:

The reason the bug report that skottish filed was rejected is that Arch wants uname to be as close to upstream as possible....so I don't think I'd have much luck with that argument.

Actually, many AUR packages carry specific patches not included by Arch official packages. For instance coreutils-icp does carry an unsupported patch. In fact, I had this specific package in mind when asking you to contact the maintainer (the git package is clean ).

Of course, you are free to make a coreutils-uname-useful package (or similar), but it just crowds the AUR even more. And when you lose interest / forget to maintain the package, the packages keep rotting. There's a reason the AUR has thousand of orphan or never updated packages

So the best option is to have a single package with multiple useful patches in the AUR.

Last edited by x33a (2013-12-04 18:29:43)

nathanb · 2013-12-04 22:35:03

@x33a: Oops, my reading comprehension is decreasing with age, since I didn't realize you were pointing to existing packages...you're right, that would be a great place to start the dialog.

Arch Linux

#1 2013-12-03 21:28:48

uname has become less useful

#2 2013-12-03 21:50:34

Re: uname has become less useful

#3 2013-12-03 23:02:31

Re: uname has become less useful

#4 2013-12-04 03:08:11

Re: uname has become less useful

#5 2013-12-04 03:49:40

Re: uname has become less useful

#6 2013-12-04 03:59:06

Re: uname has become less useful

#7 2013-12-04 05:01:54

Re: uname has become less useful

#8 2013-12-04 13:59:46

Re: uname has become less useful

#9 2013-12-04 15:22:44

Re: uname has become less useful

#10 2013-12-04 18:28:21

Re: uname has become less useful

#11 2013-12-04 22:35:03

Re: uname has become less useful

Board footer