I really appreciate your feedback but you seem to prefer writing mails instead of trying what I wrote. [Mika]
Because 2.6.21 is not going to help us even if it works; I need more data; it's not the only test; and Linux ++ fixes anything but is not a distro. My users need grml repos, 0.9 or 1.0. They can't function with 2.6.21. Communication & research is all that's possible anyway. Memorial Day vacation - I'm packing now. (Incidentally: verified as kernel regression under Ubuntu 7.04; same problems.)
During beta I would have done as requested to improve 1.0 final. Grml gave me no task, no suspect kernel config flags to isolate, etc. Radio silence made me hungry for info-crumbs...
But a broken (from our standpoint) final release makes me ask how grml beta cycles are supposed to work. I just need to know what grml does/thinks so I can work with, or around the philosophy & constraints involved.
Beta cycles are meant to catch bugs before release. Kernel regression is just another bug category. A kernel regression which, for instance, broke your laptop, would prevent a grml release. And that is how it should be.
Re bisect: Other people do that coordinated by -stable. My job is sysadmin, not kernel dev. The whole point of Linux for us, rather than BSD or Open Solaris or Nexenta or whatever, is hardware support. If we have to become kernel devs too, supporting/debugging our own hardware, then we would consider other kernels to develop, with possibly more rational code. Note about USB in Linux, "the in-kernel USB interfaces have undergone at least three different reworks over the lifetime of this subsystem" (Greg Kroah-Hartman). Anyway it's not my call. The last thing my boss will allow is debugging Linux hardware drivers.
What I'm asking is, do you inspect a grml bug report, and then talk to -stable to see if they have anything related in their pipeline, and then decide whether grml should wait for a patch?
Looking at -stable patch-2.6.20.12, I see USB fixes relating to mutexes, IRQs, etc. - the big stuff.
What -stable version is 2.6.20-grml in grml 1.0 final?
Next, how does Debian fit into all this? Grml tracks Debian unstable. But grml releases are tied to Linus's kernel releases, not Debian kernel work, right? Correct me on anything.
Does grml kernel customization include the possibility of using a -stable release that is not yet incorporated into Debian? Or is Debian a limiting factor?
Dumb question maybe, but if I compile my own 2.6.20-x using grml source and patched from -stable, will it work with grml 2.6.20-grml repos? I'm willing to compile a kernel but if I start having to build repos too, I've already become a custom distro, and I'd rather not.
Thanks - see you a week from now.
Mark
* Mark 27e3kk302@sneakemail.com [20070526 10:15]:
I really appreciate your feedback but you seem to prefer writing mails instead of trying what I wrote. [Mika]
[...]
During beta I would have done as requested to improve 1.0 final. Grml gave me no task, no suspect kernel config flags to isolate, etc. Radio silence made me hungry for info-crumbs...
How often do I have to write this again? I had no idea where the problem derived from.
Beta cycles are meant to catch bugs before release. Kernel regression is just another bug category. A kernel regression which, for instance, broke your laptop, would prevent a grml release. And that is how it should be.
Just because one single device does not work anymore (notice: "broke your laptop" is different from "my external harddisk can't be accessed") without any relevant changes in the kernel configuration it won't become a release-stopper for everyone out there.
Re bisect: Other people do that coordinated by -stable. My job is sysadmin, not kernel dev. The whole point of Linux for us, rather than BSD or Open Solaris or Nexenta or whatever, is hardware support. If we have to become kernel devs too, supporting/debugging our own hardware, then we would consider other kernels to develop, with possibly more rational code. Note about USB in Linux, "the in-kernel USB interfaces have undergone at least three different reworks over the lifetime of this subsystem" (Greg Kroah-Hartman). Anyway it's not my call. The last thing my boss will allow is debugging Linux hardware drivers.
Again, you seem to prefer writing mails instead of running those fscking 4 commands. You don't have to become a kernel dev for installing a kernel and test it once.
What I'm asking is, do you inspect a grml bug report, and then talk to -stable to see if they have anything related in their pipeline, and then decide whether grml should wait for a patch?
The stable-queue is available via git before being available as new official -stable release. I track that of course to be able to decide about kernel update/freeze.
Looking at -stable patch-2.6.20.12, I see USB fixes relating to mutexes, IRQs, etc. - the big stuff.
.12 does not include anything else than a bugfix for GEODE-AES: http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.20.12
What -stable version is 2.6.20-grml in grml 1.0 final?
It's all documented on http://grml.org/kernel/ - 2.6.20.11.
Next, how does Debian fit into all this? Grml tracks Debian unstable.
grml is based on Debian.
But grml releases are tied to Linus's kernel releases, not Debian kernel work, right? Correct me on anything.
grml's kernel has nothing to do with the one from Debian.
Does grml kernel customization include the possibility of using a -stable release that is not yet incorporated into Debian? Or is Debian a limiting factor?
Sorry, I don't understand your question. grml and Debian regarding the kernel are two different things.
Dumb question maybe, but if I compile my own 2.6.20-x using grml source and patched from -stable, will it work with grml 2.6.20-grml repos? I'm willing to compile a kernel but if I start having to build repos too, I've already become a custom distro, and I'd rather not.
Everything not containing '*2.6.20*' inside the package name/version can be used without any further changes. Only kernel modules build against the official 2.6.20-grml kernel can't be used any further.
regards, -mika-
Hi Mika,
I've returned from vacation. Good news on bug isolation.
Booting grml 1.0 final CD-ROM with "noudev" made USB behave normally. So: the bug may be udev rules rather than a kernel regression. (We can discuss privately.)
About the fscking test: it would not have helped us here, while other tests had real help potential (2.6.20-stable releases, kernel flags, boot options). The next beta will have 2.6.22 anyway, and being a full distro, can deploy to my users.
2.6.21-plus-grml-1.0 is not a distro. We need pre-built packages and modules, not some kernel++ that requires me to build them. I can't support users that way. Small -stable increments, maybe; that was why I asked.
.12 does not include anything else than a bugfix for GEODE-AES: http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.20.12
The particular delta number did not matter. My thrust was that recent and significant USB activity in 2.6.20-x (stable patches) meant USB bugs were *NOT* specific to our hardware.
Wernfried - impossible perfection is beside the point. A beta program needs to avoid sweeping assumptions about weird hardware and kernel regressions. Otherwise there's no utility in it. Many bugs are just dumb typos in scripts and config files...like udev rules.
Thanks again, M
* Mark 27e3kk302@sneakemail.com [20070621 09:45]:
I've returned from vacation. Good news on bug isolation.
Booting grml 1.0 final CD-ROM with "noudev" made USB behave normally. So: the bug may be udev rules rather than a kernel regression. (We can discuss privately.)
Thanks for isolating that and for your f'up on http://bts.grml.org/grml/issue203 - let's continue the topic there.
About the fscking test: it would not have helped us here, while other tests had real help potential (2.6.20-stable releases, kernel flags, boot options). The next beta will have 2.6.22 anyway, and being a full distro, can deploy to my users.
2.6.21-plus-grml-1.0 is not a distro. We need pre-built packages and modules, not some kernel++ that requires me to build them. I can't support users that way. Small -stable increments, maybe; that was why I asked.
For sure, the 2.6.21 kernel test was meant as bug isolator and not as "use that as your new stable kernel". :)
thx && regards, -mika-
On Sat, May 26, 2007 at 12:28:53AM -0700, Mark wrote:
Beta cycles are meant to catch bugs before release. Kernel regression is just another bug category. A kernel regression which, for instance, broke your laptop, would prevent a grml release. And that is how it should be.
Following that logic, there's always some minor bug in some kernel which would be a release stopper. Debian stable goes into that direction, and that's why there's a release that is "outdated" and only every now and then. Grml's focus is different, including an up to date kernel, which will never be completely bug free. So please, stop beating a dead horse.
I know life sucks sometimes, but sometimes getting a helmet is the best solution. ;-)
cheers, Wernfried
participants (3)
-
Mark -
Michael Prokop -
Wernfried Haas