[Bug 1166406] New: Consider moving /boot/vmlinux-*.xz to a different package
http://bugzilla.suse.com/show_bug.cgi?id=1166406 Bug ID: 1166406 Summary: Consider moving /boot/vmlinux-*.xz to a different package Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-maintainers@forge.provo.novell.com Reporter: fvogt@suse.com QA Contact: qa-bugs@suse.de CC: jeos-internal@suse.de Found By: --- Blocker: --- Currently the kernel is installed twice into /boot (at least on x86_64 and arm64), once as self-decompressing vmlinuz and then the raw compressed kernel as vmlinux.xz The latter isn't needed for booting and only used for debugging or by using special tools (AFAIK, please correct me if I'm wrong), so not useful on most systems. Especially with kernel-default-base, this ~10MiB file is almost 30% of the whole package in size, so dropping/moving that would have a noticeable impact on size reduction. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166406 Ludwig Nussel <lnussel@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lnussel@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166406 http://bugzilla.suse.com/show_bug.cgi?id=1166406#c1 Takashi Iwai <tiwai@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jeffm@suse.com, | |msuchanek@suse.com, | |tiwai@suse.com --- Comment #1 from Takashi Iwai <tiwai@suse.com> --- Sounds like a good idea. Not sure where vmlinux*.xz should be moved to, though. I thought crash utility required vmlinux, but it's obviously for debugging. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166406 http://bugzilla.suse.com/show_bug.cgi?id=1166406#c2 --- Comment #2 from Michal Suchanek <msuchanek@suse.com> --- is it not needed for some *trace? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166406 http://bugzilla.suse.com/show_bug.cgi?id=1166406#c3 Takashi Iwai <tiwai@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tonyj@suse.com --- Comment #3 from Takashi Iwai <tiwai@suse.com> --- Maybe Tony knows of such? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166406 http://bugzilla.suse.com/show_bug.cgi?id=1166406#c4 --- Comment #4 from Jeff Mahoney <jeffm@suse.com> --- It's needed for pretty much anything that needs a symbol table (and also the -debuginfo package). -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166406 http://bugzilla.suse.com/show_bug.cgi?id=1166406#c5 --- Comment #5 from Michal Suchanek <msuchanek@suse.com> --- The point here is if also -debuginfo package is needed it can be moved there or some other -debugwhatever. If there are tools that can work with the vmlinux only then those will break. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166406 http://bugzilla.suse.com/show_bug.cgi?id=1166406#c6 --- Comment #6 from Jeff Mahoney <jeffm@suse.com> --- I can't imagine what utility those tools could have. vmlinux should have the debuginfo stripped out. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166406 http://bugzilla.suse.com/show_bug.cgi?id=1166406#c7 --- Comment #7 from Michal Suchanek <msuchanek@suse.com> --- I don't think you need debuginfo for profiling. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166406 http://bugzilla.suse.com/show_bug.cgi?id=1166406#c8 --- Comment #8 from Jeff Mahoney <jeffm@suse.com> --- It appears perf top uses /proc/kcore to do its annotation and /proc/kallsyms to get the symbol table, for example. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166406 http://bugzilla.suse.com/show_bug.cgi?id=1166406#c9 Michal Suchanek <msuchanek@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mls@suse.com Flags| |needinfo?(mls@suse.com) --- Comment #9 from Michal Suchanek <msuchanek@suse.com> --- There is one last problem: If vmlinux is needed for debugging only how do we ensure it's installed with the debuginfo package if we package it separately? debuginfo packages are created automagically so it's difficult to inject additional dependencies or files. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166406 http://bugzilla.suse.com/show_bug.cgi?id=1166406#c10 --- Comment #10 from Tony Jones <tonyj@suse.com> --- (In reply to Jeff Mahoney from comment #4)
It's needed for pretty much anything that needs a symbol table (and also the -debuginfo package).
for perf, /proc/kallsyms is generally used (subject to kptr_restrict. debuginfo vmlinux is used for annotation i'd need to look closer at what exactly systemtap can do, without vmlinux, without the debug version the answer is usually very little (some trace point stuff). I think it's best to move slowly here. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166406 http://bugzilla.suse.com/show_bug.cgi?id=1166406#c11 --- Comment #11 from Tony Jones <tonyj@suse.com> --- (In reply to Michal Suchanek from comment #5)
If there are tools that can work with the vmlinux only then those will break.
Correct. Hence my previous comment about moving slowly here. It may well be that most of these have been converted over to the various /proc interfaces (when full debuginfo isn't needed) but we should check. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166406 http://bugzilla.suse.com/show_bug.cgi?id=1166406#c12 --- Comment #12 from Tony Jones <tonyj@suse.com> --- For systemtap, man 3 stapprobes breaks down what stap functions need DWARF (i.e debuginfo) and what need symbol table (i.e stripped vmlinux). Systemtap doesn't use /proc (like perf) for symbol-table info as it supports cross-instrumentation. I've never actually looked at this as I always install debuginfo but as you can see below, systemtap does make use of the stripped vmlinux in question (though it needs to be manually uncompressed) Obviously we could ship this stripped vmlinux in a separate package and have systemtap depend on it (as we do for kernel-devel which is necessary to compile "hello world") whether other tools make use of the stripped vmlinux is maybe a question for kernel list, there may well be some I'm not aware of ------------------------------ # cat do_fork.stp probe kernel.function("_do_fork"){ if (@defined($clone_flags)) printf("do_fork: clone_flags=0x%lx\n", $clone_flags); else printf("do fork: no dwarf\n"); } # ls -l /boot/vmlinux-4.12.14-197.34-default /usr/lib/debug/boot/vmlinux-4.12.14-197.34-default.debug ls: cannot access '/boot/vmlinux-4.12.14-197.34-default': No such file or directory ls: cannot access '/usr/lib/debug/boot/vmlinux-4.12.14-197.34-default.debug': No such file or directory # stap do_fork.stp semantic error: while resolving probe point: identifier 'kernel' at /home/tonyj/stap/do_fork.stp:1:7 source: probe kernel.function("_do_fork"){ ^ semantic error: missing x86_64 kernel/module debuginfo [man warning::debuginfo] under '/lib/modules/4.12.14-197.34-default/build' Pass 2: analysis failed. [man error::pass2] # ls -l /boot/vmlinux-4.12.14-197.34-default /usr/lib/debug/boot/vmlinux-4.12.14-197.34-default.debug ls: cannot access '/usr/lib/debug/boot/vmlinux-4.12.14-197.34-default.debug': No such file or directory -rw-r--r-- 1 root root 51122824 Mar 12 09:51 /boot/vmlinux-4.12.14-197.34-default # stap --poison-cache do_fork.stp do fork: no dwarf ^C # ls -l /boot/vmlinux-4.12.14-197.34-default /usr/lib/debug/boot/vmlinux-4.12.14-197.34-default.debug -rw-r--r-- 1 root root 51122824 Mar 12 09:51 /boot/vmlinux-4.12.14-197.34-default -rw-r--r-- 2 root root 370477552 Feb 25 09:27 /usr/lib/debug/boot/vmlinux-4.12.14-197.34-default.debug # # stap --poison-cache do_fork.stp do_fork: clone_flags=0x1200011 ^C -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166406 http://bugzilla.suse.com/show_bug.cgi?id=1166406#c13 Jiri Slaby <jslaby@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jslaby@suse.com --- Comment #13 from Jiri Slaby <jslaby@suse.com> --- When I added support for xz compression of vmlinux in bug 1155921, I investigated and only kdump and crash read it. kdump only copies the image to /var/crash/... crash uncompresses it and reads symbols from there. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166406 http://bugzilla.suse.com/show_bug.cgi?id=1166406#c14 --- Comment #14 from Jiri Slaby <jslaby@suse.com> --- (In reply to Michal Suchanek from comment #5)
The point here is if also -debuginfo package is needed it can be moved there
I am strongly against moving it to -debuginfo. I don't want to download gigabytes just because of few MBs. I often live w/o debuginfo when debugging, symbols are far enough.
or some other -debugwhatever.
But this is OK by me. Maybe simply -vmlinux. pesign-obs-integration might need a change when the location or rpm name changes too. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166406 http://bugzilla.suse.com/show_bug.cgi?id=1166406#c15 --- Comment #15 from Tony Jones <tonyj@suse.com> --- (In reply to Jiri Slaby from comment #13)
When I added support for xz compression of vmlinux in bug 1155921, I investigated and only kdump and crash read it.
Per comment 12, this is clearly not true. I don't thinking moving it to debuginfo is a good idea. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166406 http://bugzilla.suse.com/show_bug.cgi?id=1166406#c16 --- Comment #16 from Jiri Slaby <jslaby@suse.com> --- (In reply to Tony Jones from comment #15)
(In reply to Jiri Slaby from comment #13)
When I added support for xz compression of vmlinux in bug 1155921, I investigated and only kdump and crash read it.
Per comment 12, this is clearly not true.
Right, I broke it by bug 1155921 then. I will fix it. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166406 http://bugzilla.suse.com/show_bug.cgi?id=1166406#c17 Jiri Slaby <jslaby@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(tonyj@suse.com) --- Comment #17 from Jiri Slaby <jslaby@suse.com> --- (In reply to Tony Jones from comment #12)
# stap do_fork.stp semantic error: while resolving probe point: identifier 'kernel' at /home/tonyj/stap/do_fork.stp:1:7 source: probe kernel.function("_do_fork"){ ^
semantic error: missing x86_64 kernel/module debuginfo [man warning::debuginfo] under '/lib/modules/4.12.14-197.34-default/build'
Hmm, I don't see this: # ll /boot/vmlinux* -rw-r--r-- 1 root root 10030200 Mar 9 14:20 /boot/vmlinux-5.5.7-1-default.xz # strace -fo bubak -e trace=%file stap -v b.stap Pass 1: parsed user script and 476 library scripts using 97296virt/88352res/6588shr/81884data kb, in 280usr/90sys/559real ms. Pass 2: analyzed script: 1 probe, 0 functions, 0 embeds, 0 globals using 119936virt/112752res/8172shr/104524data kb, in 1110usr/100sys/1225real ms. Pass 3: translated to C into "/tmp/stapcPCpg1/stap_81ae959f3a822f58c54b6ac1ed4df3ae_916_src.c" using 119936virt/113000res/8420shr/104524data kb, in 990usr/60sys/1066real ms. Pass 4: compiled C into "stap_81ae959f3a822f58c54b6ac1ed4df3ae_916.ko" in 16370usr/8760sys/37761real ms. Pass 5: starting run. do fork: no dwarf do fork: no dwarf ^Cdo fork: no dwarf Pass 5: run completed in 20usr/200sys/50435real ms. # grep '"/boot' bubak 24675 openat(AT_FDCWD, "/boot/System.map-5.5.7-1-default", O_RDONLY) = 3 24675 openat(AT_FDCWD, "/boot/vmlinux-5.5.7-1-default", O_RDONLY) = -1 ENOENT (No such file or directory) 24675 openat(AT_FDCWD, "/boot/vmlinux-5.5.7-1-default.debug", O_RDONLY) = -1 ENOENT (No such file or directory) 24675 openat(AT_FDCWD, "/boot/.debug/vmlinux-5.5.7-1-default.debug", O_RDONLY) = -1 ENOENT (No such file or directory) 24675 openat(AT_FDCWD, "/boot/.debug/vmlinux-5.5.7-1-default", O_RDONLY) = -1 ENOENT (No such file or directory) 24675 openat(AT_FDCWD, "/boot/vmlinux-5.5.7-1-default.debug", O_RDONLY) = -1 ENOENT (No such file or directory) 24675 openat(AT_FDCWD, "/boot/vmlinux-5.5.7-1-default", O_RDONLY) = -1 ENOENT (No such file or directory) 24675 openat(AT_FDCWD, "/boot/build/vmlinux-5.5.7-1-default.debug", O_RDONLY) = -1 ENOENT (No such file or directory) 24675 openat(AT_FDCWD, "/boot/build/vmlinux-5.5.7-1-default", O_RDONLY) = -1 ENOENT (No such file or directory) 24675 openat(AT_FDCWD, "/boot/vmlinux-5.5.7-1-default.debug", O_RDONLY) = -1 ENOENT (No such file or directory) 24675 openat(AT_FDCWD, "/boot/vmlinux-5.5.7-1-default", O_RDONLY) = -1 ENOENT (No such file or directory) 24675 lstat("/boot", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 24675 lstat("/boot/vmlinux-5.5.7-1-default", 0x7ffc1e6778e0) = -1 ENOENT (No such file or directory) 24675 openat(AT_FDCWD, "/boot/vmlinux-5.5.7-1-default.gz", O_RDONLY) = -1 ENOENT (No such file or directory) 24675 openat(AT_FDCWD, "/boot/vmlinux-5.5.7-1-default.bz2", O_RDONLY) = -1 ENOENT (No such file or directory) 24675 openat(AT_FDCWD, "/boot/vmlinux-5.5.7-1-default.xz", O_RDONLY) = 3 So it can and does open .xz. Tony, do you have some old version of systemtap? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166406 http://bugzilla.suse.com/show_bug.cgi?id=1166406#c18 --- Comment #18 from Jiri Slaby <jslaby@suse.com> --- (In reply to Jiri Slaby from comment #17)
So it can and does open .xz. Tony, do you have some old version of systemtap?
Stap seems to use libelf to handle that and this was added there by commit 6ecdead8c0fbba51e8b2561e4d54dd7be3f69204 Author: Roland McGrath <roland@redhat.com> Date: Fri Feb 11 12:29:45 2011 -0800 libdwfl: Search for Linux kernel binaries with compression file name suffixes. So xz should not be a problem. That said, I don't understand what your issue is. Something seems to be broken on your system. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166406 http://bugzilla.suse.com/show_bug.cgi?id=1166406#c19 --- Comment #19 from Tony Jones <tonyj@suse.com> --- (In reply to Jiri Slaby from comment #18)
(In reply to Jiri Slaby from comment #17)
So it can and does open .xz. Tony, do you have some old version of systemtap?
Stap seems to use libelf to handle that and this was added there by commit 6ecdead8c0fbba51e8b2561e4d54dd7be3f69204 Author: Roland McGrath <roland@redhat.com> Date: Fri Feb 11 12:29:45 2011 -0800
libdwfl: Search for Linux kernel binaries with compression file name suffixes.
So xz should not be a problem. That said, I don't understand what your issue is. Something seems to be broken on your system.
I don't have an issue. The vmlinux I was using wasn't xz compressed and so systemtap wasn't decompressing it. Maybe it can decompress xz. My point was that you said only "kdump and crash read it [vmlinux]" which isn't true, systemtap also does. That is all. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166406 http://bugzilla.suse.com/show_bug.cgi?id=1166406#c20 Jiri Slaby <jslaby@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(tonyj@suse.com) | --- Comment #20 from Jiri Slaby <jslaby@suse.com> --- (In reply to Tony Jones from comment #19)
I don't have an issue. The vmlinux I was using wasn't xz compressed and so systemtap wasn't decompressing it. Maybe it can decompress xz.
My point was that you said only "kdump and crash read it [vmlinux]" which isn't true, systemtap also does. That is all.
Aaah. It also looks (from the source code) that libdw (elfutils) can read also vmlinuz if there is no vmlinux. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166406 http://bugzilla.suse.com/show_bug.cgi?id=1166406#c21 --- Comment #21 from Tony Jones <tonyj@suse.com> --- (In reply to Jiri Slaby from comment #20)
(In reply to Tony Jones from comment #19)
I don't have an issue. The vmlinux I was using wasn't xz compressed and so systemtap wasn't decompressing it. Maybe it can decompress xz.
My point was that you said only "kdump and crash read it [vmlinux]" which isn't true, systemtap also does. That is all.
Aaah. It also looks (from the source code) that libdw (elfutils) can read also vmlinuz if there is no vmlinux.
This wasn't working for me when I tried it, so I had to manually decompress the installed vmlinux. Possible I'm using too old an elfutils, or issue was elsewhere. Regardless, not relevant to this bug. I'll verify it works off-line. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166406 http://bugzilla.suse.com/show_bug.cgi?id=1166406#c22 --- Comment #22 from Tony Jones <tonyj@suse.com> --- (In reply to Tony Jones from comment #21)
This wasn't working for me when I tried it, so I had to manually decompress the installed vmlinux. Possible I'm using too old an elfutils, or issue was elsewhere. Regardless, not relevant to this bug. I'll verify it works off-line.
Sorry, I misread what you wrote. Ignore above. I knew elfutils decompression of vmlinux.* was possible for Systemtap but I was not aware that vmlinuz could be handled by Systemtap. I will look at it some more. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166406 http://bugzilla.suse.com/show_bug.cgi?id=1166406#c23 --- Comment #23 from Tony Jones <tonyj@suse.com> --- (In reply to Jiri Slaby from comment #20)
Aaah. It also looks (from the source code) that libdw (elfutils) can read also vmlinuz if there is no vmlinux.
Our vmlinuz is stripped of all ELF symbol data. # eu-readelf -s /boot/vmlinux-5.5.7-1-default.xz | wc -l 122468 # eu-readelf -s /boot/vmlinuz | wc -l 0 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166406 http://bugzilla.suse.com/show_bug.cgi?id=1166406#c24 --- Comment #24 from Michal Suchanek <msuchanek@suse.com> --- This is not the way to tell. You must first unpack it. You could 'prove' any rpm package is stripped of all symbols by running readelf on the rpm. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166406 http://bugzilla.suse.com/show_bug.cgi?id=1166406#c25 --- Comment #25 from Tony Jones <tonyj@suse.com> --- (In reply to Michal Suchanek from comment #24)
This is not the way to tell. You must first unpack it. You could 'prove' any rpm package is stripped of all symbols by running readelf on the rpm.
My understanding (as was Jiri's from looking at the code) is that libdw handles the unpacking. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166406 http://bugzilla.suse.com/show_bug.cgi?id=1166406#c26 --- Comment #26 from Tony Jones <tonyj@suse.com> --- (In reply to Tony Jones from comment #25)
(In reply to Michal Suchanek from comment #24)
This is not the way to tell. You must first unpack it. You could 'prove' any rpm package is stripped of all symbols by running readelf on the rpm.
My understanding (as was Jiri's from looking at the code) is that libdw handles the unpacking.
Regardless, if I manually unpack the vmlinux from the vmlinuz using scripts/extract-vmlinux, the result contains no symbols. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166406 http://bugzilla.suse.com/show_bug.cgi?id=1166406#c27 Michal Suchanek <msuchanek@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugzilla.suse.com/s | |how_bug.cgi?id=1162581 --- Comment #27 from Michal Suchanek <msuchanek@suse.com> --- get_kernel_version is using vmlinux (see bug 1162581) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166406 http://bugzilla.suse.com/show_bug.cgi?id=1166406#c28 Ludwig Nussel <lnussel@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(mls@suse.com) | --- Comment #28 from Ludwig Nussel <lnussel@suse.com> --- get_kernel_version works fine with vmlinuz too: # for i in /boot/vmlinu*; do echo -n $i:; get_kernel_version $i; done /boot/vmlinux-5.6.0-1-default.xz:/boot/vmlinuz:5.6.0-1-default /boot/vmlinuz-5.6.0-1-default:5.6.0-1-default Wrt the open question about how to install the package containing vmlinux. I guess what you want is to install that package if both kernel-default as well as kernel-default-debuginfo are installed. You can use boolean deps¹ for that. So in kernel-default something like that should work: Requires: (%name-vmlinux = %version-%release if %name-debuginfo = %version-%release) [1] https://rpm.org/user_doc/boolean_dependencies.html -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166406 http://bugzilla.suse.com/show_bug.cgi?id=1166406#c29 --- Comment #29 from Takashi Iwai <tiwai@suse.com> --- A separate *-vmlinux package would give another benefit: we can package the uncompressed vmlinux if its installation is optional. Some applications need the raw vmlinux file and user had to uncompress manually, and this step can be avoided. Though, I'm not sure how many such applications exist now... -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166406 http://bugzilla.suse.com/show_bug.cgi?id=1166406#c30 --- Comment #30 from Tony Jones <tonyj@suse.com> --- (In reply to Ludwig Nussel from comment #28)
I guess what you want is to install that package if both kernel-default as well as kernel-default-debuginfo are installed.
Maybe I'm misunderstanding. How is that different from just adding vmlinux to the debuginfo package? Also, as already shown, systemtap can make use of the symbol information in vmlinux without debuginfo. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166406 http://bugzilla.suse.com/show_bug.cgi?id=1166406#c31 --- Comment #31 from Michal Suchanek <msuchanek@suse.com> --- get_kernel_version does not work on 32bit arm without vmlinux -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1166406 https://bugzilla.suse.com/show_bug.cgi?id=1166406#c32 Miroslav Beneš <mbenes@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mbenes@suse.com Assignee|kernel-maintainers@forge.pr |kernel-bugs@opensuse.org |ovo.novell.com | --- Comment #32 from Miroslav Beneš <mbenes@suse.com> --- Has there been any new development? tl;dr summary (hopefully correct) is that at least systemtap and get_kernel_version on arm need vmlinux. As far as systemtap is concerned, vmlinux could be stored in a different package. Ludwig proposed boolean deps for that in comment 28. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1166406 Libor Pechacek <lpechacek@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lpechacek@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1166406 https://bugzilla.suse.com/show_bug.cgi?id=1166406#c33 --- Comment #33 from Fabian Vogt <fvogt@suse.com> --- Any news? What are the next necessary steps? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1166406 https://bugzilla.suse.com/show_bug.cgi?id=1166406#c40 Jiri Slaby <jslaby@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fvogt@suse.com Flags| |needinfo?(fvogt@suse.com) --- Comment #40 from Jiri Slaby <jslaby@suse.com> --- So what's the status of this please? Is it still desired, can we proceed? Or is this wontfix? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1166406 https://bugzilla.suse.com/show_bug.cgi?id=1166406#c41 Fabian Vogt <fvogt@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(fvogt@suse.com) | --- Comment #41 from Fabian Vogt <fvogt@suse.com> --- (In reply to Jiri Slaby from comment #40)
So what's the status of this please? Is it still desired, can we proceed? Or is this wontfix?
Yep, still desired. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1166406 https://bugzilla.suse.com/show_bug.cgi?id=1166406#c42 --- Comment #42 from Michal Suchanek <msuchanek@suse.com> --- To summarize - vmlinux cannot be moved to debuginfo package - changing the way debuginfo packages are generated is infeasible, and this would need substantial change - some tools need only vmlinux, not debuginfo, and forcing installation of debuginfo for those is a no-go - moving vmlinux into separate package is possible (on non-ppc) provided tools that assume vmlinux is present are fixed up (there are some additional binaries used exclusively for debugging - eg. the s390 boot stub, vdso?) - some of these tools are something like debug tools or performance measurement tools that can be fixed up as problems are found - some of these tools may be part of basesystem and it is critical that they work from the start on all platforms - complex dependencies can be used to fix up debug package installation on SLE15, on SLE12 this cannot be reasonably expected to work. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1166406 Libor Pechacek <lpechacek@gmx.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|lpechacek@gmx.com |chrubis@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
participants (2)
-
bugzilla_noreply＠novell.com -
bugzilla_noreply＠suse.com