Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

[solved:overlayfs bug] dpkg error on firefox-esr 60.4 update

Graphical Environments, Managers, Multimedia & Desktop questions.
Post Reply
Message
Author
ffhuh12
Posts: 3
Joined: 2018-12-13 15:32

[solved:overlayfs bug] dpkg error on firefox-esr 60.4 update

#1 Post by ffhuh12 »

Hello,

I made an apt-get dist-upgrade on my Debian 9.6 install today and got a dpkg unpack error related to firefox-esr 60.4 (currently running firefox-esr 60.3) : apparently it fails to update the folder "/usr/share/icons/hicolor/symbolic/apps/firefox-esr-symbolic.svg/"

I deleted this folder and it's content (watermark.svg) and the update went through correctly, which resulted in the creation of a svg file (the path is not a folder anymore).

Is anyone else experiencing the same behavior ? If so, could someone please report it as bug ?

Thanks
Last edited by ffhuh12 on 2018-12-15 02:39, edited 1 time in total.

Bulkley
Posts: 6383
Joined: 2006-02-11 18:35
Has thanked: 2 times
Been thanked: 39 times

Re: dpkg error on firefox-esr 60.4 update

#2 Post by Bulkley »

Why apt-get dist-upgrade? apt-get upgrade should do it. Or are you running a mixed system? Having just received the firefox-esr 60.4 update without issue I wonder what's in your sources.list.

ffhuh12
Posts: 3
Joined: 2018-12-13 15:32

Re: dpkg error on firefox-esr 60.4 update

#3 Post by ffhuh12 »

apt-get dist-upgrade is just a habit, I'm too lazy to re-enter it as a second command in case upgrade was not enough on first try (it always worked fine, so I never bothered with the "weaker" one) :D

No franken-debian here, just vanilla install and basic sources.list :
deb ... stretch main
deb ... stretch/updates main

It is weird that you were not impacted... what do/did you have at this exact path : a folder or a file ?

I also see a line in the firefox-esr 60.4 debian changelog that may be related (https://tracker.debian.org/media/packag ... sr-1deb9u1) :
debian/browser.install.in, debian/rules: Properly copy the watermark to /usr/share/icons/hicolor/symbolic/apps.

Bulkley
Posts: 6383
Joined: 2006-02-11 18:35
Has thanked: 2 times
Been thanked: 39 times

Re: dpkg error on firefox-esr 60.4 update

#4 Post by Bulkley »

I have

Code: Select all

/usr/share/icons/hicolor/symbolic/apps/firefox-esr-symbolic.svg/
just as yours.

BTW, I run Openbox. You aren't running into a Gnome desktop error, are you? That would be awfully weird but . . .

User avatar
None1975
df -h | participant
df -h | participant
Posts: 1388
Joined: 2015-11-29 18:23
Location: Russia, Kaliningrad
Has thanked: 45 times
Been thanked: 65 times

Re: dpkg error on firefox-esr 60.4 update

#5 Post by None1975 »

Bulkley wrote: Having just received the firefox-esr 60.4 update without issue.
Same here.
OS: Debian 12.4 Bookworm / DE: Enlightenment
Debian Wiki | DontBreakDebian, My config files on github

User avatar
bw123
Posts: 4015
Joined: 2011-05-09 06:02
Has thanked: 1 time
Been thanked: 28 times

Re: dpkg error on firefox-esr 60.4 update

#6 Post by bw123 »

ffhuh12 wrote:Hello,

I made an apt-get dist-upgrade on my Debian 9.6 install today and got a dpkg unpack error related to firefox-esr 60.4 (currently running firefox-esr 60.3) : apparently it fails to update the folder "/usr/share/icons/hicolor/symbolic/apps/firefox-esr-symbolic.svg/"

I deleted this folder and it's content (watermark.svg) and the update went through correctly, which resulted in the creation of a svg file (the path is not a folder anymore).

Is anyone else experiencing the same behavior ? If so, could someone please report it as bug ?

Thanks
You're right. I upgraded one pkg, firefox-esr. Before the upgrade, /usr/share/icons/hicolor/symbolic/apps/firefox-esr-symbolic.svg/ had one file, watermark.svg

Now, there is no folder. It is a file. I have no idea why you had trouble or what it means. Upgrade went fine with no errors, on stretch kde plasma-desktop.
$ file /usr/share/icons/hicolor/symbolic/apps/firefox-esr-symbolic.svg
/usr/share/icons/hicolor/symbolic/apps/firefox-esr-symbolic.svg: SVG Scalable Vector Graphics image
resigned by AI ChatGPT

ffhuh12
Posts: 3
Joined: 2018-12-13 15:32

Re: dpkg error on firefox-esr 60.4 update

#7 Post by ffhuh12 »

Problem solved, I am writing it here so maybe it can help someone in the future : it is caused by a known bug with overlayfs.

Some parts of my system are copied into overlayfs and it seems directory rename operations are not possible in that case : https://bugs.debian.org/cgi-bin/bugrepo ... bug=836211
So when dpkg processed the firefox-esr 60.4 update, it tried to rename the folder to move it aside (must be replaced by a new file instead), but the operation failed.
Manualy deleting the folder before updating was the correct choice in that specific case.

If overlayfs can not be fixed (the bug is open since 2016), maybe dpkg could add an if case in the code to copy then delete (2 operations) the old files as a second try in case the move/rename (1 operation) failed ?

Anyway, I learned something today so thanks everyone for your feedback and support ! :D

User avatar
llivv
Posts: 5340
Joined: 2007-02-14 18:10
Location: cold storage

Re: dpkg error on firefox-esr 60.4 update

#8 Post by llivv »

ffhuh12 wrote:Problem solved, [...]
Some parts of my system are copied into overlayfs
interesting :!:

check out the spec and see if the overlay and lower is setup correctly..,
https://www.kernel.org/doc/Documentatio ... rlayfs.txt
Overlay objects
---------------
On 64bit systems, even if all overlay layers are not on the same
underlying filesystem, the same compliant behavior could be achieved
with the "xino" feature. The "xino" feature composes a unique object
identifier from the real object st_ino and an underlying fsid index.
If all underlying filesystems support NFS file handles and export file
handles with 32bit inode number encoding (e.g. ext4), overlay filesystem
will use the high inode number bits for fsid. Even when the underlying
filesystem uses 64bit inode numbers, users can still enable the "xino"
feature with the "-o xino=on" overlay mount option. That is useful for the
case of underlying filesystems like xfs and tmpfs, which use 64bit inode
numbers, but are very unlikely to use the high inode number bit.


Upper and Lower
---------------
I remember a time when it was possible to copy older files and directories over newer mangled files and directories (a lazy mans restore for example) and get shadows or ghosts of the newer mangled files and directories showing up through, around, from underneath the older copied over files and directories. A lot like a chroot can behave when mounted badly.
In memory of Ian Ashley Murdock (1973 - 2015) founder of the Debian project.

Post Reply