Cannot exclude read-only paths from dpkg, as they still cause dpkg to fail

Bug #2003789 reported by Łukasz Zemczak
This bug affects 1 person
Affects Status Importance Assigned to Milestone
dpkg (Debian)
Fix Released
dpkg (Ubuntu)
Fix Released
In Progress
Won't Fix

Bug Description


In certain very specific cases, certain directories on the filesystem can be read-only. As-is, this is problematic for dpkg in case some package wants to install files there - which is fine and expected. But when this situation is 'intentional', one might want to use --path-exclude for the selected paths. Currently, dpkg will *still* fail in such cases.

The reason is that dpkg, before starting work on the package, checks for any dpkg interrupted transactions. It does that by performing a rename() on the dpkg tmp files on the selected path, and if there is none (by checking errno for ENOENT and ENOTDIR), it continues the operation. But in cases where the file-system is read only, the returned errno is EROFS, which is not handled and treated as if the file is there but unable to restore it.

It feels like a valid case though - if the filesystem if readonly, we should not consider *this* as an error case. Without path-excludes, dpkg will fail at a different moment anyway. While if someone has a working setup where this path indeed should be read-only but excluded, we should let dpkg continue.

[Test Case]

Ideally, creating a setup where some directory (for instance, /lib/firmware) is read-only, and trying to install a package like alsa-topology-conf. The package installation should succeed without any files installed into /lib/firmware.

[Regression Potential]

As this is a change in dpkg, there's quite a lot that might go wrong. However, the change is rather limited. Problems can appear in handling of interrupted transactions, or by breaking package installation in overall.

Tags: patch
Revision history for this message
Łukasz Zemczak (sil2100) wrote :

Here is the debdiff of the proposed change (for jammy in this case).

tags: added: patch
Revision history for this message
Łukasz Zemczak (sil2100) wrote :

Pushed this to Debian: . Will now upload to lunar and as SRUs to kinetic and jammy.

Changed in dpkg (Ubuntu Jammy):
importance: Undecided → High
Changed in dpkg (Ubuntu Kinetic):
importance: Undecided → Low
Revision history for this message
Łukasz Zemczak (sil2100) wrote :

Pushed SRU to jammy. I was thinking about a kinetic upload, but... not sure if it's worthwhile. The fix is for a rather edge-case, and kinetic is about to go EOL in a few months. That's still quite some time, but upgrading dpkg means an upgrade for all kinetic users - for almost no merit. We *need* this fix for jammy due to a commercial project that requires this fix, but it's 22.04 only. So there the severity is high. But for kinetic there is no reason.

If someone from the SRU team thinks otherwise, I'm happy to prepare a kinetic upload as well.

Changed in dpkg (Ubuntu):
status: New → Fix Committed
Changed in dpkg (Ubuntu Kinetic):
status: New → Won't Fix
Changed in dpkg (Ubuntu Jammy):
status: New → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package dpkg - 1.21.19ubuntu3

dpkg (1.21.19ubuntu3) lunar; urgency=medium

  * Fix dpkg handling of --path-exclude for read-only paths (LP: #2003789).

 -- Łukasz 'sil2100' Zemczak <email address hidden> Tue, 31 Jan 2023 17:59:24 +0100

Changed in dpkg (Ubuntu):
status: Fix Committed → Fix Released
Changed in dpkg (Debian):
status: Unknown → Fix Released
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.