udev package doesn't mark as a configuration file fbdev-blacklist.conf

Bug #1827753 reported by Chai T. Rex
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
kmod (Ubuntu)
Triaged
Wishlist
Unassigned
systemd (Ubuntu)
Opinion
Low
Unassigned

Bug Description

System information
====================

    $ lsb_release -rd
    Description: Ubuntu 18.04.2 LTS
    Release: 18.04

    $ apt-cache policy udev
    udev:
      Installed: 237-3ubuntu10.21
      Candidate: 237-3ubuntu10.21
      Version table:
     *** 237-3ubuntu10.21 500
            500 http://us.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
            100 /var/lib/dpkg/status
         237-3ubuntu10.19 500
            500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
         237-3ubuntu10 500
            500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages

 Problem
=========

The `udev` package includes `/lib/modprobe.d/fbdev-blacklist.conf`, a configuration file blacklisting several kernel modules. It's not listed as a configuration file in the package, though:

    $ cat /var/lib/dpkg/info/udev.conffiles
    /etc/init.d/udev
    /etc/udev/udev.conf

This means that, if I want to go ahead and use the `sisfb` kernel module, for example, I unblacklist it in the two files it's blacklisted in. However, any updated version of `udev` that's installed will throw away my changes to `/lib/modprobe.d/fbdev-blacklist.conf` by simply overwriting the file and again blacklist the kernel module, which doesn't work well when the system is being used by someone very new to computers.

I can't avoid that by simply telling APT to leave configuration files alone because the `.conf` file here technically isn't a configuration file. Also, `chattr +i /lib/modprobe.d/fbdev-blacklist.conf` causes APT to require someone with technical knowledge to take extra effort to repair things when the end user agrees to an install in the weekly GUI reminder of new software.

 Request
=========

Please mark `/lib/modprobe.d/fbdev-blacklist.conf` as a configuration file in `udev`.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: udev 237-3ubuntu10.21
ProcVersionSignature: Ubuntu 4.15.0-47.50-generic 4.15.18
Uname: Linux 4.15.0-47-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.6
Architecture: amd64
CurrentDesktop: XFCE
CustomUdevRuleFiles: 70-snap.core.rules 70-snap.cnctsun.rules 70-snap.cncra2yr.rules 70-snap.cncra.rules 60-vboxdrv.rules
Date: Sat May 4 21:51:42 2019
InstallationDate: Installed on 2018-12-27 (128 days ago)
InstallationMedia: Xubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725)
Lsusb:
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 020: ID 046d:c077 Logitech, Inc. M105 Optical Mouse
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: Dell Inc. XPS 13 9360
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-47-generic root=/dev/mapper/xubuntu--vg-root ro quiet splash vt.handoff=1
SourcePackage: systemd
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 09/27/2018
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 2.10.0
dmi.board.name: 0839Y6
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 9
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvr2.10.0:bd09/27/2018:svnDellInc.:pnXPS139360:pvr:rvnDellInc.:rn0839Y6:rvrA00:cvnDellInc.:ct9:cvr:
dmi.product.family: XPS
dmi.product.name: XPS 13 9360
dmi.sys.vendor: Dell Inc.

Revision history for this message
Chai T. Rex (chaitrex) wrote :
description: updated
Chai T. Rex (chaitrex)
description: updated
Revision history for this message
Dan Streetman (ddstreet) wrote :

@chaitrex, while it's not an acutal fix, modprobe does filter out duplicate named files in the modprobe.d search list, and /lib/modprobe.d is at the end of the list; so if you simply copy /lib/modprobe.d/fbdev-blacklist.conf to /etc/modprobe.d/fbdev-blacklist.conf, then you can edit the file in /etc/modprobe.d and the contents of the file in /lib/modprobe.d will be ignored by any calls to modprobe. Upgrading the udev package will also not touch the /etc/modprobe.d/fbdev-blacklist.conf file since it did not place it there.

Revision history for this message
Dan Streetman (ddstreet) wrote :

@rbalint, I think @chaitrex has a point in this bug that /lib/modprobe.d/fbdev-blacklist.conf isn't end-user editable without being overwritten by udev package update.

Additionally, the Ubuntu (but not Debian) kmod package ships /etc/modprobe.d/blacklist-framebuffer.conf which contains almost all the drivers in fbdev-blacklist.conf; maybe we should remove fbdev-blacklist.conf from the Ubuntu systemd package? It might be worth seeing if Debian is interested in removing it also, or at least moving it to /etc/modprobe.d so it becomes a config file. what do you think?

Revision history for this message
Balint Reczey (rbalint) wrote :

@chaitrex, IMO the workaround proposed by @ddstreet in #2 is the simplest solution, overriding default configuration by placing a configuration in /etc and this also follows the general concept of how systems should be configured.
The big miss here is not having the behavior documented in modprobe.d(5).

Since the file in /lib/modprobe.d can be overridden by placing an identically named file in /etc i don't think that making the file shipped in /lib/modprobe.d is necessary or desired.
Also we would like to go in the direction of not shipping files in /etc by default, so moving the file to /etc would be a step back.

As a side note in similar situation the system administrator can use dpkg-divert to keep a file from being overwritten by a package upgrade.

Changed in kmod (Ubuntu):
importance: Undecided → Wishlist
Changed in systemd (Ubuntu):
importance: Undecided → Low
status: New → Opinion
Changed in kmod (Ubuntu):
status: New → Triaged
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.