Bug 1189879 - Missing kernel config in /boot
Missing kernel config in /boot
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Kernel
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: openSUSE Kernel Bugs
E-mail List
:
Depends on:
Blocks: 1029961
  Show dependency treegraph
 
Reported: 2021-08-27 09:27 UTC by Petr Vorel
Modified: 2021-12-07 20:31 UTC (History)
8 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Vorel 2021-08-27 09:27:30 UTC
bsc#1184804 moved kernel config out of /boot into /usr/lib/modules/. But unlike vmlinuz and initrd there is missing symlink in /boot.  Is it really a wanted change?

$ ls -l /boot/
-rw-r--r-- 1 root root        0 Mar 13  2017 backup_mbr
-rw-r--r-- 1 root root     1725 Jul 28 19:25 boot.readme
drwxr-xr-x 6 root root     4096 Aug 25 11:18 grub2
lrwxrwxrwx 1 root root       34 Aug 25 10:57 initrd -> initrd-5.14.0-rc7-3.gdbb9dbc-debug
-rw------- 1 root root 11202252 May 24  2019 initrd-5.0.7
-rw------- 1 root root 22664676 Aug 25 11:02 initrd-5.14.0-rc7-3.gdbb9dbc-debug
-rw------- 1 root root 22652804 Aug 25 11:03 initrd-5.14.0-rc7-3.gdbb9dbc-default
-rw------- 1 root root 13074280 Jul  4  2019 initrd-5.2.0-rc1-2.gb225e5a-default+
-rw------- 1 root root 19355748 Jul  4  2019 initrd-5.2.0-rc1-2.gb225e5a-default+-kdump
lrwxrwxrwx 1 root root       58 Aug 25 10:57 sysctl.conf-5.14.0-rc7-3.gdbb9dbc-debug -> ../usr/lib/modules/5.14.0-rc7-3.gdbb9dbc-debug/sysctl.conf
lrwxrwxrwx 1 root root       60 Aug 25 10:56 sysctl.conf-5.14.0-rc7-3.gdbb9dbc-default -> ../usr/lib/modules/5.14.0-rc7-3.gdbb9dbc-default/sysctl.conf
lrwxrwxrwx 1 root root       57 Aug 25 10:57 System.map-5.14.0-rc7-3.gdbb9dbc-debug -> ../usr/lib/modules/5.14.0-rc7-3.gdbb9dbc-debug/System.map
lrwxrwxrwx 1 root root       59 Aug 25 10:56 System.map-5.14.0-rc7-3.gdbb9dbc-default -> ../usr/lib/modules/5.14.0-rc7-3.gdbb9dbc-default/System.map
lrwxrwxrwx 1 root root       35 Aug 25 10:57 vmlinuz -> vmlinuz-5.14.0-rc7-3.gdbb9dbc-debug
lrwxrwxrwx 1 root root       54 Aug 25 10:57 vmlinuz-5.14.0-rc7-3.gdbb9dbc-debug -> ../usr/lib/modules/5.14.0-rc7-3.gdbb9dbc-debug/vmlinuz
lrwxrwxrwx 1 root root       56 Aug 25 10:56 vmlinuz-5.14.0-rc7-3.gdbb9dbc-default -> ../usr/lib/modules/5.14.0-rc7-3.gdbb9dbc-default/vmlinuz

If yes, some users can be surprised. Also rpm package claims to have config in /boot but it's not there:

$ rpm -ql kernel-default-5.14~rc7-3.1.gdbb9dbc.x86_64 |grep /boot/config
/boot/config-5.14.0-rc7-3.gdbb9dbc-default

ls -la /boot/config-5.14.0-rc7-3.gdbb9dbc-default
ls: cannot access '/boot/config-5.14.0-rc7-3.gdbb9dbc-default': No such file or directory

According to openQA it was broken somewhere between 5.13.12-1.2 999e6048a4cc6accd2653c9dccaaaff2f4ae8f86 (good) and 5.13.12-2.1 33df9c651d0aa37cce1275bd9528ea5cb9196022 (bad). It looks to me that 33df9c651d0aa37cce1275bd9528ea5cb9196022 Revert "Revert "UsrMerge the kernel (boo#1184804)"" broke it.
Comment 1 Ludwig Nussel 2021-08-27 09:45:16 UTC
Is the config file actually needed for anything in /boot or just some openqa test randomly checking it?
Comment 2 Petr Vorel 2021-08-27 09:50:00 UTC
It's definitely not a problem to fix openQA test. I'm opening this bug to make sure it's wanted feature, because people for sure have in their scripts /boot/config-$(uname -r) as it has been there for years.
Comment 3 Michal Suchanek 2021-08-27 09:51:13 UTC
it's where people will generally look for it and there are probably quite a few scripts/code samples that expect it there.

Also if the package claims to have the file it should provide it.
Comment 4 Ludwig Nussel 2021-08-27 12:03:40 UTC
It's %ghost so can be there or not. Rpm then makes sure it gets deleted on uninstall. Fedora's kernel-install(8) script for grub actually does link/copy the config file to /boot. The upstream kernel-install scripts do not handle that file.

So I really wonder what the purpose of using the file in /boot would be. Does anyone know any script used in practice that uses it? And for what?
The running kernel has it's config in /proc/config.gz. For building modules /lib/modules/$version/build/.config is the correct one to use.

So if the %ghost entry is considered confusing I'd rather remove it than adding link.
Comment 5 Michal Suchanek 2021-08-27 12:08:06 UTC
/boot/config-$(uname -r) is the place where the config is typically placed for distribution provided kernel.

It can be used for rebuilding the kernel with the same configuration.

It is not consumed by the bootloader or something so a symlink rather than hardlink would suffice.
Comment 6 Petr Vorel 2021-08-27 13:10:17 UTC
(In reply to Michal Suchanek from comment #5)
> /boot/config-$(uname -r) is the place where the config is typically placed
> for distribution provided kernel.
+1

@lnussel Although People have it in their custom scripts. And this is not only for some cross distro tools, even current SLES/Leap vs. openSUSE Tumbleweed users will be affected. Sure, solution is simple: 
f="/boot/config-$(uname -r)"; [ -f "$f" ] || f="/usr/lib/modules/$(uname -r)/config

But users will think: why to break compatibility for no reason (again)?

For cross distro tools you cannot rely on /proc/config.gz, because not all distros have CONFIG_IKCONFIG_PROC enabled.

> 
> It can be used for rebuilding the kernel with the same configuration.
> 
> It is not consumed by the bootloader or something so a symlink rather than
> hardlink would suffice.
+1
Comment 7 Michal Suchanek 2021-08-27 13:22:50 UTC
(In reply to Petr Vorel from comment #6)

> 
> But users will think: why to break compatibility for no reason (again)?
+1
> 
> For cross distro tools you cannot rely on /proc/config.gz, because not all
Also you may not be running the kernel you are rebuilding.
Comment 8 Olaf Hering 2021-09-02 07:32:55 UTC
see bug#1190061 for actual breakage.
Comment 9 Martin Wilck 2021-09-02 09:34:14 UTC
No offense, but these missing %ghost files create a lot of confusion. It's particularly confusing that some of the symlinks are created in %post, while others are not. That simply looks like an oversight on the part of the developers, even if it was done deliberately.

We shouldn't have done this without a BIG FAT announcement. I'm not sure if we should have done it at all.
Comment 10 Jiri Slaby 2021-09-02 10:31:01 UTC
(In reply to Martin Wilck from comment #9)
> No offense, but these missing %ghost files create a lot of confusion. It's
> particularly confusing that some of the symlinks are created in %post, while
> others are not. That simply looks like an oversight on the part of the
> developers, even if it was done deliberately.

My intention definitely was: no undocumented changes.
Comment 11 Takashi Iwai 2021-09-06 13:16:49 UTC
Yet other breakages: bug 1189782 and bug 1190143.
The fix is still missing?
Comment 12 Martin Wilck 2021-09-06 14:36:46 UTC
(In reply to Takashi Iwai from comment #11)
> The fix is still missing?

Not sure which fix you mean, but Michal is working on a large-ish change of the kernel scriptlets in bug 1189841.
Comment 13 Michal Suchanek 2021-09-06 14:47:44 UTC
Which does not in any way address this bug but when merged the fix for this bug will need to be done in suse-module-tools.
Comment 14 Martin Wilck 2021-09-06 15:21:02 UTC
The question is whether this bug here, and the ones Takashi mentioned, should be fixed *before* pushing the s-m-t changes as part of bug 1189841. They are arguably more urgent.
Comment 15 Ludwig Nussel 2021-09-13 10:56:37 UTC
Back from vacation, will take a look
Comment 16 Ludwig Nussel 2021-09-13 14:01:39 UTC
The grub related script were fixed by Michael to read the new location. That fixes all linked bugs already. Thanks for that! It's the right solution IMO. I'll add the compat link back in addition. PR filed. Nevertheless script that rely on it should really be adjusted the new location. There is no promise how /boot will look like in the future. See also https://systemd.io/BOOT_LOADER_SPECIFICATION/
Comment 17 Martin Wilck 2021-09-14 19:27:52 UTC
(In reply to Ludwig Nussel from comment #16)

> There is no
> promise how /boot will look like in the future. See also
> https://systemd.io/BOOT_LOADER_SPECIFICATION/

I don't think that spec will take us very far:

"Note that the $BOOT partition is not supposed to be exclusive territory of this specification. This specification only defines semantics of the /loader/ directory inside the file system (see below), but it doesn’t intend to define ownership of the whole file system exclusively. Boot loaders, firmware, and other software implementing this specification may choose to place other files and directories in the same file system."

I'm still waiting for a rationale why these symlinks should _not_ exist. Is it because /boot should be r/o? I suppose not, because then you couldn't create the sysctl.conf and other symlinks, either. I really see no other good reason. On the other hand, the absence of these files is likely not only to confuse users, but break scripts and software all over the place. These files have existed under /boot for as long as most of us can remember.
Comment 18 OBSbugzilla Bot 2021-09-14 22:40:12 UTC
This is an autogenerated message for OBS integration:
This bug (1189879) was mentioned in
https://build.opensuse.org/request/show/919012 Factory / suse-module-tools
Comment 19 Ludwig Nussel 2021-09-15 07:41:27 UTC
(In reply to Martin Wilck from comment #17)
> [...]
> I'm still waiting for a rationale why these symlinks should _not_ exist. Is
> it because /boot should be r/o? I suppose not, because then you couldn't
> create the sysctl.conf and other symlinks, either. I really see no other
> good reason. On the other hand, the absence of these files is likely not
> only to confuse users, but break scripts and software all over the place.
> These files have existed under /boot for as long as most of us can remember.

You mean symvers and symtypes? What tools use them? Fedora 34 also doesn't have them (only config and System.map left atm). Going forward the /boot as we know it is kind of redundant so there might be no need to even have it anymore IMO. All OS files are in /usr and boot stuff goes to the EFI boot partition that could be mounted only when writing it is needed.

Anyway, pr for adding config link back was merged, thanks!
Comment 20 Jiri Slaby 2021-09-15 07:48:39 UTC
(In reply to Ludwig Nussel from comment #19)
> Anyway, pr for adding config link back was merged, thanks!

FTR, AFAICS, it was not (yet).
Comment 21 Martin Wilck 2021-09-15 08:19:31 UTC
(In reply to Jiri Slaby from comment #20)
> FTR, AFAICS, it was not (yet).

Ludwig submitted it to suse-module-tools, and I merged it yesterday. It's based on Michal's work to move all kernel scriptlets into s-m-t (boo#1189841).

So this will fixed after the kernel migrates to the "external" scripting.
Comment 22 Ludwig Nussel 2021-09-15 08:27:00 UTC
Too many moving bits :-) the script removal happened in the stable branch yesterday night so my submission to the kernel git is obsolete.
Comment 23 Martin Wilck 2021-09-15 09:17:48 UTC
There was a bug in my OBS submission (obsolete .obscpio file included) causing confusion. New sr#919089.
Comment 24 Jiri Slaby 2021-09-15 09:36:04 UTC
(In reply to Ludwig Nussel from comment #22)
> Too many moving bits :-) the script removal happened in the stable branch
> yesterday night so my submission to the kernel git is obsolete.

Not completely, could you rebase only w/ a5f2391d33d (rpm/kernel-binary.spec.in: avoid conflicting suse-release).
Comment 25 OBSbugzilla Bot 2021-09-15 10:40:12 UTC
This is an autogenerated message for OBS integration:
This bug (1189879) was mentioned in
https://build.opensuse.org/request/show/919089 Factory / suse-module-tools
Comment 26 openQA Review 2021-09-30 00:00:44 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: jeos-ltp-commands@uefi_virtio-2G
https://openqa.opensuse.org/tests/1943659

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`
Comment 27 openQA Review 2021-10-14 00:01:38 UTC
This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: install_ltp_s390x
https://openqa.opensuse.org/tests/1944814

To prevent further reminder comments one of the following options should be followed:
1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
3. The bugref in the openQA scenario is removed or replaced, e.g. `label:wontfix:boo1234`
Comment 31 Michal Suchanek 2021-11-16 16:57:01 UTC
Merged into Factory.
Comment 34 Swamp Workflow Management 2021-12-01 17:26:11 UTC
SUSE-RU-2021:3820-1: An update that has 9 recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1158817,1189841,1189879,1190598,1191200,1191260,1191480,1191804,1191922
CVE References: 
JIRA References: 
Sources used:
SUSE Linux Enterprise Server for SAP 15 (src):    suse-module-tools-15.0.10-3.12.1
SUSE Linux Enterprise Server 15-LTSS (src):    suse-module-tools-15.0.10-3.12.1
SUSE Linux Enterprise High Performance Computing 15-LTSS (src):    suse-module-tools-15.0.10-3.12.1
SUSE Linux Enterprise High Performance Computing 15-ESPOS (src):    suse-module-tools-15.0.10-3.12.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
Comment 35 Swamp Workflow Management 2021-12-02 11:49:33 UTC
SUSE-RU-2021:3869-1: An update that has 8 recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1189841,1189879,1190598,1191200,1191260,1191480,1191804,1191922
CVE References: 
JIRA References: 
Sources used:
SUSE Linux Enterprise Server for SAP 15-SP1 (src):    suse-module-tools-15.1.23-3.19.1
SUSE Linux Enterprise Server 15-SP1-LTSS (src):    suse-module-tools-15.1.23-3.19.1
SUSE Linux Enterprise Server 15-SP1-BCL (src):    suse-module-tools-15.1.23-3.19.1
SUSE Linux Enterprise High Performance Computing 15-SP1-LTSS (src):    suse-module-tools-15.1.23-3.19.1
SUSE Linux Enterprise High Performance Computing 15-SP1-ESPOS (src):    suse-module-tools-15.1.23-3.19.1
SUSE Enterprise Storage 6 (src):    suse-module-tools-15.1.23-3.19.1
SUSE CaaS Platform 4.0 (src):    suse-module-tools-15.1.23-3.19.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
Comment 36 Swamp Workflow Management 2021-12-07 17:16:54 UTC
SUSE-RU-2021:3966-1: An update that has 8 recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1189841,1189879,1190598,1191200,1191260,1191480,1191804,1191922
CVE References: 
JIRA References: 
Sources used:
SUSE Linux Enterprise Server 12-SP5 (src):    suse-module-tools-12.11-3.8.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
Comment 37 Swamp Workflow Management 2021-12-07 20:31:18 UTC
SUSE-RU-2021:3970-1: An update that has 8 recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1189841,1189879,1190598,1191200,1191260,1191480,1191804,1191922
CVE References: 
JIRA References: 
Sources used:
SUSE OpenStack Cloud Crowbar 9 (src):    suse-module-tools-12.6.1-27.6.1
SUSE OpenStack Cloud Crowbar 8 (src):    suse-module-tools-12.6.1-27.6.1
SUSE OpenStack Cloud 9 (src):    suse-module-tools-12.6.1-27.6.1
SUSE OpenStack Cloud 8 (src):    suse-module-tools-12.6.1-27.6.1
SUSE Linux Enterprise Server for SAP 12-SP4 (src):    suse-module-tools-12.6.1-27.6.1
SUSE Linux Enterprise Server for SAP 12-SP3 (src):    suse-module-tools-12.6.1-27.6.1
SUSE Linux Enterprise Server 12-SP4-LTSS (src):    suse-module-tools-12.6.1-27.6.1
SUSE Linux Enterprise Server 12-SP3-LTSS (src):    suse-module-tools-12.6.1-27.6.1
SUSE Linux Enterprise Server 12-SP3-BCL (src):    suse-module-tools-12.6.1-27.6.1
SUSE Linux Enterprise Server 12-SP2-BCL (src):    suse-module-tools-12.6.1-27.6.1
HPE Helion Openstack 8 (src):    suse-module-tools-12.6.1-27.6.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.