Bug 970222 - Kernel panic after update/reinstall kernel (update bootloader throw zypper) with /var/tmp tmpfs noexec mount flag
Kernel panic after update/reinstall kernel (update bootloader throw zypper) w...
Status: RESOLVED WONTFIX
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Bootloader
Current
x86-64 All
: P2 - High : Major (vote)
: ---
Assigned To: Thomas Renninger
Jiri Srain
: Upgrade
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-03-09 08:08 UTC by Илья Индиго
Modified: 2018-04-25 14:26 UTC (History)
1 user (show)

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


Attachments
Screenshot of Monitor durring Kernel panic (3.74 MB, image/jpeg)
2016-03-09 08:08 UTC, Илья Индиго
Details
/var/log/zypp/history (1.62 MB, text/plain)
2016-03-09 12:24 UTC, Илья Индиго
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Илья Индиго 2016-03-09 08:08:28 UTC
Created attachment 668279 [details]
Screenshot of Monitor durring Kernel panic

Hello.
If to the /etc/fstab to register

tmpfs /var/tmp tmpfs nodev,nosuid 0 0

The key here is the noexec flag, then the next time you update the kernel or packages for which updates the boot loader sudo zypper dup, or that would clearly repeat sudo zypper in -f kernel-default zypper update the bootloader and will not issue any warnings, but after reboot, you will receive the following message, which I also attached a screenshot of the monitor in the attachments.

init: error while loading shared libraries: libseccomp.so.2: cannot open shared object file: No such file or directory
4.055441] Kernel panic - not syncing: Attemted to kill init! exitcode=0x00007f00
4.056010] CPU: 0 PID: 1 Comm: init Not tainted 4.4.3-1-default #1

I, if you honestly do not quite understand, it is normal that in the /var/tmp may even be required to be executable files, or is it still not the correct behavior zypper or rpm?
And in any case zypper and/or rpm should check whether they allow in /var/tmp to create executable files in the file system and only then perform the update bootloader and/or some thingelse, or to tell me that something is wrong and it can lead to serious problems.
In any case, the lack of this check and consider the warning of a serious bug.
Comment 1 Илья Индиго 2016-03-09 09:16:30 UTC
tmpfs /var/tmp tmpfs nodev,nosuid,noexec 0 0
Comment 2 Michael Andres 2016-03-09 10:36:16 UTC
Sorry, but zypper/rpm can't know which packages will trigger some action upon the next reboot and whether this may fail due to your systems settings. zypper/rpm install the software, they do not know how the software will behave.

The install scripts performing actions are part of the package, not part of the installer. The installer executes the script, but the installer does not know what the script will do.


From the error message it's not even possible to tell, whether it's actually caused buy the noexec flag. libseccomp.so.2 ususally resides in /usr/lib64, not in /var/tmp and the error says it's missing.

I forward this to 'Bootloader' guys.
Comment 3 Jiri Srain 2016-03-09 11:47:34 UTC
Honestly, I'm not sure that setting /var/tmp as noexec is something that will work in other cases. You may not have run into any yet, but I think that it is just matter of time.

Anyway, can you attach the zypp history (/var/lib/zypp/history) to see whether/what provided some additional output? Hopefully it will help identify which script has an issue with the noexec.
Comment 4 Илья Индиго 2016-03-09 12:24:01 UTC
Created attachment 668327 [details]
/var/log/zypp/history
Comment 5 Jiri Srain 2016-03-09 12:37:53 UTC
There is some interesting output of dracut, not sure it is related. Thomas, can you, please, have a look?

The crash happens while initrd is being executed, therefore it looks to me like dracut fails to create initrd properly (due to the noexec flag?).
Comment 6 Илья Индиго 2016-03-09 13:17:24 UTC
(In reply to Jiri Srain from comment #5)
> ...(due to the noexec flag?).

If this question to me, yes.
Without noexec flag in the /var/tmp after a kernel upgrade the system boots normally.
When it appears, after upgrading the kernel and reboot the system, I get what showed in the screenshot.
Comment 7 Thomas Renninger 2016-03-14 17:01:54 UTC
Yes, I can reproduce this bug.
I first tried on SLES12 SP2 without success. This one still has an older dracut version. I then tried on latest Tumbleweed build and could reproduce by doing an lsinitrd on a initrd produces with and without noexec flag on /var/tmp.
Comment 8 Thomas Renninger 2018-04-25 13:25:16 UTC
Closing the bug, because it slipped through and is really old.

Probably fixed meanwhile. If still reproducable, please re-open, this is a valid bug.
Comment 9 Илья Индиго 2018-04-25 14:26:27 UTC
Thank you! I'm set again noexec tag for /tmp and /var/tmp 

/etc/fstab
tmpfs /tmp tmpfs nodev,nosuid,noexec,size=2G 0 0
tmpfs /var/tmp tmpfs nodev,nosuid,noexec,size=2G 0 0

And update from 20180420 to 20180424 include kernel-default
All fine. Bug not reproduce now.