Linux: Stock Kernel Compatible Distributions

Submitted by Jeremy
on May 7, 2004 - 5:40pm

Stephen Hemminger recently posted to the lkml in frustration, asking which Linux distributions support a stock kernel. He specifically listed problems between the stock kernel and Mandrake, due to its use of supermount, and SuSe due to its usage of ReiserFS attributes. He explained, "When running a non-vendor kernel, I need to reasonably expect that the system will boot and all the filesystems and standard devices are available."

The various responses listed a few distributions that evidently work well with the stock kernel, including RedHat's Fedora, Debian, Slackware, and Gentoo. Stephen concluded, "I am not saying it is bad that the distributions try to satisfy their customers, or create a better experience; they just need to stop breaking things, and add running a standard kernel as part of their QA cycle."


From: Stephen Hemminger [email blocked]
To:  linux-kernel
Subject: Distributions vs kernel development
Date: 	Fri, 7 May 2004 08:53:12 -0700

After having being burned twice: first by Mandrake and supermount, and second
by SuSe and reiserfs attributes; are any of the distributions committed to
making sure that their distribution will run the standard kernel? (ie. 2.6.X from
kernel.org). When running a non-vendor kernel, I need to reasonably expect that the system
will boot and all the filesystems and standard devices are available.  I don't
expect every startup script to run clean, or every device that has a driver
only in the vendor kernel to work. 

But kernel developers need to be able run a standard environment. This effects
both day to day kernel testing and automated test environments like PLM and STP.
I am not saying it is bad that the distributions try to satisfy their customers,
or create a better experience; they just need to stop breaking things, and add
running a standard kernel as part of their QA cycle.


From: Arjan van de Ven [email blocked] Subject: Re: Distributions vs kernel development Date: Fri, 07 May 2004 18:02:36 +0200 On Fri, 2004-05-07 at 17:53, Stephen Hemminger wrote: > After having being burned twice: first by Mandrake and supermount, and second > by SuSe and reiserfs attributes; are any of the distributions committed to > making sure that their distribution will run the standard kernel? (ie. 2.6.X from > kernel.org). I can say that for Fedora Core we do have this goal. Obviously we do expect a "recent enough" kernel, eg a 2.2 kernel on FC1 probably will give issues, as will 2.4.0. 2.4.2x ought to be fine though.
From: Jeff Garzik [email blocked] Subject: Re: Distributions vs kernel development Date: Fri, 07 May 2004 12:03:00 -0400 Stephen Hemminger wrote: > After having being burned twice: first by Mandrake and supermount, and second > by SuSe and reiserfs attributes; are any of the distributions committed to > making sure that their distribution will run the standard kernel? (ie. 2.6.X from > kernel.org). When running a non-vendor kernel, I need to reasonably expect that the system > will boot and all the filesystems and standard devices are available. I don't > expect every startup script to run clean, or every device that has a driver > only in the vendor kernel to work. Fedora Core runs stock 2.4 and 2.6 kernels just fine... :) Jeff
From: Måns Rullgård [email blocked] Subject: Re: Distributions vs kernel development Date: Fri, 07 May 2004 18:05:43 +0200 Obscurity, linux) Stephen Hemminger [email blocked] writes: > After having being burned twice: first by Mandrake and supermount, and > second by SuSe and reiserfs attributes; are any of the distributions > committed to making sure that their distribution will run the standard > kernel? (ie. 2.6.X from kernel.org). When running a non-vendor kernel, > I need to reasonably expect that the system will boot and all the > filesystems and standard devices are available. I don't expect every > startup script to run clean, or every device that has a driver only in > the vendor kernel to work. My last slackware install used an unmodified kernel, I don't know if the latest versions so the same. I run gentoo with vanilla 2.6 kernels. I recently installed a vanilla 2.6 kernel on a redhat9 machine, without any problems (which quite surprised me). -- Måns Rullgård [email blocked]
From: Martin J. Bligh [email blocked] Subject: Re: Distributions vs kernel development Date: Fri, 07 May 2004 09:22:17 -0700 > After having being burned twice: first by Mandrake and supermount, and second > by SuSe and reiserfs attributes; are any of the distributions committed to > making sure that their distribution will run the standard kernel? (ie. 2.6.X from > kernel.org). When running a non-vendor kernel, I need to reasonably expect that the system > will boot and all the filesystems and standard devices are available. I don't > expect every startup script to run clean, or every device that has a driver > only in the vendor kernel to work. > > But kernel developers need to be able run a standard environment. This effects > both day to day kernel testing and automated test environments like PLM and STP. > I am not saying it is bad that the distributions try to satisfy their customers, > or create a better experience; they just need to stop breaking things, and add > running a standard kernel as part of their QA cycle. I run Debian to do this all the time. If you run the stable distro, it doens't have all bleeding edge desktop crap, but it does have the major advantage of actually working, and being perfectly stable. Getting it to run 2.6 needs a few small updates, but nothing hard. Testing is very solid too, has 2.6 support out of the box, and more updated desktop stuff (I run that on my laptop). Unstable seems more stable than most vendors shipped distros to me, but changes more rapidly. They also seem to break serial console occasionally in unstable by loading fonts into it (idiots!), but that's trivial to fix. The fact that their own kernel packages are so close to mainline probably helps a lot ;-) M.
From: Pascal Schmidt [email blocked] Subject: Re: Distributions vs kernel development Date: Fri, 7 May 2004 21:41:13 +0200 On Fri, 07 May 2004 18:00:22 +0200, you wrote in linux.kernel: > After having being burned twice: first by Mandrake and supermount, and second > by SuSe and reiserfs attributes; are any of the distributions committed to > making sure that their distribution will run the standard kernel? (ie. 2.6.X from > kernel.org). Slackware, both -current and 9.1. Don't expect fancy initscripts handling every possible thing you could boot off for you, though. -- Ciao, Pascal

Related Links:

Huh?

Cabal
on
May 7, 2004 - 8:00pm

Mandrake runs perfectly with a vanilla kernel. In fact, some recent releases shipped with supermount disabled, and even if it is enabled, it won't break anything to run without it. I've never used a supermount kernel for longer than it takes for me to compile a new one and never had a problem.

Not just supermount.

Wolfbone
on
May 9, 2004 - 4:34pm

"Runs perfectly with a vanilla kernel" or "Runs perfectly with a vanilla kernel for me" ?

Supermount is not the only issue: When I ran Mandrake 9.1, I found that the supplied userspace iptables would not work properly with a vanilla kernel's netfilter modules. I had to ditch the mdk binaries and build iptables from source to get it working again.

*My* experience with mdk was that it never worked satisactorily, let alone perfectly, even with it's own kernel. As the saying goes; "the plural of anecdote is not data" and who knows what other incompatibilities there might be?

I had to ditch the mdk binari

Anonymous
on
May 12, 2004 - 5:45am

I had to ditch the mdk binaries and build iptables from source to get it working again.

I had to do this too. Netfilter underwent a change (sometime around 2.4.24?) that required new userspace iptables. The problem was just using a new kernel with old iptables, not anything MDK-specific. If your vanilla kernel had been the same version as the MDK one you replaced, you would not have had a problem.

In chosing to run vanilla kernels on MDK, I assume that I will occasionally need to compile recent versions of my own userspace tools. To expect anything else is just daft.

You're right...

Wolfbone
on
May 13, 2004 - 5:38pm

Yes - 2.4.24 - that sounds about right. My mistake then - I'd gotten so used to blaming Mandrake for it's myriad inconsistencies and annoying bugs that I was about ready to blame them for the rain. ;)

Mandrake

Anonymous
on
May 7, 2004 - 8:36pm

I have always had problems with Mandrake's and Red Hat's kernels also.

Wow

Anonymous
on
May 8, 2004 - 7:40am

Nice trolling in this thread. Too bad no moderation has been brought back yet.

Mandrake is not the problem

doctorture
on
May 7, 2004 - 9:26pm

I use Mandrake and the latest kernel, 2.6.6-rc3, 2.6.6XXX-mm2 etc..
whithout problem.

You just need to adjust your /etc/fstab to not use supermount and you are done. This way you are like the other distribs like Fedora, that doesnt use supermount.

Supermount is veeeeeeeeeery good, I really dont know why just Mandrake uses it. This is one of the major details that keeping me using MDK 10.

Supermount is evil

Anonymous
on
May 7, 2004 - 10:39pm

it breaks things, it can wipe data out of your CDRW, it can crash your machine if you have aggressive readahead or some other filesystem than ISO (like UDF)...

lol...thats bullshit

Anonymous
on
August 14, 2004 - 5:33pm

lol...thats bullshit

Supermount is a hack, NOT evil

Anonymous
on
May 8, 2004 - 5:23pm

I think that supermount is a quite good thing, and Mandrake is doing
a GREAT thing including it in his distro, and i wonder why Linus did not merge it (or something similar) into the kernel.

I will say that i do not love supermount in particular. But Linux just
has NO HOPE on the desktop until the user has to use mount to read cdroms, edit /etc/X11/XF86Config to have a working xserver and to be root to do "modprobe usbcore; mount none -t usbdevfs proc/bus/usb" to have the digital camera working (unless the permissions/ configurations have be perfectly tuned by the distro).
Of course mount is great for experienced users, but it is not what
average users should NEED to do.

If an average user tries linux and finds out that he must do something
complicated just to read a cdrom he will never try it again.
I spend a lot of time programming/installing/tuning on my linux box,
but i do respect those who do not want to know about how everything
works on a computer.

After all, come on guys, we can click on the cdrom to read it since
windoze 95!

if you don't like supermount, ok, let's try somthing different, but
linux should not stay a it is for long, or it will be a big amount
of great code written by amazing people just for nothing.

Mounting == Policy

Anonymous
on
May 8, 2004 - 8:10pm

When to mount what for which action is policy and should be kept out of the kernel. For example, like in Windows 95, where automounting is kept out of the DOS based kernel and is handled by the shell.

Bash, GNOME, KDE are all shells, and cross platform, so they can't depend on Linux handling mounting for them anyway . . .

Editing XFree86.conf == so not the kernel's problem. This is an X issue, X is cross platform, the only real gripe you can have with the kernel about X is when the X implementation does something stupid because the kernel makes it hard where other kernels make it easy.

As for the modpobing, again, policy, but easily handled by the hotplug system. For the "standard" scripts check out linux-hotplug.sf.net

User space

Anonymous
on
May 8, 2004 - 11:25pm

Message:

In this distro mounting of the removable media and
all system configuration is implemented in "USER SPACE".

Since you are THE USER, it's to you to do the work,
so please mount the cdrom...

Implementation not theory

kinema
on
May 8, 2004 - 9:05pm

It isn't the idea behind automount that is evil or flawed, it's the implementation. In my humble opinion a better option would be to implement it using a user-space filesystem like FUSE/AVFS or LUFS.

agreed

Anonymous
on
May 8, 2004 - 10:49pm

This is a very good idea.

User Mounting

Claymen
on
May 8, 2004 - 10:13pm

KDE can handle mounting easily, just make sure the user can mount the cdrom by adding it into fstab with the option user and enable in kde to display the devices on the desktop. It will automount the cdrom for you etc without having to rely on supermount. Just click on the cdrom icon and bam if its not mounted it will attempt to and if that fails it'l tell you there aint no cdrom in there.

Hence you dont have any of the problems associated with supermount. And this works not only for cdroms but anything thats available for the user to mount. Hdd's, zip drives etc.

In regards to the xsetup stuff, most distros aimed at USERS tend to auto configure that for you anyway.

And on the usb stuff. Hotplug handles all of that quite nicely.

Either way, supermount isnt really needed. For advanced users you just mount it yourself, for newbies just give them kde or gnome and let that handle the mounting of the cdrom (not sure wether gnome can but i'd guess it can)

Pretty simple really.

How about unmounting?

Anonymous
on
May 9, 2004 - 3:22am

Ok, mounting is not that hard, but what about unmounting?

When I push the eject button I expect the CD to be ejected (the user should be in control, right?), but this does not work with a stock kernel when the CD is still mounted. I'm working around this by using automount with a mount expiration time of 10 seconds, so with some luck I can get my CD back 10 seconds after the latest access, but it's far from ideal.

Microsoft wrote a specification for an ATA extension called Media Status Notification Support Specification v1.03. This extension allows the CPU to poll the drive to see if the user pressed a button or inserted new media.

Has it ever been considered to write a daemon to do this (say, once a second) for drives that support it? When an event occurs, it would take action like mount on new media, unmount & eject on button press. Perhaps this could even be integrated with the hotplug system.

magicdev

gebner
on
May 9, 2004 - 4:02am

Has it ever been considered to write a daemon to do this (say, once a second) for drives that support it? When an event occurs, it would take action like mount on new media, unmount & eject on button press. Perhaps this could even be integrated with the hotplug system.

I think that's called magicdev, and AFAIK RedHat/Fedora is shipping it.

RE: magicdev

Anonymous
on
May 10, 2004 - 1:10am

Debian ships it too and AFAIK you can use it regardless of DE that's running.

mandrake ships it as well..bu

Anonymous
on
August 14, 2004 - 5:38pm

mandrake ships it as well..but you know...supermount is still nicer.
The problem is...there needs to be a low lvl implementation. And i want it to work with writable media as well. And i want to get rid of magicdevs bugs when manually mounting media or doing other slightly more advance things than push a CD into the tray.

submount

mjt
on
May 10, 2004 - 8:07am

Like this:
http://submount.sf.net
or?

-- 
Markus Törnqvist

Floppies

Anonymous
on
May 15, 2004 - 9:56pm

What about floppies? I've always had a problem with forgetting to unmount floppies before removal, or having to turn on monitor to unmount and remove a floppy that I placed in the drive before.

Re: Floppies

Anonymous
on
May 17, 2004 - 6:10am

i always use mtool for dos disks (mdir, mcopy, ...) and just tar on the dev file for unix, so no need to mount or unmount.

But Linux just has NO HOPE on

Anonymous
on
May 9, 2004 - 4:24pm

But Linux just has NO HOPE on the desktop until the user has to use mount to read cdroms, edit /etc/X11/XF86Config to have a working xserver and to be root to do "modprobe usbcore; mount none -t usbdevfs proc/bus/usb" to have the digital camera working

I hear this argument a lot. Remind me why I should care?

Ok.

Anonymous
on
May 9, 2004 - 5:51pm

I guess that you are happy with your WindowsXP copy.

After all, why should we use Linux, as it doesn't even support
latest Palladium technology?

*rolleyes*

Anonymous
on
May 10, 2004 - 1:19am

But Linux just
has NO HOPE on the desktop until the user has to use mount to read cdroms,

Let's see. On a GNOME-Desktop you just do a righclick on Desktop, select "drives" (german variant is "Platten" so I assume english is "drives") and select the CD-ROM or other device you want to mount. Even easier is it to just install Magicdev and have CD/DVD-ROM drives automagically mounted.

With a KDEnvironment it's just as easy.

And there's hotplug that can integrate devices.

btw. Windows rulez :-P

On a GNOME-Desktop you just d

florin
on
May 10, 2004 - 12:40pm

On a GNOME-Desktop you just do a righclick on Desktop, select "drives" (german variant is "Platten" so I assume english is "drives")

It's actually "Disks" - but yeah, the idea is right.

the idea

Anonymous
on
May 9, 2004 - 12:58pm

The idea of Super mount rocks, all the windows users I get to switch to Linux love it. The driver just needs work.

SuSe

Hiryu
on
May 7, 2004 - 9:32pm

There really isn't a problem with SuSe. I've never had _any_ problems going to a stock kernel that didn't have reiserfs attributes. I only find SuSe annoying in that if I use a stock kernel, I'll get some trivial failures during boot. Mostly or all just modules it tries to load when I've built the features directly into the kernel is all.

I just wish SuSe had something like Debian make-kpkg and was overall more friendly to custom stock/vanilla kernels.

SuSe

Anonymous
on
May 10, 2004 - 4:41am

> I'll get some trivial failures during boot

I am not an expert, but I have had the best luck with SuSE by patching the standard kernel with mjb. I then adjust the startup by hand (ie remove the SuSE scripts for options I compile in).

Mike

Did he mean to write "due" ?

Anonymous
on
May 8, 2004 - 3:51am

It seems to me that "do" doesn't quite make sense in the above context. Did the author intend to write "due"?

Re: Did he mean to write "due"?

Jeremy
on
May 8, 2004 - 4:58am

Yes, fixed.

supermount on desktop

Anonymous
on
May 8, 2004 - 10:34am

I build my kernels all by myself, and since Im a lazy git, i patch them with supermount-ng. Desktop-users shouldn't need to mount cdroms themselves. Let the kernel handle it.

Why kernel???

Anonymous
on
May 10, 2004 - 5:53am

Desktop-users shouldn't need to mount cdroms themselves. Let the kernel handle it.

Why should kernel handle it? What about putting an office suite to kenrel -- it could make it start faster, and that's what desktop users definitely want...

The only thing kernel probably should do is some notification the eject button was pressed for unmount.

slackware

Anonymous
on
May 9, 2004 - 9:21am

Slackware always worked fine with stock kernels. Af far as I know it's also distributed with a stock kernel. Yes, it has some special kernels with new features in them but they're optional.

Debian also works fine with stock kernels.

The problems is with distributions like Mandrake, RedHat, SuSE which ship with a heavily modified kernel. As far as I've heard RedHat also works ok with stock kernels.

RedHat?? Fedora???

Anonymous
on
May 16, 2004 - 7:48am

RedHat 9 and Fedora does not work so well (with 2.4). They do boot, but Berkeley DB does not work as it has to, because of expecting NPTL in kernel.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.