Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Linux 2.2.0pre5 97

Posted by justin++ from the test-me,-it-calls! dept.
Linus released 2.2.0pr.5 this afternoon. Hopefully, enough mirrors will have synced by now. People need to test these babies so the real 2.2.0 is as close to bug-free as possible.
This discussion has been archived. No new comments can be posted.

Linux 2.2.0pre5 More

Linux 2.2.0pre5

Comments Filter:
  • Then stick with 2.0.X or 2.1.X.

    I don't plan on changing to 2.2.x untill I find a feature I need.

  • vga consoles? I guess you mean framebuffer consoles. I imagine people whose machines don't implement any sort of text mode find them quite useful :) And if you have a PC and don't like framebuffer, don't use it..
  • ...when I manage to get it before Slashdot announces it :-)

    ---

  • Do it this way. Say you keep your patches on /usr/src/, and your kernel is on usr/src/linux-2.2.0pre4/


    First, patch it.

    # cd /usr/src/linux-2.2.0pre4
    # bunzip2 -c ../patch-2.2.0pre5.bz2 |patch -p1



    Then, check for failed patches (files with a .rej extension):

    # find . -name '*.rej'


    If none appear, then the patch was successful. You can remove the original files that the patch saved (those with a .orig extension):

    # find . -name '*.orig' -exec rm -f {} \;


    Usually it's a lot easier, since scripts/patch-kernel (go and read it with less) under the kernel tree is a script that automatically applies a set of patches to a kernel tree. Sadly, the irregular numbering on the pre-2.2 series has broken this script (last time I checked)

    ---

  • This is usually the case with pre-patches. But not with the official pre2.2 kernel patches Linus is putting out now.


    It does apply to the ac patches, AFAIK (haven't tried them).

    ---

  • Linus' 2.2 pre-patches are not cumulative, they're incremental, meaning you DO NOT remove pre4 to get pre5.
  • Actually, it's possible that you'd never see it. And therefore never be able to see whats going wrong if something bad happens. At least that's the way it works now with Plug and Pray monitors.

  • An amusing trick that is quicker than uncompressing and running patch manually:

    # cd /usr/src/linux
    # cp patch-2.2.0-pre5.bz2 patch-2.2.1.bz2
    # ./scripts/patch-kernel

    Current kernel version is 2.2.0-pre4
    Applying patch 2.2.1 (bz2)
    done

    (You have to rename the patch file as the patch-kernel script doesn't recognize the -pre5 extension. Obviously this has no actual effect on the patch itself).


  • Ads? On Slashdot? Oh yeah... www.junkbusters.com. :)

  • If there won't be ISDN support in 2.2.0 because Linus refuses [lwn.net] to include the lately sent-in patch file, this kernel version won't be quite useful here in highly-using-ISDN-Germany... :-(


    Regards, Jochen

  • Has anyone else had a problem compiling this one? When I try and compile, it dies with this:

    checksum.c:200: redefinition of `csum_partial_copy'
    checksum.c:105: `csum_partial_copy' previously defined here.

    Now, I know a little bit about programming, so I opened up checksum.c (which is in /arch/i386/lib) and checked out lines 200 and 105. They're function declarations. Line 200 declares function "csum_partial_copy", and line 105 declares function "csum_partial_copy_fromuser". So why does the compiler think that its trying to redefine "csum_partial_copy"?

    I'm trying to compile under RedHat 5.2 using gcc-2.7.2.3-14.

  • Don't blame Linus for this. If the ISDN people want it included in the kernel they better submit patches way earlier. The same happened to knfsd and now people are taking responsibility and knfsd has an official maintainer. Just needed a kick in the behind from Linus, I guess.

    /mill
  • IMHO, moving from 2.1 to 2.2..0 pre gives bug-testing a whole new boost, which should help iron out a lot of last-minute glitches. (I remember having to wait, with 2.0 - I was able to use almost every development kernel prior to it without problems, but 2.0.0 simply wouldn't work.)


    I'm not going to worry, no matter how long it takes. Weeeeell, if we get up to 2.2.0-pre150 I might wonder if maybe Linus switched to the pre phase a tad early.... :)

  • I like RPM because it allows me to keep track of files on my system, provides a powerful versioning system for up/downgrades, and most importantly, it saves time...

    I'm pushing for a major switch from Solaris to RedHat Linux here at work. My major selling point is reduced administration time through the use of RPM.

    Remember that RPM != Precompiled Binary. SRPMS allow you to compile from pristine source, but also give you the ability to track/update/remove every file created through the compilation process. I like that a lot better than the ".tar.[gz|bz2|Z]" system of spraying and orphaning files all over my file systems.

  • Whenever it's ready. Probably soon, however; I'd say it certainly wouldn't be more than two months away, and probably no more than one month.
  • It seems that IP aliasing is not working in the late 2.1 and pre-2.2 kernels.

    Running the following command under 2.0.36 (and other 2.0 kernels) works fine:
    ifconfig eth0:0 192.168.0.139

    However, with the 2.2.0-pre5 kernel, this has no effect. I have built both Network aliasing and "IP: Aliasing" into the kernel.

    Before I submit this as a bug, does anyone know if there is some new syntax or other requirement for this to work? E.g. some /proc/sys/net/ipv4 stuff?

  • Umm, did you even read the post you linked to at http://lwn.net/1999/0107/a/lt-isdn.html? It's not Linus's fault; he's doing what he should. Kick the ISDN4Linux people instead. Geez.
  • The Frame buffer console was ported over to x86 because the PC98 spec no longer requires a text mode on video cards - so, in the future, it might be impossible to use Linux on x86 w/o a frame buffer console. As others have said, in the mean time, if you don't like it, don't use it.
  • Well you're right: I like SRPMs too, but you know what an SRPM is? It's a tar.gz file (maybe a few), together with patches and a spec file.

    When you install an SRPM, all it does is copy the tar.gz file(s) and patches to /usr/src/redhat/SOURCES and the spec file to /usr/src/redhat/SPECS (talk about splaying all over your filesystem...and why are the RPMS binaries a part of the /usr/src tree?). You have to then use the spec file to build the RPM, then install the RPM.

    The problem is that if you're looking for someone to provide an SRPM for a kernel, then simply build an RPM from their spec file, you *still* have no control over the kernel configuration, which is pretty important when testing the kernel (which is, after all, what the prereleases are for).

    If you're building your own RPM/SRPM, you haven't saved any time (especially considering that you often have to build the stuff successfully more than once if you are making your own spec file; once by hand [using the tar.gz] and again from the spec-- for instance to find out what files it provides).

    I don't think the original poster cared (or knew) about building his own RPM, he was more concerned with just getting a binary package and installing it, letting others compile for him.

    If you want to build your own RPM/SRPM, then just grab a spec file from an earlier kernel SRPM and hack...er, edit it to work with the new kernel. The steps are the same, more or less, only the configuration file (which you would presumably include preconfigured) will be different.
    --
    Aaron Gaudio
    "The fool finds ignorance all around him.
  • Don't you use modules? or is that why you have to make bzImage? Nonetheless, most of us do use modules, and that automagically installs into the /lib/modules directory tree so there is some splaying.
    --
    Aaron Gaudio
    "The fool finds ignorance all around him.
  • Geez, download it.. run it.. report the problems.

    Stop whining and become part of the 'team'.

  • How ironic. The sequence I use (OK, I'm still on 2.1.131, but same principles apply) is:

    cd /usr/src
    bunzip2 patch-2.1.131.bz2 #or gunzip if applicable
    patch -p0 patch-2.1.131

    (the -p0 tells it not to strip any directories from the filenames being patched)
  • IT SAVES TIME!!! Plus I don't want to dink around with tar files and patches to the point of destroying my system. I've already installed 2.0.36-1 in my RH52 system at home and work with a minimum of fuss. IMHO the RPM system is why RH is the leading distro in the US.
  • If you are going from a 2.0 to 2.2 kernel, remember that IP Forwarding is off by default, and you need to echo a '1' to the appropriate file in proc (i don't recall it... look at the IP Chains page) to enable it. My masquerading was broken for two weeks until I found this out. Now it works like a champ. Go 2.2!
  • There are comments on here from people wanting 2.2.0 to be released soon...

    I personally would not like to see it released after first quarter this year, but I don't understand why it is so important to people to have 2.2.0 released.

    Linux kernel 2.2 is currently in a feature freeze, which means the current pre release does everything the final kernel will do. So why is it so important for 2.2.0 to be released?

    Why don't you, the people who want to use 2.2.0 final, just use pre5 AS IF IT WERE FINAL, and only update to the latest pre every 5 releases or when you find a bug in the kernel you are using.

    If 2.2.0 were released tomorrow any further bugs that are found would have to be put into a patch, and because end users, not just the `beta testers' will have to apply this, linus will probably want to wait a while before releasing it.

    I personally like the releasing of a new pre every 2-3 days, it means I have to compile then re-boot, which makes me feel like I am in windoze again :-) (does flatlining the CPU then having to re-boot for the changes to take effect to install software remind anyone else of a certain OS? *grin*)
  • This assumes that your patch-2.2.0-pre5 is in /usr/src, and you uncompressed linux-2.2.0-pre4 to /usr/src/linux.

    cd /usr/src/linux
    patch -p1 /usr/src/patch-2.2.0-pre5

    And you'll be done!

  • rpms? (Score:1)

    by tsikora ( 6430 )
    Sorry the Real Linux world is a tar world. Building it youself with tars and *new*
    bz2 are the standard. Gimmicks need not apply.
  • Last night (23:00 gmt+1 time) I found the pre5 patch and complete source on ftp.kernel.org, on a completely free system, there where almost no users at all online. Yet I noticed that none of the mirrors had it. So please, whoever posts kernel kernel info on slashdot, look on the mirrors ( all of them ) if it is allready available there.

    aXi
  • &ltRANT&gt
    Well, they could pull a Microsloth and release it as-is, even though it still contains bugs. Or they could do what they're doing, make multiple prereleases and correct the bugs in each, then making sure that the bugfixes do not engender new bugs, so when they do release 2.2.0 final, it's stable and works. Which would you prefer? If you want to speed up the release of the final 2.2.0 kernel, install the latest prerelease and submit intelligent bug reports.
    &lt/RANT&gt

  • Cyrix (Score:1)

    by Fantome ( 7951 )
    Are the Cyrix 6x86 chips still broken? Mine seems to be. I've tried all the patches... compiled it for 386, etc...
    I guess it's time for the real stuff.
  • > depmod should show ppp.o depending on bsd_comp.o and ppp_deflate.o

    no no no no no no no!

    bsd_comp and ppp_deflate depend on ppp, not the other way round!

    using aliases is the right way. the kernel doesn't know that ppp-compress-24 is bsd_comp, and doesn't need to!

    this approach means that a compression module will only be loaded if it is going to be used: if your ppp peer doesn't support compression, the modules won't be loaded, and everyone's happy, yes?

    I should imagine that you can't load ppp_deflate without having ppp already loaded (could be wrong, can't check while at work), so having ppp *depend* on ppp_deflate would obviously be broken...
  • where can a good list of what got fixed in each pre release be found?
    --
  • I don't do -ac patches because I'm too lazy to undo them before the next one. Pre6 should have this fixed; at least I hope so I'm in the middle of configuring a firewall so this bug wrecks the effort. Patienly waiting...
  • Redhat is the leading distro because of the easy installation. Debian is the best distro because of .deb, dpkg, and apt. When you learn more you'll move up. I needed RedHat for on month before graduating to debian. When you find you can't upgrade sw you want because of rpms don't let you acquire the necessary dependencies or won't overcome conflicts you'll check out debian, and you'll love it. Aside from that, that rpm kernel you installed has options you don't need. You could reduce the size of the kernel by typing make clean, make menuconfig, make dep, make bzImage (if it's that big) or make zImage, then make bzlilo to install it, make modules, make modules_install, that's it, reboot. Participate in the linux community and report bugs. Trust me, if I can do it, you can too.
  • It's been forever in coming for pre-2.2. when to final?
  • You do realize that you can configure that, right?
  • Hey, it beats MSCE books if nothing else. :-)

    D
  • Well, if a functional patch exists, then ISDN users or their distribution maintainers can apply it themselves. If no functional patch exists, even now, then it probably isn't worth holding up the release of 2.2.0 for it. Annoying, but...

    In either case, it is on Alan Cox's todo list, and I'm sure that it will be fixed early in the 2.2.x series.

  • Can I use my mousewheel in X? Would someone mind pointing me in the right direction for info on this?
  • pre-5 was the first one to work for me, so obviously they still have a few issues to work out! I'd rather they release 20 "pre" instead of taking the Microsoft route and calling a buggy product final.
  • once an OS or software is finished to the point of no improvement..we should not use computers anymore.
  • go get
    ftp://ftp.linux.org.uk/pub/linux/alan/2.2pre/pat ch-2.2.0pre5-ac1.bz2

    and put it in /usr/src/linux

    patch then recompile .. its works now :)


    talking windows users is where I draw the line ..
  • don't bother visiting slashdot anymore.
  • you smoke too much crack. sure, in a MS world where your forced to use the Man's inflated disfunctional kernel, precompiled updates would be fine. but in a world where you can actually fine tune your computer's abilities, it simply isn't. download the tar and take a bite out of crime.
  • is it just me, or are vga consoles annoying? i come from an ascii art background so i might be biased to the oldskewl, but...i'm just wondering.
  • i get an error message because lilo doesn't recognize the "video=" option. does anybody know how to correct this? i'm using lilo version 21

Slashdot Top Deals

1000 pains = 1 Megahertz

Close