On Thu, 2019-01-31 at 20:21 +0100, Michal Kubecek wrote:
On Thu, Jan 31, 2019 at 11:01:18AM +0100, Stefan Seyfried wrote:
"Unable to boot afterwards" would imply the module was used when the update happens. This should be relatively easy to detect and to auto- adjust dracut.conf so that the module will still be loaded in next initrd.
Yes, that's one way to handle it, similar to what Jeff and Martin proposed later. I just wanted to point out that we need to handle it in some way because user's system not booting properly after an update (in this case, even selecting previous "known good" kernel might not help) is one of the worst things a distribution can do (from users's point of view).
I agree.
If anyone is interested, a prototype of the blacklisting logic can be
found in my home project:
https://build.opensuse.org/project/show/home:mwilck:suse-module-tools
https://download.opensuse.org/repositories/home:/mwilck:/suse-module-tools/o...
All the blacklisting-related logic is in the spec file. The default is
to blacklist all previously mentioned modules. Separate blacklist files
for each file system are placed in /etc/modprobe.d/60-blacklist_fs-$FS.conf.
The content of these files looks like this:
------
# The f2fs file system is blacklisted by default because it isn't actively
# supported by SUSE, not well maintained, and may have security vulnerabilites.
# To enable autoloading the f2fs file system module, comment out the
# "blacklist f2fs" statement below. ENABLE AT YOUR OWN RISK.
#
# File system modules loaded at installation time of the suse-module-tools package
# are not blacklisted. This is achieved by commenting out the blacklist
# line in the post-installation script. To prevent the post-installation
# script from modifying this file, delete the following line.
# __THIS FILE MAY BE MODIFIED__
blacklist f2fs
------
If any such module is loaded during the installation of the suse-module-tools
package (i.e. listed in /proc/filesystems), the %post script comments out the
blacklist line on the bottom. This will cause the file to appear modified to
rpm, so that future updates won't overwrite it, as the files are marked
%config(noreplace). %config(noreplace) doesn't protect the files from being
modified by the %post script though. Therefore, people who want to keep the
FS blacklisted (even though they sometimes load the module manually) can remove the
"__THIS FILE MAY BE MODIFIED__" marker. That way, even if the suse-module-tools
rpm was updated while the module was loaded, it wouldn't un-blacklist it.
I've tested this on my system, and it appears to work as designed.
Comments welcome.
Martin
--
Dr. Martin Wilck