Pistar or Linux - Commands?

[G0KDT]

Not being massively familiar with Pistar or Linux I find reading many of the posts on maintaining a pistar hotspot mightily confusing.

Yes there are other sites that show some bits but I've not found one yet that sets out or explains the commands used.

For RPi the basics to sustain it from the command line (pistars SSH) were, to my knpwledge;

sudo apt-get update
sudo apt-get upgrade

So I used those but more recently I'm seeing what apparently new commends like;

sudo pistar-update
sudo pistar-upgrade

These are prefixed with Pistar- and aren't preceded with sudo for superuser permissions... is that all they do?

Trying to update the pistar image using these command resulted in several errors, which the suggested using

--fix-broken-install

somehow I muddled through those but it was far from a confident process, relying on guesswork.

I thought about updating the MMDVM firmware that seems a total minefield of potentially locked or partially built hardware conflicts with a variety of firmware for boards. Some seem to imply a need for downloading special MMDVM flasjing software and then;

sudo pistar-mmdvmhshatflash hs_hat

suddenly appears in one of the posts where folk are getting mightily confusing clarifying what to do.

So is there a list of Pistar commands with clarification vs the Rpi linux standard update/upgrades posted anywhere....

[M1DNS]

Theres the Bin. list, not extensive, but those that will prob. see most use for the average user...

https://github.com/AndyTaylorTweet/Pi-S ... ries_sbin/



Sent from my SM-G935F using Tapatalk

[G0KDT]

Ok Andy.

I looked and can see the links to source code/script files but no real explanation, so I'll take that as a 'No, no real documentation unless you are part of the inner circle of the coding and pistar team'..

[G8SEZ]

To answer the question a bit more:

sudo apt update
sudo apt full-upgrade

these are used to update any available packages in the underlying OS, now known as RasPiOS and based on Debian Buster. It is sensible to run rpi-rw before these two commands to put the filesystem into read-write mode, you can also run rpi-ro afterwards to return it to read-only mode but this is not necessary and if /mount is showing as busy then this indicates the need for a reboot.

sudo pistar-update runs the update scripts for various bits of Pi-Star including the binaries, dashboard, host files and firewall. Normally you run this manually from a terminal reached via the SSH access command on the expert configuration page, you can use the update command from the dashboard in which case the OS updates will not be run as you are not in a terminal. This is what the overnight update process does, but there is also an unattended-upgrades package installed as part of Pi-Star that performs updates of security-related packages when necessary.

sudo pistar-upgrade runs the Pi-Star upgrade script which may have been modified by the pistar-update process, it's sometimes necessary to run a couple of cycles of these two commands to get everything up to date.

Again if you see a /mount busy message then it normally means a reboot is required, this now has an OK/cancel dialogue in case you click reboot by accident.

HTH

Oh yes, and "read the source Luke" applies, it's all in the github repos.

[G0KDT]

Thank you for the extra detail Brian. Having read through those points and not being someone who is fully at home with Linux as I'm sure many other users aren't the divide between Linux (Debian) and Pistar and its supporting scripted features/services are really quite blurred.

When I first played with RPis' the command was of the form 'sudo atp-get update', yet now 'apt-get' seems to have changed to simply 'apt'.

The pistar- 'update' and 'upgrade' functions I already considered by deduction to work as you describe, providing the facility to compare installed vs available updates in step 1 and the doing the updating in step 2.

I can only presume that the pistar- variants of those commsnds do things that the basic Debian update/upgrade wouldn't alone. If that is the case then really we need to have better clarity of these SSH commands, which was the point of asking my original question.

I can't say I have ever seen 'rpi-rw' used anywhere but I do understand the need for the update/grade routines to be able update/replace the necessary files stored. However it was my understanding that use of a preceeding 'sudo' would have granted any called procedure the necessary adminitrative rights to enable any invoked child process functions read/write.

I recognise the 'Expert' setting menu options and appreciate the points you make about needing to cycle use of the commands either from the dashboard or SSH terminal. The latter route I think giving more feedback and where I encountered the '--fix-broken install' feedback I mentioned in the first post.

Sorry, I don't follow the 'read the source Luke' comment, though its probably an insider joke. I have looked at the link Andy posted to Github repository but I could not find anything but the code scripts and whilst some have REM or Supporting commentary most don't give much clarity unless I were to decide to learn and understand the full code.... not going to happen.

I thought I'd ask the original question to see if it is worth continuing with use of Pistar. I say this because I updated to v4.1.4 which wasn't much fun when various errors were reported but found my way through more by luck than design I felt... far from ideal.

Add to that, that the MMDVM firmware potentially needs updating to sustain the changes in Pistar. Then without better documentation, I'm at stage where I am simply considering forgetting Pistar as auto updates that occured between 4.1.1 and 4.1.2 simply made things a problem and fixing them was a mess and I don't want to contend with thing 'undocumented' happening like that least of all when there isn't proper documentation available.

[G8SEZ]

Well I tried to help as much as I can, and no the "read the source Luke" comment is not an insider joke, but it does imply a little bit of effort in looking at the scripts in use to see what they do. I'm as bad at this as the next man, and I've only been using Linux for 27 years or so, but the thing is that documentation of rapidly moving projects is a serious challenge and the people who write the code are better used in that than in documenting beyond a certain irreducible minimum.

I hope that you continue with Pi-Star, there are alternatives of course but I can only say that if you read the forums of a well-known manufacturer it is just as full of confused people asking questions and often failing to read the manual or failing to find essential information in the manual(s).

I am full of admiration for the people that created MMDVM and Pi-Star, in just the same way as I am for the people who created their own fully-supported alternatives that don't always work as one would expect them to despite the payment of additional folding beer vouchers.

Very complicated all this stuff, it says here in small print.

[G0KDT]

Jason,

Thanks for your points. I recognise your callsign and Brian's as two of the more prominent ops on the forum here aside from the Andys.

From what I can tell, based on using the pistar calls some things aren't necessarily correct as pistar-update followed by pistar-upgrade failed a number of times in succession when tried and I then found the --fix-broken install by running the standard update/upgrade functions which once called and followed by a standard update/upgrade then seemed to fix things. As I say it was more by luck than anything.

I think as the 'Home of Pistar' I was hoping and expecting there to be some 'Sticky' threads posted on the forum that covered commands and gave guidance on updating both pistar and modem firmware which is equally bewildering if you read the various websites discussing DV/APRS opsthey often seem to contradict each other and confuse.

[G0KDT]

Jason\Brian,

I'm trying to answer and sustain balance here. Forgive me I have quoted without using the forum quote feature as it got too fiddly so If I got it wrong then please excuse that.

What's not correct?

Your statement that the Pistart-update/upgrade routines should "handle all of the Linux commands...". Brian says something similar in his post.

So my comment, is not a criticism, but an observation. As I said, those routines did not seem to achieve the desired outcome, certainly not run from the expert dashboard or prefixed with 'sudo' from SSH which is how I ran them first. Maybe something didn't sync, or something else, I simply don't know.

Your statement, "Its confusing but sudo is not needed for rpi-rw and rpi-ro"

and

Your point - "Most of the time just the normal "sudo pistar-update" will do everything on its own and not require any input from a user".
I agree, and when people who, like You and Brian say things like that, and they have been using Linux 27yrs (Brian) or are finding things confusing too, then it is no wonder that oters with less familiarity get confused or worse, feel lost. On the second of those points I accept that you 'quality' that point with "Most" so I am hoping that you will understand that I am trying to be clear and fair.

Paying attention to the MMDVM firmware update part of your reply. That sets out positively but is rapidly qualified, not unreasonably, with caveats as to where things can go wrong for users. Your summary of flashing boards and "quite a few don't have any issue" is hopeful but I like to try and check things before diving in, so.

In fairness I have read a number of internet posts on other sites discussing these firmware updates. So far none have really setout step wise the approach to take, and in some of them they seem to come with warnings/implications that flashing the MMDVM can lead to problems needing to go to low level settings to reconfigure the Modem hardware for offsets and BER readings. So far I have not needed to change offsets or adjust anything to address a BER problme between transceiver and hotspot. Were a firmware flash to trigger a need to do that, then once again a logical walk through to do this would be a useful sticky post.

Perhaps it would be good to have a some example pics of MMDVM boards to aid identification. My MMDVM board is in all probability a 'Clone' or 'Chinaspot' as some call them. If I understand correctly, then on some boards the connections from the RPi Gpio are not made to enable serial data to flash the MMDVM. There do seem to be some other exceptions, the detail of which I have to politely say I cannot recall accurately so I don't want to post here as that may mislead others in incorrect or confused. You yourself have already been specific in the case of the "MMDVM_HS_Dual Baord by DB9MAT DF2ET & DO&EN". Truthfully a number of people have posted their stories but generally the descriptions often spread across a number of posts between commenting ops some right some possibly wrong, can quickly become disjointed and confusing.

As Brian says, the software development is a considerable feat and has clearly drawn on the resourcefulness of many people in specialist areas. The breadth and depth of the knowledge they have is considerable and the product open-sourced as it is, is not unappreciated. It is true to say that as a software collaborative the Pistar site don't technically need to post anything to cover anything more than the pistar commands. That said I suspect a very high number of hotspot builders would find it extremely helpful to have.

On that note, I think I should cease.

[G0KDT]

Like I said before. You sit down and make a list of things you think are important and useful and I'll sit down and address each one of them as best I can. Then we'll figure out a way to get it in some sort of sticky or FAQ or whatever.

I think you wrote a lot to finally contradict you earlier statement that you simply don't think sticky posts with guides aren't useful. So I take that as a 'no' and I would be better using a supported product.

[G8SEZ]

I think the Pi-Star wiki is the obvious place to put this information, it ought to get a link on the forum pages too.

I can see Phil's point, some extra help would be a good idea.