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
Huh?
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.
"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
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...
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
I have always had problems with Mandrake's and Red Hat's kernels also.
Wow
Nice trolling in this thread. Too bad no moderation has been brought back yet.
Mandrake is not the problem
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
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
lol...thats bullshit
Supermount is a hack, NOT evil
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
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
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
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
This is a very good idea.
User Mounting
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?
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
I think that's called magicdev, and AFAIK RedHat/Fedora is shipping it.
RE: magicdev
Debian ships it too and AFAIK you can use it regardless of DE that's running.
mandrake ships it as well..bu
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
Like this:
http://submount.sf.net
or?
Floppies
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
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
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.
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*
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
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
The idea of Super mount rocks, all the windows users I get to switch to Linux love it. The driver just needs work.
SuSe
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
> 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" ?
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"?
Yes, fixed.
supermount on desktop
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???
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
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???
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.