[opensuse-kernel] Re: openSUSE Build Service
On 16.2.2010 21:44, Brian K. White wrote:
Hi,
Hi Brian, please use the opensuse-kernel mailing list (an pick a better subject next time...). I also added Jiri, who maintains the lxc package in Factory.
cgroup support is missing from the desktop kernel. Is this intentional or accidental?
Intentional, see https://features.opensuse.org/305694 and http://gitorious.org/opensuse/kernel-source/commit/c065c52q1 .
It breaks LXC which requires it. All other LXC options are enabled in the desktop kernel but the one can't work without the other so you might as well turn the other lxc options off also, or turn cgroup on.
BTW, which are these options?
I'm checking now to see if the previous desktop kernel had cgroup or not. I don't remember seeing this problem before, but I have only started using lxc since 11.2 and I normally override the default and install the now mis-named "default" kernel anyways so I don't know maybe this has always been the case and maybe I only just now noticed.
That said, regardless if the desktop kernel is intended or not, or continues or not, to to include cgroup support, since there are packages that depend on the feature, and there is no file I know of that can be checked for in a spec file Requires: field, I think there should be a flag in the spec/rpm files for the kernels that says they provide the feature or not, so that other packages can say "Requires: cgroup" and they don't care which specific kernel you install, merely that you are running a kernel that includes the facility. There are ways to check the running kernel of course like "grep cgroup /proc/filesystems" but I don't think a spec file can be told to run a test like that as part of the "requires:" field. Maybe %pre or %prein are the place for a test like that? But putting a dependency in Requires: ensures that even when the user goes to install some other kernel later after lxc is already installed, if the new kernel is not also "kernel-default" rpm will notice and try to either prevent the install or remove lxc along with the old kernel to maintain a consistent system.
The problem with userspace packages depending on certain kernel features or versions is that it doesn't really do what you want. You can express a dependency on an installed package, but what really matters is the running kernel, which rpm can't test for. Also if you depend on a certain kernel flavor (or some virtual capability provided by some flavors), the effect would be that the installer would install the desired kernel flavor _alongside_ with the "wrong" flavor, because different kernel flavors don't conflict with each other. Just something to keep in mind.
Currently for my own updated lxc package in build service home:aljex, I am specifying "Requires: kernel-default" which is wrong but ensures that lxc will work. And then I am also performing the /proc/filesystems check at run-time in my lxc init script just to be sure.
Thanks
Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Michal Marek wrote:
On 16.2.2010 21:44, Brian K. White wrote:
Hi,
Hi Brian,
please use the opensuse-kernel mailing list (an pick a better subject next time...). I also added Jiri, who maintains the lxc package in Factory.
Ah sorry the web link on the OBS page autofilled that and I never even looked at it.
cgroup support is missing from the desktop kernel. Is this intentional or accidental?
Intentional, see https://features.opensuse.org/305694 and http://gitorious.org/opensuse/kernel-source/commit/c065c52q1 .
OK I see now. So it's performance overhead and it's uncommon utility make it one of the things it makes sense to remove from a desktop-tuned kernel. Ok no problem. Then the question becomes, why, when I choose the "minimal text-only system" during install, and make no other software choices, do I get the desktop kernel instead of the server one? If that target isn't a "server" target, what is?
It breaks LXC which requires it. All other LXC options are enabled in the desktop kernel but the one can't work without the other so you might as well turn the other lxc options off also, or turn cgroup on.
BTW, which are these options?
Got me there. I knew there were several options that needed to be enabled and I knew they all were, but I hadn't actually gone over them. I see now none of them look lxc-specific. Sorry for _that_ noise.
The problem with userspace packages depending on certain kernel features or versions is that it doesn't really do what you want. You can express a dependency on an installed package, but what really matters is the running kernel, which rpm can't test for. Also if you depend on a certain kernel flavor (or some virtual capability provided by some flavors), the effect would be that the installer would install the desired kernel flavor _alongside_ with the "wrong" flavor, because different kernel flavors don't conflict with each other. Just something to keep in mind.
hmm? I thought all along you could depend on say, a file, say, /bin/ksh, and it doesn't matter how that file got there, rpm is satisfied. And if it's not there, then one of the several possible packages that each supply that file (bash supplies a symlink which is a lie and that I hate that it does that..., and pdksh, and of course ksh93 (zsh too but I don't know offhand if opensuse's rpm of it does) all also can supply their own version of the same file. When it's missing and a package depends on it, ... I don't know what happens. I'll go mock up a test now and answer my own question. Maybe what I can do is have the lxc package do a test at install-time in %prein, toss up a message telling the user what to do, and then abort/fail the install? That way it isn't simply installable broken, nor do I force a bad requirement of any specific kernel to the exclusion of any other. -- bkw -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Thursday 18 February 2010 08:06:43 Brian K. White wrote:
Then the question becomes, why, when I choose the "minimal text-only system" during install, and make no other software choices, do I get the desktop kernel instead of the server one? If that target isn't a "server" target, what is?
Good question - let's discuss it on either opensuse-factory or open a bugreport for it, Andreas -- Andreas Jaeger, Program Manager openSUSE, aj@{novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On 18.2.2010 08:06, Brian K. White wrote:
Michal Marek wrote:
On 16.2.2010 21:44, Brian K. White wrote:
Hi,
Hi Brian,
please use the opensuse-kernel mailing list (an pick a better subject next time...). I also added Jiri, who maintains the lxc package in Factory.
Ah sorry the web link on the OBS page autofilled that and I never even looked at it.
cgroup support is missing from the desktop kernel. Is this intentional or accidental?
Intentional, see https://features.opensuse.org/305694 and http://gitorious.org/opensuse/kernel-source/commit/c065c52q1 .
OK I see now. So it's performance overhead and it's uncommon utility make it one of the things it makes sense to remove from a desktop-tuned kernel. Ok no problem.
Then the question becomes, why, when I choose the "minimal text-only system" during install, and make no other software choices, do I get the desktop kernel instead of the server one? If that target isn't a "server" target, what is?
It breaks LXC which requires it. All other LXC options are enabled in the desktop kernel but the one can't work without the other so you might as well turn the other lxc options off also, or turn cgroup on.
BTW, which are these options?
Got me there. I knew there were several options that needed to be enabled and I knew they all were, but I hadn't actually gone over them. I see now none of them look lxc-specific. Sorry for _that_ noise.
The problem with userspace packages depending on certain kernel features or versions is that it doesn't really do what you want. You can express a dependency on an installed package, but what really matters is the running kernel, which rpm can't test for. Also if you depend on a certain kernel flavor (or some virtual capability provided by some flavors), the effect would be that the installer would install the desired kernel flavor _alongside_ with the "wrong" flavor, because different kernel flavors don't conflict with each other. Just something to keep in mind.
hmm? I thought all along you could depend on say, a file, say, /bin/ksh, and it doesn't matter how that file got there, rpm is satisfied. And if it's not there, then one of the several possible packages that each supply that file ...
The difference is that if you have a script that needs /bin/ksh, the package manager will install ksh alongside with bash and your script can use it right away. Now if you depend on a certain kernel flavor, the package manager will install that flavor alongside with kernel-desktop, but your package won't work until the user reboots into the right kernel flavor. So you have to handle missing kernel features in the application anyway.
Maybe what I can do is have the lxc package do a test at install-time in %prein, toss up a message telling the user what to do, and then abort/fail the install?
That way it isn't simply installable broken, nor do I force a bad requirement of any specific kernel to the exclusion of any other.
Please don't fail %pre/%post scripts intentionally. Displaying an error message is fine, but if the script fails, then you'll just annoy users who launch install of several packages and expect it to work unattended. Also you should print the error message in the init script, because as I said above the installed kernel is not necessarily the running kernel. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Michal Marek wrote:
On 18.2.2010 08:06, Brian K. White wrote:
Michal Marek wrote:
On 16.2.2010 21:44, Brian K. White wrote:
Hi, Hi Brian,
please use the opensuse-kernel mailing list (an pick a better subject next time...). I also added Jiri, who maintains the lxc package in Factory. Ah sorry the web link on the OBS page autofilled that and I never even looked at it.
cgroup support is missing from the desktop kernel. Is this intentional or accidental? Intentional, see https://features.opensuse.org/305694 and http://gitorious.org/opensuse/kernel-source/commit/c065c52q1 . OK I see now. So it's performance overhead and it's uncommon utility make it one of the things it makes sense to remove from a desktop-tuned kernel. Ok no problem.
Then the question becomes, why, when I choose the "minimal text-only system" during install, and make no other software choices, do I get the desktop kernel instead of the server one? If that target isn't a "server" target, what is?
It breaks LXC which requires it. All other LXC options are enabled in the desktop kernel but the one can't work without the other so you might as well turn the other lxc options off also, or turn cgroup on. BTW, which are these options? Got me there. I knew there were several options that needed to be enabled and I knew they all were, but I hadn't actually gone over them. I see now none of them look lxc-specific. Sorry for _that_ noise.
The problem with userspace packages depending on certain kernel features or versions is that it doesn't really do what you want. You can express a dependency on an installed package, but what really matters is the running kernel, which rpm can't test for. Also if you depend on a certain kernel flavor (or some virtual capability provided by some flavors), the effect would be that the installer would install the desired kernel flavor _alongside_ with the "wrong" flavor, because different kernel flavors don't conflict with each other. Just something to keep in mind. hmm? I thought all along you could depend on say, a file, say, /bin/ksh, and it doesn't matter how that file got there, rpm is satisfied. And if it's not there, then one of the several possible packages that each supply that file ...
The difference is that if you have a script that needs /bin/ksh, the package manager will install ksh alongside with bash and your script can use it right away. Now if you depend on a certain kernel flavor, the package manager will install that flavor alongside with kernel-desktop, but your package won't work until the user reboots into the right kernel flavor. So you have to handle missing kernel features in the application anyway.
Maybe what I can do is have the lxc package do a test at install-time in %prein, toss up a message telling the user what to do, and then abort/fail the install?
That way it isn't simply installable broken, nor do I force a bad requirement of any specific kernel to the exclusion of any other.
Please don't fail %pre/%post scripts intentionally. Displaying an error message is fine, but if the script fails, then you'll just annoy users who launch install of several packages and expect it to work unattended. Also you should print the error message in the init script, because as I said above the installed kernel is not necessarily the running kernel.
Michal
Got it. So I can actually continue depending on kernel-default and it's merely a little inefficient in that it may sit there unused if the user has some other kernel that works. rpm will bring it in, but not make it the default and not remove the desktop one. Then I perform a cgroup test at run-time just so that when it fails I can put up a simpler message than what lxc-start will generate, that makes it as easy as possible to know what to do. Also perheps more importantly so I can avoid even trying to run lxc-start or lxc-execute which might leave a bit of a mess behind or hang etc. No test or failure at install time. Although a notice that doesn't require user input might be good even though many/most never see such. Lastly just make sure it's clearly documented in any likely place a person encountering the failure or looking to try using lxc for the first time might look. ie the main man-page and googled up docs. That part is already true. -- bkw -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
participants (3)
-
Andreas Jaeger
-
Brian K. White
-
Michal Marek