Re: how to detect a debian kernel from `uname -r`
On Sun, Sep 11, 2005 at 07:30:20PM +0200, Andrea Arcangeli wrote:
> On Sun, Sep 11, 2005 at 06:10:47PM +0200, Sven Luther wrote:
> > Nope,; it works for debian packages. But you can match that to kernels.
>
> not quite, you never know what kernel the system is running if you don't
> call uname -r sorry. Note that klive is written for _mainline_ kernels,
> see the homepage (without screening args). Adding the debian screen is
> just a minor feature that I could as well remove if they remain
> undetectable.
>
> Klive has nothing to do with debian or suse or any other distro, it was
> made for the mainline kernels only. But apparently a number of people is
> running it in combination with the distro kernels, and in turn I'm
> trying to be nice and detect them (or at least filter them out of the
> homepage without args).
>
> > arch basis, especially as it might be that two flavours on two different
> > arches share the same name. Not sure if this is the case right now.
>
> So the mess is even higher than what I originally thought...
>
> If different flavours of debian can have the same uname -r means the
> uname -r is meaningless on debian, you could call it "foo" and it'd be
> the same.
uname -r is meaningless everywhere, it can be set to whatever the user wants
when he compiles it.
> That doesn't mean it doesn't work at runtime, it just means there's no
> way to know what flavour is running by checking uname -r.
Well, you obviously can take some educated guesses :)
> > Well, possibly, but i have some doubt of the values of it. Actually, there is
> > a sure way of doing this, you could simply get a database of all the ubuntu or
> > debian kernels out there (they are all archived), and then simply match their
> > md5sum against the md5sum of the installed kernel (which is
> > /boot/vmlinu[zx]-`uname -r`). That way, you have no doubts ay all :)
>
> Using the database is attractive as an heuristic for the names (and I
> can match the uname -m as well if needed), but I'm unsure about the md5
> way. You can call the kernel name as you want, you can call it /boot/foo
> and set grub to /boot/foo, and the uname -r may well be
> 2.6.13-something. So it's not certain which image in /boot we'd need to
> take the snapshot of. It may even be deleted by the time the client
> runs. Amittedly those are corner cases, but if I've to make substantial
> changes I'd prefer something really reliable.
if you are on a debian system, and running a debian kenrel, then the kernel
will be /boot/vmlinu[xz]-`uname -r`. If the user overwrote a debian kernel
with a self-compiled thingy, then bad luck to you. That said, you can always
look at the dpkg database for /lib/modules/...
Also, i believe /lib/modules should have the info you search, after all, it
knows how to match the kernel with its modules.
Finally, you only have this problem because you are using sucky hardware, on
the real thing, you only need to look at :
/proc/device-tree/chosen/bootpath
To know what file you booted from :)
> > Assume debian by default :) I am not sure, but i guess ubuntu and debian use
> > another set of flavours even, but if you really want to do it right, the most
> > sure way is the md5sum database.
>
> I feel that adding a /proc/branch or something like that is easier and
> completely reliable, its only disavantage is that it requires (trivial)
> kernel changes.
Well, go ahead then. Still, i am not convinced this will give you any info
about what you want, since probably users can put any random stuff in it, not
the data you are searching for. Maybe you could have /proc/md5sum, which
contains an md5sum of the running kernel :)
Friendly,
Sven Luther
Reply to: