-
Notifications
You must be signed in to change notification settings - Fork 224
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OS detection fails for Debian Bookworm #1606
Comments
See https://serverfault.com/questions/817005/debian-8-no-lsb-modules-are-available for why |
This seems to be an issue with some systems (debian in this case specifically), not suppressing the error message regarding "No LSB modules are available". For instance on Ubuntu, that message is output, but if you specify the '-s -i' options, the message is suppressed. |
Thanks @dboehmer for the report, and @numberwhun for an initial triaging! I finally could get around to obtaining an official Debian 12 image and reproduce the issue too at first. After much investigation, though, I don't believe it's a bug, but a missing feature flag for modern Rex features. TL;DRI only could reproduce the situation with For SSH connections, the original/default behavior is to allocate a tty, but that makes the distinction between remote STDOUT and STDERR streams impossible. Due to all the problems this causes, since Rex-1.0.0 the default is to don't allocate a tty. This is not a backwards compatible change in behavior therefore one must opt-in for it via either a feature flag or feature bundle (much like how Perl features work too). Please try the same Rex task with one of the following Rex imports: use Rex -feature => ['1.4']; # enable 1.4 feature bundle
use Rex -feature => ['no_tty']; # disable only tty allocation and let me know how that works. Also feel free to reach out on other support channels (Matrix/IRC, open source office hours, etc.) for possibly faster feedback loops. Long versionFirst impressionsThe problem is indeed about Rex currently takes the output of this command literally without distinction between STDERR and STDOUT. The returned values are used to choose the matching package- and service-management provider modules from the Rex::Pkg and Rex::Service namespaces, respectively. For example, in case of the example here it literally looks for a module named I'm not yet sure how to write a failing test for this case yet, but I expect one or more of the following would be interesting to check for a solution:
What I don't entirely like about suppressing the STDERR output as a whole, is that it may mask other errors on every other OSes too, not just Perhaps a viable alternative would be to specifically filter out this known-to-be-accepted error message from the output instead. It feels a bit dirty too at first, but at least it would allow meaningful failures through for other cases. Deeper lookThere is a an
The actual problemThinking more about the previous point, I noticed the provided example did not include a full Rexfile, but only a sample task. That means, I had to make a guess about the exact With the vanilla Looking at the list of available feature flags, I was sure something between 0.0.0 and 1.4.0 causes the different behavior. Since 1.0, part of the default feature set is to don't allocate a tty for the SSH connections. With tty enabled on the underlying connection based on Net::SSH2 or Net::OpenSSH, always the combined STDOUT+STDERR output is returned without any way to make a distinction between the separate streams. Hence the new default from 1.0 onwards to disable tty on SSH connections. Due to preserving backwards compatibility, these improvements are always opt-ins via feature flags or feature bundles (much like how |
I confirmed that
solved the issue. Sorry for not including the boilerplate in my test code. I didn’t think of it that this might have an effect on the issue. |
Great! 🎉 Thanks for confirming!
No worries, it was still a valuable learning experience to track down the root cause despite the less-than-ideal starting point. In case we bump into this situation more often, we might want to update the issue template to ask for more like a "fully copy-pasteable example to run" (like a minimal Rexfile), instead of the "shortest possible" one (which sometimes might be considered only a task without further context). There are already tests for the |
Describe the bug
I upgraded a server of mine to Debian 12 Bookworm and started my Rexfile. After some steps Rex fails because it does not correctly detect Debian 12.
Output of test file from below (redacted):
Expected behavior
Old behavior with Debian 11 Bullseye (output redacted):
How to reproduce it
Code example
Test Rexfile:
Additional context
Rex/lib/Rex/Hardware/Host.pm
Line 113 in d157dcc
lsb_release -s -i
for detecting the OS. Output via SSH is the sameDebian
for both host OS versions. But when run in an interactive terminal the behavior changed:The method
is_debian()
inlib/Rex/Commands/Gather.pm
receives the stringNo LSB modules are available.\nDebian
with a literal newline character as argument.As a workaround I monkeypatched the method to always return true. That way I was able to successfully run my Rexfile.
Rex version
(R)?ex 1.14.3
Perl version
5.34.0
Operating system running rex
Debian 11 Bullseye
Operating system managed by rex
Debian 12 Bookworm
How rex was installed?
cpan client
The text was updated successfully, but these errors were encountered: