At first thanks for reply, Dave :) >MD5 sums will tell you with whether the files match with a very high >sensitivity to any change.
I fully understand that. :) >Odds are that there are mild differences >between your patched tree and the official kernel.org tarball for the >kernel. 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 :). >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 :))). >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 :). >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 :(. 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 :). 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 :))) 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? :) Thanks anyway. :) Best regards, Dmitry. -- [EMAIL PROTECTED] mailing list
