Dmitry wrote: (snip)
But why my patched tree have do be different from kernel.org tarball? I thought that patches bring the source EXACTLY the same through different versions - that's all its about. If they aren't, then I would expect troubles on compiling and such. Maybe i thought wrong? )
I can agree that MD5 sums may differ from one bzip2 compression level to another. :) But as for patches - i'm not quite sure. Please explain me, if you don't mind :).
It might not be the source that differs, it could be a documentation file. Perhaps there are files that were removed since the original tarball. I'm not sure if they'd be removed as well or just ignored. Theres really alot of things that could be different.
But portage doesnt care about the md5 of the linux source, it cares about the md5 sum of the kernel.tar.bz2 that you have, and theres a million (times a million factoring in what i said above) reasons this could be different.
I believe portage tells you what to do to correct the MD5
Yes, it told me to remove linux-2.5.66 and replace it with right one :). I.e. - download right one. :) I have only one problem with that - THE 56K MODEM :). I'm in Russia, you know :). We don't have Internet services well adopted to people - but i beleive that we will in near future. :) At least all goes on to this :). But price for even ISDN connection is too expecive for me at the moment. :( I'm a student and don't have much money to spend :). But that seems to be my own problem, yeah? )) So let's leave it :))).
Thats what the portage program suggests. It assumes it did download the source for you, and something went wrong. Why would it assume that you patched and re-compressed the kernel sources from an older version?
i'm pretty sure it's in the man pages, but you can change the md5 sum that portage thinks is correct. This change is obliterated after every sync.
Sounds like a timezone problem or GMT RTC problem. Check into /etc/localtime:
ls -l /etc/localtime
lrwxrwxrwx 1 root root 30 2002-09-19 14:38 /etc/localtime -> /usr/share/zoneinfo/US/Central
Checked this out - it's all right with this file - it points to my timezone "/usr/share/Europe/Moscow"
Btw, when I rebooted with stable kernel, first thing that i've done -- set the correct time and date. But when I rebooted again (stable) i got again the April 6!!! :( So I think that's not a kernel bug :). I will look in config files, but not quite sure what it can be :).
You might want to set up rdate even if you do get this problem fixed. Theres a howto in the most recent gentoo weekly news.
nvidia has their own drivers out for stable kernels. I'm not sure if there are patches for 2.5 kernels or not, as they are harder to keep up with.Also look at what you have for your kernel config under General, there is an option there for "RTC stores time in GMT"
That option is not set - i'm sure. I already know about it :).
Since you mentioned it, is there any particular reason you are running unstable kernels? I've tended to avoid anything but release candidates/stable for machines I care about (heck, I only recently started compiling my kernel with gcc 3.x!). If you are just looking to play, it would be far safer to do so in UML or a virtualizer such as VMWare or bochs. Sure you won't get a feel for speed improvements, but you aren't risking your data on unstable I/O developments. Just a friendly suggestion... <remembers the umount sync fiasco... and that was on "stable" kernels!>
Just wanted to give it a try :). And to look at the UNSTABLE kernel - since i was never tried it before. :). Just interesting :).
Another reason - I have Nvidia Nforce2 chipset on my MB and it is not supported by last stable kernel :(.
As far as i know, nforce motherboards (and assumingly nforce2) use are usable using regular generic drivers (which are used on most motherboards), and the nforce drivers are extensions to allow special features to work, as well as anything past core functionality (including builtin devices, etc.)
And another reason - someone in list a few days ago told that's not enough people in linux community that would agree to test new kernel and that's why its development goes slowly ;). I'd like to help, so i decided at least to try to help :).
If that's your reason, be sure to fill out bug reports as well, then. Testing isnt testing without feedback.
Truly, I expected MUCH more problems with unstable kernel - I even thought that it can crush at once as i run it :). But maybe my current problems are only at the begining :)))
I've been using unstable kernels for a while now, the only problems i'm having are with pcmcia.
Just don't know yet what would I do - solve this problems and stay with unstable kernel, or move to old, but proven good one? :) What would anyone suggest? :)
If an older kernel fits your needs, by all means use it.
-Chris I
pgp00000.pgp
Description: PGP signature
