[ale] ifup problems, possible IPv6

[Michael H. Warfield]

On Thu, 2005-02-03 at 18:45 -0500, Geoffrey wrote:
> Jeff Hubbs wrote:
> > On Thu, 2005-02-03 at 13:42 -0500, Michael H. Warfield wrote:
> > 
> >>Building
> >>a custom kernel on Fedora Core 3 is a royal pain in the fanny, since it
> >>no longer has a "sourcecode" rpm and the SRPM has to be used and that
> >>can't be installed or updated by yum.  Building a vanilla kernel from a
> >>primary kernel.org tarball is even further out there.  
> > 
> > 
> > Wow, I had no idea.  I'm surprised that a major distribution is like
> > that.  In Gentoo-land, kernel compiles are part of the natural order of
> > things and you can either bring your kernels (including vanilla ones) in
> > through the portage system by simply emerging them or you can drop them
> > in /usr/src the old-fashioned way.

> I'm not all too sure what Michael's alluding to, but I've built a couple 
> of custom kernels from kernel.org and all went well.

> Maybe you can expand on your concerns Michael?

	In this particular case, I'm alluding to some of the pain of dealing
with some of the distro specific patches and changes and conflicts with
the generic kernels.  Once you've crossed that hurdle on a given
install, the generic kernels are no more problem than the distro
specific kernels.  It's just that there can be gotcha's the first time
(and, maybe, after upgrades).

	For instance, you have the LABEL= mount point stuff in RedHat.  Not
sure if that's worked it's way into the mainline kernel or not.  Sounds
like a good idea, at first glance, till you've been burned by it.  Build
a kernel.org kernel (at least a 2.4 kernel, for sure) and then discover
that NONE of your mountpoints would mount any longer because the kernel
doesn't understand the "LABEL=" scheme.  So the concerns are not so much
building the kernel, which is simply an involved undertaking, but the
random acts of terrorism that you run into when that kernel conflicts
with the distro.  Some distro's, like Debian, are very generic on the
kernel.  Some, like RedHat, are a royal pain in the rear.

	I've been burned by that particular example I've cited, three ways.
One, booting a generic kernel blew up in my face forcing me to boot the
old kernel and modify grub.conf and fstab to fix the dain bramage
introduced by RedHat (easier than fixing up the patches).  Another time,
when I was using loop-AES (which requires patched mount and losetup
utilities) I was burned when the patched version no longer supported the
RedHat-ism.  Third problem pointed out WHY LABEL= was a bad idea
implemented poorly.  Added a hard drive to a system and discovered the
random acts of terrorism that occurs when you have multiple partitions
with the same label.  Earlier version of Fedora and RedHat would mount
multiple devices over the same mount point!  Not good.  Now, last time I
saw this, it simple bitches that there are multiple labels and refuses
to mount anything (single user mode, here we come).  I'm rather
disgusted with RedHat over that particular misfeature, if it isn't
obvious (and, yes, there are people who glow over how wonderful it is
not to have to worry about device renumbering and all [which I've never
encountered]).

	But it's just an example that going back to a "generic kernel"
introduces some new uncertainties.  I would not take a Fedora Core
system back to a generic kernel unless there was an overwhelming
requirement, at this point.  My development platforms, sure.  My
production platforms, no.  There have been other examples (and there's
always the issue of staying up on security patches) that I don't have at
my finger tips at the moment.

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw at WittsEnd.com  
  /\/\|=mhw=|\/\/       |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part