dnf transaction fails inside Fedora container and corrupts container #108
Comments
|
I forgot to mention that using Docker instead of Podman works as expected. |
|
@giuseppe is this one of the bugs you fixed in fuse-overlay? |
|
I would bet it works well with root podman as well. |
|
I think this is already fixed, but the rpm didn't hit Stable yet. Could you try with https://bodhi.fedoraproject.org/updates/FEDORA-2019-ed81918b28 ? |
|
@giuseppe how can I test this package safely on Silverblue ? |
|
@yann-soubeyrand I think you can download it and install it as a layered package using rpm-ostree. |
|
@rhatdan it won't mess with my underlying ostree when I'll remove the layered package? |
|
Nope, that is the way rpm-ostree layering works. They can update independently. |
|
This wouldn't be a layer but an override. |
|
Sorry wrong terminology. Thanks @cgwalters |
|
It doesn't work either with fuse-overlayfs 0.5.2-3.git4dc60f0.fc30. |
|
But indeed, it works with root podman. |
|
Well maybe you are seeing something different, we don't see this issue with f30. Perhaps reboot after replacying the fuse-overlayfs, actually I think that is required on silverblue anyways. |
|
I think I know what is going on, it is an issue exposed by recently enabling FUSE writeback. Going to take a look at it |
I don't have toolbox any more as dnf upgrade crashed it. I did a podman run so I was in a brand new container ;-)
It's indeed mandatory to take the new ostree into account and I did it ;-) @giuseppe Cool! Working on Silverblue without toolbox is a bit incapacitating :-D |
introduce a hash map to refer from an inode to the file paths. A recent change where we enable FUSE writeback by default uncovered an underlying issue in fuse-overlayfs where changes to a file with multiple links would not be visible from the other link. For each inode, maintain a list of nodes that refer to it, so that we can still access it when a link is removed and more importantly we can use the inode value with FUSE. Closes: containers#108 Closes: https://bugzilla.redhat.com/show_bug.cgi?id=1744109 Signed-off-by: Giuseppe Scrivano <[email protected]>
introduce a hash map to refer from an inode to the file paths. A recent change where we enable FUSE writeback by default uncovered an underlying issue in fuse-overlayfs where changes to a file with multiple links would not be visible from the other link. For each inode, maintain a list of nodes that refer to it, so that we can still access it when a link is removed and more importantly we can use the inode value with FUSE. Closes: containers#108 Closes: https://bugzilla.redhat.com/show_bug.cgi?id=1744109 Signed-off-by: Giuseppe Scrivano <[email protected]>
introduce a hash map to refer from an inode to the file paths. A recent change where we enable FUSE writeback by default uncovered an underlying issue in fuse-overlayfs where changes to a file with multiple links would not be visible from the other link. For each inode, maintain a list of nodes that refer to it, so that we can still access it when a link is removed and more importantly we can use the inode value with FUSE. Closes: containers#108 Closes: https://bugzilla.redhat.com/show_bug.cgi?id=1744109 Signed-off-by: Giuseppe Scrivano <[email protected]>
introduce a hash map to refer from an inode to the file paths. A recent change where we enable FUSE writeback by default uncovered an underlying issue in fuse-overlayfs where changes to a file with multiple links would not be visible from the other link. For each inode, maintain a list of nodes that refer to it, so that we can still access it when a link is removed and more importantly we can use the inode value with FUSE. Closes: containers#108 Closes: https://bugzilla.redhat.com/show_bug.cgi?id=1744109 Signed-off-by: Giuseppe Scrivano <[email protected]>
|
It is not fixed for me |
|
Same with |
|
It could be SELinux blocking it. Could you try again with SELinux disabled? We have fixed recently an issue like that, so you might need to update it |
|
Yes, with SELinux disabled it works. Will there be version with SELinux enabled? |
|
container-selinux-2.115.0-1.gitfddfbbb.fc30 is the latest available. |
|
Thanks, i still have container-selinux-2.113.0-1.dev.git4f7d6bb.fc30.noarch |
|
114 should be in updates testing now, and might have the fix. dnf -y update --enablerepo=updates-testing container-selinux |
|
I use silverblue and i don't know yet how to enable testing repo in rpm-ostree |
|
|
|
Hi, 114 seems not to fix the bug: having container-selinux-2:2.114.0-1.git028ab00.fc30.noarch and fuse-overlayfs-0.6.1-2.gitc548530.fc30.x86_64 on Silverblue 30 and still hitting the bug. |
|
Hi! I went through the following steps.
From the /var/log/audit/audit.log file, I get: Did I miss something or is this bug still present? |
|
The AVC's indicate you need an updated version of container-selinux. |
|
From the informations you gave above, I thought I had a fixed version: Which version does contain the fix? And where can I install it from? |
|
It should be in that one, but I am wondering if it the modules is installed properly. |
|
OK, Can you keep us updated in this issue when the fix hits Silverblue 30 testing then stable? |
|
Hm, you may have hit ostreedev/ostree#1026 |
|
@cgwalters OK, if I understand correctly, this bug is not going to be fixed soon as it's not trivial, right? Is there a manual way to fix it (other than manually loading the policy after each reboot)? |
|
Answering myself: semodule command solves the problem permanently, thanks a lot @rhatdan ;-) |
/kind bug
Description
Doing a dnf install inside a Fedora container or a Silverblue toolbox results in failed transaction and corrupted container.
Steps to reproduce the issue:
podman --log-level=debug run -ti --restart=no --rm fedora
Inside container: dnf install jq (jq is an example, it could be dnf upgrade)
Describe the results you received:
DNF transaction failed. If the command used is dnf upgrade the system is corrupted (library files from the packages in the transaction are deleted).
Describe the results you expected:
I expect a successful installation of jq (or upgrade of the system if using dnf upgrade).
Additional information you deem important (e.g. issue happens only occasionally):
Issue did not happen a month ago. I don't know exactly when the problem appeared though.
Output of
podman version:Output of
podman info --debug:Package info (e.g. output of
rpm -q podmanorapt list podman):Additional environment details (AWS, VirtualBox, physical, etc.):
Fedora Silverblue 30.20190821.0.
The text was updated successfully, but these errors were encountered: