forum.pistar.uk

Hello!

I'm not quite sure what happened but at some point my Pi-Star got stuck in read/write mode (rpi-rw). Any time I go to the command-line to switch it back to read-only (rpi-ro), I get a message that states:

mount: / is busy

Any thoughts on how to debug this?

Easiest is to just reboot (sudo reboot); the shutdown phase should flush whatever activity is holding the file system open.

Granted, that /isn't/ debugging the root cause...

That did the trick. I ran 'lsof' to see if I could identify what was causing the issue but there were so many files held open.

And I had tremendous uptime!!! I was hoping to avoid the reboot...

Thanks!

Something in a recent update caused this issue, and it has happened once in a blue moon previously. Andy Taylor has been trying to identify the culprit but has been unable to so far. It's probably healthy to reboot once in awhile anyway!

KE0FHS wrote: ↑Wed Aug 15, 2018 2:51 am... It's probably healthy to reboot once in awhile anyway!

I power-down my Linux machines once per year for routine dust removal.

Glad to know that something was identified. I installed the image on several other SD cards to see if it was hardware related, configuration related (even rebuilt the config from scratch), or something else. It happens consistently, so I'm glad that it's not just me.

Has the root cause for this been identified yet?

This is actually a VERY serious issue! If the file system is left in a read/write state, it significantly increases the potential for file system corruption if the device isn’t properly shut down. Tanking the power cable is one of the worst things you can do with systems that leverage SD-cards (even MMC/eMMC for that matter.

I would have to think this is why read-only support was implemented in the first place. This is a high priority bug in my book.

I’ve had several cases where Pi-star images have become so terribly corrupted that fsck was unable to repair them, or worse the boot loader was damaged. The only way to recover was to completely reimage the device. Which sucks when you make customizations to the system that aren’t restored by the backup/restore capability (such as enabling HTTPS support).

I’ve gotten to the point where, periodically, I’ll shut the device down cleanly and put the SD card in another computer so I can use ‘dd’ to create a block level backup of the card. That allows me to restore to a known good state exactly as it was when I created the image.

I know someone that figured out what the issue was on his own and figured out how to resolve it. I need to connect with him to figure out what he did to fix it.

I am confident that rebooting the device was not the fix. He made a change to Pi-Star and has been using it on all of his repeaters.

Thankfully pistar-remote allows for a clean shutdown via your radio!

W4JEW wrote: ↑Sat Jan 26, 2019 8:04 am I know someone that figured out what the issue was on his own and figured out how to resolve it. I need to connect with him to figure out what he did to fix it.

It would be great if you could track down this info. I shut down my hotspots overnight and lately I've been noticing that they almost always start up in rw mode. This is quite different from a few months ago when it happened only occasionally.

I actually got in touch with the guy. He told me that what I heard wasn’t entirely accurate.

He got fed up with the fact that there was no resolution to the issue so he ended up building his own image. He refused to use Pi-Star with his repeaters for this reason alone.

I guess when you’re using it to run repeaters and they’re in far off places that you can’t get to easily, it makes sense that you’d have to find a way around this kind of issue.


Sent from my iPhone using Tapatalk Pro

Okay, thanks for circling back with that info.