Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Binary modification fills root partition until xochitl restart #781

Open
rM-self-serve opened this issue Dec 8, 2023 · 3 comments
Open
Labels
bug Something isn't working packages Add or improve packages of the repository
Milestone

Comments

@rM-self-serve
Copy link
Contributor

rM-self-serve commented Dec 8, 2023

Describe the issue

Modifying the binary via ddvk-hacks, #770, #772, or any future binary modification without restarting xochitl will lead to the system reporting the root partition as full.

This will result in failure if two binary modifications are applied sequentially as the second operation will detect the full root partition.

This is not apparent on v2.10 but is apparent on v2.15-v3.8.

In reference to #772 (comment)

To Reproduce

Ensure xochitl is running as a service and is >= v2.15

df '/' | tail -n1 | awk '{print $4}'
cp /usr/bin/xochitl /tmp/
cp /tmp/xochitl /usr/bin/
df '/' | tail -n1 | awk '{print $4}'
systemctl restart xochitl
df '/' | tail -n1 | awk '{print $4}'

Expected behaviour

N/A

Upstream issue

N/A

Screenshots

rootfull

@rM-self-serve rM-self-serve added bug Something isn't working packages Add or improve packages of the repository labels Dec 8, 2023
@Eeems
Copy link
Member

Eeems commented Dec 8, 2023

I think the solution we should implement for this is to move the modified version of xochitl to a location under /opt and use that instead. This may cause some conflicts with manual installation of binary hacks, but we already prefer that users don't do that and instead use the toltec packages. I'd be happy to open PRs in the various repositories to update their install/uninstall scripts to be aware of the new location.

@rM-self-serve
Copy link
Contributor Author

rM-self-serve commented Dec 8, 2023

I do wonder if #720, #770, and #722 being reinstalled on reenable has the potential to cause other packages that may write to the root partition (something like a service file) to fail since the root partition is reported as full.

I have tested reinstall on reenable for all 3 packages and have not seen the issue but it may still be possible.

@Eeems Eeems added this to the 3.x support milestone Dec 8, 2023
@Eeems
Copy link
Member

Eeems commented Dec 8, 2023

I do wonder if #720, #770, and #722 being reinstalled on reenable has the potential to cause other packages that may write to the root partition (something like a service file) to fail since the root partition is reported as full.

I have tested reinstall on reenable for all 3 packages and have not seen the issue but it may still be possible.

Service files are quite small, so it's probably not likely to happen. Xochitl itself is rather large, so having it fail to overwrite due to the lack of enough space shouldn't actually fill the partition. Plus the patching happens as part of configure(), so I believe that all the files already exist on the root partition at this point, as configure should happen after all the package contents have been extracted.

Nevertheless, this should still be something we work on resolving before 3.x support, as the root partition filling up is just as pronounced in 3.x.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working packages Add or improve packages of the repository
Projects
None yet
Development

No branches or pull requests

2 participants