make_image: log systemd-repart *.conf files at the --debug level#3993
make_image: log systemd-repart *.conf files at the --debug level#3993daandemeyer merged 1 commit intosystemd:mainfrom
Conversation
3d301a0 to
fb63d4d
Compare
|
1 random QEMU timeout just like in unrelated #3992 . It seems ToolsTreeDistribution is Fedora in most timeouts. Now 2 timeouts after re-run: Now just 1: Still not winning the lottery: 1 failing again: Finally all green! |
243d634 to
5d5c828
Compare
mkosi/__init__.py
Outdated
| lines = 0 | ||
| for line in f: | ||
| logging.debug(line.strip()) | ||
| lines += 1 |
There was a problem hiding this comment.
| lines = 0 | |
| for line in f: | |
| logging.debug(line.strip()) | |
| lines += 1 | |
| for lines, line in enumerate(f): | |
| logging.debug(line.strip()) |
though lines is then no longer a good name.
There was a problem hiding this comment.
Also, you could write something like truncated to X lines in the message above saying from which file this is and instead of enumerating lines do
for line in itertools.islice(f, 100):There was a problem hiding this comment.
Done.
As usual, QEMU from the Fedora ToolsTreeDistribution is hanging in 2 places.
https://github.com/systemd/mkosi/actions/runs/19315730637/job/55247012466?pr=3993
Last time I force-pushed and banged until they all passed but this is getting tedious :-(
There was a problem hiding this comment.
Last time I force-pushed and banged until they all passed but this is getting tedious :-(
You really don't need to. Sometimes CI is flaky, e.g. due to distro-specific problems, and in a lot of cases it is clear that the CI failure is not related to the change in the PR.
mkosi/__init__.py
Outdated
| for line in f: | ||
| logging.debug(line.strip()) | ||
| lines += 1 | ||
| if lines > 100: |
There was a problem hiding this comment.
That seems a bit arbitrary. Is the idea for it to be much longer than than all possible repart files? The number of directives for these files is about 40.
There was a problem hiding this comment.
It is arbitrary. Yes, the idea is for this to be longer than all "regular" repart files, as a safety to protect the debug logs and keep them usable, triggered only when something went terribly wrong. For instance: a wrong .conf file landing there by accident. Or some other bug. I can summarize this as a one-line comment in the source.
The number of directives for these files is about 40.
I don't get this sorry. Did you mean 40 lines? Is this an average?
There was a problem hiding this comment.
I don't get this sorry. Did you mean 40 lines? Is this an average?
That's just the rough amount of different directives for repart files. Even if you put multiple partitions in a file, which I've not seen done, to be honest, some of these directives are exclusive or dependent on others, so in general these files will be below 10 lines long.
2959afb to
7040a6a
Compare
|
Sample output: |
7040a6a to
4feb333
Compare
mkosi/__init__.py
Outdated
| logging.debug(f"\n === {c} ===") | ||
| with open(c) as f: | ||
| # Do not spam the logs in case something goes wrong | ||
| maxlines = 100 | ||
| for line in itertools.islice(f, maxlines): | ||
| logging.debug(line.strip()) | ||
|
|
||
| for anything_left in f: | ||
| logging.debug(f"=== {c.name} truncated to {maxlines} lines ===") | ||
| break |
There was a problem hiding this comment.
Let's shorten this somewhat, the truncation will never really be a thing
| logging.debug(f"\n === {c} ===") | |
| with open(c) as f: | |
| # Do not spam the logs in case something goes wrong | |
| maxlines = 100 | |
| for line in itertools.islice(f, maxlines): | |
| logging.debug(line.strip()) | |
| for anything_left in f: | |
| logging.debug(f"=== {c.name} truncated to {maxlines} lines ===") | |
| break | |
| logging.debug(f"# {c} (truncated to 100 lines)") | |
| with open(c) as f: | |
| for line in itertools.islice(f, 100): | |
| logging.debug(line.strip()) |
Using a # as the separator, makes these files still valid, when copied from screen.
As discussed in systemd#3948, systemd-repart *.conf files have default values which is convenient until this fails with some dreaded "disk full" error - then it becomes very mysterious. To considerably speed up the investigation about what exactly is full, show the configuration files in use when using --debug. Signed-off-by: Marc Herbert <marc.herbert@intel.com> (cherry picked from commit 7040a6a) Signed-off-by: Marc Herbert <marc.herbert@intel.com>
4feb333 to
2a2ef55
Compare
As discussed in #3948, systemd-repart *.conf files have default values which is convenient until this fails with some dreaded "disk full" error - then it becomes very mysterious. To considerably speed up the investigation about what exactly is full, show the configuration files in use when using --debug.