Bug 1906833
Summary: | filesystem package upgrade fails on rawhide toolbox | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Bastien Nocera <bnocera> |
Component: | toolbox | Assignee: | Debarshi Ray <debarshir> |
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | butirsky, debarshir, harrymichal, kxra, ovasik, pknirsch, praiskup |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-12-18 23:07:26 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Bastien Nocera
2020-12-11 14:09:34 UTC
Actually, all those are mountpoints in toolbox: mount | grep -e ' /media ' -e ' /mnt ' -e ' /dev ' -e ' /tmp ' -e ' /sys ' -e ' /proc ' And all of them have non-standard ownership: $ rpm -V filesystem | grep UG .....UG.. /dev .....UG.. /media .....UG.. /mnt .....UG.. /proc .....UG.. /sys .....UG.. /tmp Are you sure only /dev causes problems? FTR, normal podman run doesn't suffer from this issue (only /proc and /sys needs to be handled, and /dev is mountpoint too, but it has standard ownership so rpm doesn't complain). (In reply to Pavel Raiskup from comment #1) <snip> > Are you sure only /dev causes problems? I don't, but that's the only error I saw, so that's the only one I reported. I didn't investigate further as I already spent a day and a half fighting other rawhide regressions in containers :) This is a duplicate of 1830830 It doesn't just affect Toolbox containers, but Podman containers in general. *** This bug has been marked as a duplicate of bug 1830830 *** > It doesn't just affect Toolbox containers, but Podman containers in general.
Not on my box. We fixed filesystem package on F33+ so rpm doesn't complain
in normal rootless podman container.
Ok, from 1830830 it looks like toolbox people are working on the work-around: https://github.com/containers/toolbox/pull/640 I commented there the bug in the PR code, but I don't think we can generally expect similar problems elsewhere (normal podman runtime) as bind-mounting down the filesystem-owned files isn't common. Switching against toolbox. Umm... why did you un-duplicate the bug? There are too many of these bugs about the same issue flying around. It would be nice to consolidate them a bit. *** This bug has been marked as a duplicate of bug 1830830 *** Because I disagree this is a duplicate. But it should be obvious from my comments? If you use container F33+, this only happens in toolbox, not buildah. > this only happens in toolbox, not buildah. I mean, that duplicate bug 1830830 is assigned to buildah. It's not about finding someone or some package (toolbox or buildah or whatever) to blame. We need to figure out a solution, whatever that might be and ship it to our users. For that it's really useful if the discussion stays consolidated in one place instead of getting fragmented across multiple bugs. Really, I'm not trying to blame anything/one. I'm sad you see me like that. I really don't see Buildah affected by _this_ bug. We invested some time to solve one buildah+filesytem in bug 1548403. Perhaps that solved the bug 1830830 as well? ATM there's a problem with /dev, /media, ... (not /proc or /sys). And this is not a problem for Buildah because it _doesn't mount those new paths_ to actually trigger the problem. No problem to track _this_ in bug 1830830, but it looks like something different when there's Component=buildah field. That's why I actually filled this bug. Looks like my comments in upstream PR#640 are not applied. Please consider them. Is there some reason this would be a problem again upgrading a F35 toolbox container to F36 (on a silverblue F36 host)? The workaround doesn't seem to make a difference now (In reply to kxra from comment #12) > Is there some reason this would be a problem again upgrading a F35 toolbox > container to F36 (on a silverblue F36 host)? The workaround doesn't seem to > make a difference now Dunno about the age of your f35 container, but I can't reproduce that in a fresh f35 updated toolbox if I dnf upgrade it to f36, at least. (In reply to kxra from comment #12) > Is there some reason this would be a problem again upgrading a F35 toolbox > container to F36 (on a silverblue F36 host)? The workaround doesn't seem to > make a difference now What was the exact failure that you saw? Do you have the /usr/lib/rpm/macros.d/macros.toolbox file inside the container? Yes, I think there were a combination of factors, as I was able to resolve it by: - dnf autoremove - dnf list --installed | rg fc35 - dnf remove fc35 packages - remove the /etc/rpm/macros.dist file https://ask.fedoraproject.org/t/how-to-upgrade-fedora-version-inside-a-toolbox-container/10463/8 I see. I am glad you managed to find a way forward. :) |