Container doesn't start because of missing /media possibly due to failed RPM transaction #539
Comments
|
Could you please try with Toolbox 0.0.94? Specifically, this error should be more detailed now: |
|
I doubt how I can try Toolbox 0.0.94 on Fedora Silverblue 32. |
Can I run Toolbox from within Toolbox? :) |
I created an update for Fedora 32 just now. You can use
Yes, but it will still be the version that's on your host. |
|
@debarshiray thanks! For now I just manually installed new Toolbox in custom dir, hope it should work OK from there. It doesn't help if I manually chown the |
|
@debarshiray thanks! For now I just manually installed new Toolbox in custom dir, hope it should work OK from there. UPDATE: And here we have an update!: Should I create |
|
I've compared working and non-working containers based on the same image. Please see if it could be helpful. I have run out of ideas.. |
|
Workaround I used: |
|
Thank you @owtaylor for adding the workaround! Owen shared with me the last lines of I believe I know what is going on there. The
I believe we're hitting the third point here. So, the solution should either be to handle cases when |
|
I see. Interesting. I'm puzzled why the The proposed solution of special casing the third point (ie., |
|
I just want to clarify this bit that came up in The older POSIX shell implementation used Removing the |
I'd say it was just something weird that happened to my toolbox, except that it also happened to @bam80 - I agree that every f33 toolbox has shipped with a /media. We still have problems with the filesystem package on 'dnf update' inside a container - maybe something happened there? The shell-like 'if [ -e /media ]' seems fine to me - it's infinitesimally less efficient than handling ENOENT, but makes the code easier to read, and there shouldn't be any risk of race conditions in this case - the toolbox init is the only thing manipulating the container. |
|
Confirmed - did something like: |
|
The particular error upgrading filesystem is similar to what we've seen before: I thought we were dropping in an /etc/rpm file setting %_netsharedpath either in the Fedora image or in the toolbox image, but I don't see that. |
|
Doing: echo '%_netsharedpath /proc:/sys:/dev' > /etc/rpm/macros.toolbox - before upgrading helps some - the transaction still fails because filesystem fails verification (permissons are wrong on /proc /sys /dev), but things are unpacked correctly and the image is left with a /media directory. |
The redirectPath function used to error out when handling directories, if the path inside the container was initially absent. There's no real reason for this, and recently some containers failed to start because the /media directory was absent from them. Therefore, it's better to not worry about the path being initially absent, and be more forgiving and robust. containers#539
The redirectPath function used to error out when handling directories,
if the path inside the container was initially absent. There's no real
reason for this, and some containers failed to start because the
/media directory was absent from them. This can happen as a
consequence of Fedora's filesystem RPM failing 'dnf update'
transactions inside containers:
$ toolbox enter f33-to-upgrade
$ dnf --assumeyes --enablerepo=fedora --disablerepo=rawhide update
<...>
Failed:
filesystem-3.14-2.fc32.x86_64
filesystem-3.14-3.fc33.x86_64
Error: Transaction failed
Therefore, it's better to not worry about the path being initially
absent, and be more forgiving and robust.
containers#539
That's a good point. Thanks for the reproducer.
True, but my OCD still compelled me to change it to handle |
debarshiray
changed the title
@owtaylor thanks for narrowing it down! Do we have problem with the filesystem package reported? |
After these manipulations, /media link replaced with /media dir on upgrade, not sure if it correct. |
The redirectPath function used to error out when handling directories,
if the path inside the container was initially absent. There's no real
reason for this, and some containers failed to start because the
/media directory was absent from them. This can happen as a
consequence of Fedora's filesystem RPM failing 'dnf update'
transactions inside containers:
$ toolbox enter f33-to-upgrade
$ dnf --assumeyes --enablerepo=fedora --disablerepo=rawhide update
<...>
Failed:
filesystem-3.14-2.fc32.x86_64
filesystem-3.14-3.fc33.x86_64
Error: Transaction failed
Therefore, it's better to not worry about the path being initially
absent, and be more forgiving and robust.
containers#539
I don't see that
/medialine at all when attaching to f32 container:The text was updated successfully, but these errors were encountered: