Re: User's perspective on upgrading to kernel 2.4?
Wow! Lots of responses. Thanks to all for your comments. Rather than
write about 15 separate replys, I'm going to address most of the points
in this one mail.
Greg Madden <gomadtroll@gci.net> wrote:
> Two programs that from a user perspective cause workarounds are
> xcdroast/cdrecord/mkisofs & vmware. Each one is compiled for one kernel
> version. Switching causes them to not work until recompiled or new
> modules generated (vmware) If you are using Woody the 2.4 series works
> well, smp support is better.
VMWare isn't an issue; cdrecord and mkisofs are. I just installed them
a couple of days ago on a 2.2 kernel, so I've already rebuilt them for
2.2. I guess I can just swap those packages in and out, but that's kind
of a hassle. Still, once I install 2.4, I only really intend to go back
to 2.2 in an emergency.
When you say SMP support is better: are you referring to the fact that
2.4 scales to a higher number of processors, or will I actually
experience a performance boost on my dual Athlon?
dman <dman@dman.ddts.net> wrote:
> If you use the packages provided by Herbert Xu, you'll find that apm
> and the cd driver are modules now. Add them to /etc/modules to
> restore their functionality. The Deps will ensure your modutils is
> new enough to handle it. The other difference is using an 'initrd' in
> the boot sequence. I don't know how to configure lilo for it, but
> grub is trivial.
Thanks for the warning about the CD driver; that would have been a
surprise.
Does APM work for SMP systems on 2.4? You can enable it under 2.2; it
just doesn't do anything.
I used to do initrds under lilo when my root partition was on a SCSI
disk, so I can handle that part with no problems. (I've also been
meaning to investigate grub for a while, but that's a separate issue.)
> For your firewall, load the 'ipchains' modules (or whatever it is
> called) to continue to use "ipchains". You can't mix ipchains and
> iptables, though.
I have a separate firewall machine running potato, so I can play with
iptables until I get used to it. (In fact, that's one of the main
reasons I have a separate firewall machine.)
Paul 'Baloo' Johnson <baloo@ursine.dyndns.org> wrote:
> I would highly recommend ext3 at this point, just make sure your
> e2fstools are the current version (in woody? sid?), and once you've
> recompiled, tune2fs -j /dev/(your partition goes here). Edit fstab so
> ext2 is now est3, and viola! You're using a journaled, fast
> filesystem.
I think I'll keep my filesystems at ext2 for now, since I may need to
reboot under 2.2 in a pinch. When I'm reasonably satisfied that 2.4 is
OK, I'll probably move up to ext3.
In another message, Paul also said:
> Moderately faster (YMMV) virtual memory system (>2.4.10), better
> hardware support, and compile times stretching into the weeks on a
> 386. 8:o)
Well, I have a dual Athlon 1900+; do you think compile times will be a
problem? :-) (make -j is your friend.)
Paul Smith <pausmith@nortelnetworks.com> wrote, in response to my
question about /dev changing:
> That is only if you enable the dev filesystem, which is still beta,
> not enabled by default, and probably not recommended.
This is probably the biggest issue; I've gotten several conflicting
recommendations about devfs/devfsd. What are the advantages of going to
the new devfs/devfsd? I haven't really paid much attention to the buzz
about this issue, although I gather it generated some controversy early
in the 2.4 series. FWIW, the hardware on this machine doesn't change
all that often; USB currently isn't an issue, as I don't have any USB
devices.
So: stick with the old dev, or use the devfs with devfsd running in
compatibility mode?
Jeffrey W. Baker <jwbaker@acm.org> said that in his experience, devfsd
in compatibility mode didn't create the necessary devices for SCSI hard
drives. I've got one of those, although nothing critical is on it at
this point. What would I need to do in order to get these devices back?
Thanks again,
Richard
--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: