[ale] ifup problems, possible IPv6

[James P. Kinney III]

On Thu, 2005-02-03 at 19:07 -0500, Michael H. Warfield wrote:

> 
> 	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

I a long-time user of RH stuff. I have to chime in here in support of
Mikes gripe with the LABEL= garbage. That is a level of system
abstraction that does not do anything productive. By the time there is a
PROBLEM and I need to work fast at moving a partition to another drive,
I sure dont want to have to go find out which partition is /boot mounted
on. Sure it's LABEL=boot but that doesn't feed nicely to dd, now does
it? The label is a nice thing but is should be just that, a label, an
extra tag that is used only as a reminder of use. Otherwise, /boot which
on one system is really /dev/sda3 and another system /dev/hda2 can be
found fast with "cat /etc/fstab".

On the kernel issue, most of the $$ distro$ have backported patches to
their "official" kernel. That can be a PIA to work from. So far, Fedora
has only used (that I have caught) a stock kernel.org kernel with no
extra patches. So the /boot/kernel*.config file can be used to build
another kernel with the same setup from a stock kernel source. I like to
use the distro kernel to initially boot with and then "roll my own"
using the supplied config file as a starting place to take out the parts
I don't need until the kernel is as lean as I can make it. I really
don't _need_ every module there is no matter how cool the tech is :)
-- 
James P. Kinney III          \Changing the mobile computing world/
CEO & Director of Engineering \          one Linux user         /
Local Net Solutions,LLC        \           at a time.          /
770-493-8244                    \.___________________________./
http://www.localnetsolutions.com

GPG ID: 829C6CA7 James P. Kinney III (M.S. Physics)
<jkinney at localnetsolutions.com>
Fingerprint = 3C9E 6366 54FC A3FE BA4D 0659 6190 ADC3 829C 6CA7
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part