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

MSET9 is (probably) borked on SELinux. Potentially doing something that SELinux doesn't like that makes the drive unwriteable. #35

Open
trurune opened this issue May 17, 2024 · 5 comments

Comments

@trurune
Copy link

trurune commented May 17, 2024

During my MSET9 usage, I ran into a problem where MSET9 wouldn't uninstall, stating that there were no ID1s, and sure enough, there weren't, I thought this was just an isolated issue, however, upon looking at the homebrew Discord other people ran into the same issue, and there was one consistency that I found, and that was that they were all running Linux. Please look into this issue (my SD card also went Read-Only after installing, you may have a permissions based issue in which you are turning the drives read only, causing the fake ID1s to not be possible to write and therefore deleting the ID1.

@Anonymous941
Copy link
Contributor

Anonymous941 commented May 17, 2024

there was one consistency that I found, and that was that they were all running Linux

I've run this on Ubuntu before, and haven't personally encountered this issue (so it must not happen every time, but obviously still happens)

my SD card also went Read-Only after installing, you may have a permissions based issue in which you are turning the drives read only, causing the fake ID1s to not be possible to write and therefore deleting the ID1

That's really strange since FAT32 doesn't support permissions. So it's either a mounting issue, hardware issue, or you accidentally turned on the lock switch... Can you try running sudo touch test.txt on any folder in the SD card?

@trurune
Copy link
Author

trurune commented May 17, 2024

Hi Anon!
Yeah so from the looks of it, it may be something to do with SELinux, I am runnign arch linux without SELinux these days and sure enough, touch works. What may be the issue is SELinux, which runs at the kernel level, so even when I did mount as sudo (something I did try) nothing worked.

@trurune
Copy link
Author

trurune commented May 17, 2024

The main thing is, MSET9 is doing something that is making SELinux freak out and make the drive unwriteable.

@trurune trurune changed the title MSET9 is (probably) borked on Linux MSET9 is (probably) borked on SELinux. Potentially doing something that SELinux doesn't like that makes the drive unwriteable. May 17, 2024
@Anonymous941
Copy link
Contributor

Anonymous941 commented May 17, 2024

Yeah so from the looks of it, it may be something to do with SELinux, I am runnign arch linux without SELinux these days and sure enough, touch works.

I don't know much about SELinux but I think that it overrides root, so if touch works, then it probably means it's something else... Try running sudo ls -ld and see if the owner is root

What may be the issue is SELinux, which runs at the kernel level, so even when I did mount as sudo (something I did try) nothing worked.

Maybe try disabling SELinux temporarily and see if you can write to the drive?

The main thing is, MSET9 is doing something that is making SELinux freak out and make the drive unwriteable.

That's weird, maybe it has to do with the unicode craziness? You might want to test the SD card for errors in case the problem is that your SD card is failing, but to be honest I'm as confused as you are about all this (I'm not an MSET9 developer)

@Naim2000
Copy link
Contributor

Turns out this is much simpler than I thought.

When renaming/moving a folder, the old directory entry is marked as deleted and a new one is created. However the new one does not actually point anywhere until you've properly flushed changes to disk.
I wanted to rename 'apps!' to 'apps.', but whatever

So the solution is to just safely unmount the SD card. Or optimally, the script calls os.sync() before exiting, because nobody's stopping us from doing that. I hope.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants