First information for new Pyra owners (FAQ)


My Recovery SD Card is back in the GBA Case whit the other not used Cards,
I have now my 2 Standard SD Cards in: 128 gb whit Roms, and 400 gb for the DBP Files and Documents etc ..
shure it’s not the best way to learn when I avoid these problems, but where should I learn the solutions? Evening Shool is closed, due to Lockdown, so I don’t think I could get an VHS Course „Debian ARM HF for Hobby Pyrats ^^ Or „How to use an Ultra Rare Linux Handheld“ ^^ , I could search the Internet for Tutorials, and try to improvise because I would have to see what fits on the Pyra..

Using the Pyra isn’t that though, when you know how to search the Internet for the right Linux Software for your purposes, and what package you need to pick from Synaptic.. ,
But things that are deeper in the Debian, like putting out the Boot Flagg on your SD Card is a bit different.. , or to know how to fix the Pyra when this happened like today..
I think I would rather screw the bottom part open, to fix some shoulderbutton, then ever have to had a Pyra that stopped Booting..
Maybe this was that annoying as the time, when trying to change the bottom part of my Pandora, but it’s fell down to the ground because I made the false moves, and on my attempt to fix it, I broke one shoulderbutton contact (but at least the Pandora still works) , also this was cause by myself..



Not send from my Pyra, but my Pyra is also here whit me ^^
 
Djoga'Ro said:
That's the wrong lesson to learn. The correct lesson rather goes like: I need to find out how to distinguish between the storage devices/partitions on a linux system and triple check every time that I do the operations on the correct device. (I don't know how it is on ARM, but on PC I've seen that occationally the device names get mixed up. So what's (almost) always called /dev/sdb one time was called /dev/sda and the other way around.) See to that you give the partitions names you can recognize them by.
Click to expand...
Yes, /dev/sd*n* can vary between boots. If you want very consistent, use /usr/disk/by-uuid/ which contains links to your partitions based on the UUIDs, or if you get into the good habit of labelling your formats, /dev/disk/by-label can be more human readable, and stable and unique provided you set your labels uniquely and don't get in the habit of changing labels with e2label too often.
 
matzesu said:
What’s wrong whit just push the Sd Carts out on every Boot, and then push them back in when the Bootloader allready decide to boot from internal storage?
Click to expand...
It's mildly annoying. But as I understand it it only tries to boot from SD if the SD incorrectly advertises itself as bootable, in which case I do not mind because it's probably pretty easy to properly format SDs to not do so. Besides, I plan to make bootable SDs and thus I think it's pretty cool that the left SD slot can be used for booting.
 
cinaeco said:
@matzesu:

  1. Grab the latest https://packages.pyra-handheld.com/images/buster/test33-install.img.7z
  2. Extract that 7z file to get an .img file
  3. Write that image file to an SD card with something like etcher
  4. Insert SD card into Pyra left SD card slot
  5. Power on, and it should start flashing.
From there, power off when it tells you, eject the SD card, power back on, and you should get to the first-run setup stuff.
Click to expand...
aTc said:
Sounds about right.

Just be very careful with the resulting sd card, it will overwrite the pyra emmc immediately without prompt when you leave it in the pyra and restart :)

The card you get is fat32 formatted, and you can replace the test33.img.tar.zst file on it with a newer version without having to rewrite the image ( filename doesn't matter, the installer will use the first *.tar.zst file it finds), same with the uboot dir on there.
The reason it needs to be written as a .img in the first place is because uboot needs to be installed on it in the space in front of the first partition.

the test33.img.7z can be written to an sd card to get a bootable sd card with the normal os. Unfortunately it doesn't resize to fill the sd card at first boot yet (got a half working version of that, but there's just so much other stuff to do), so free space is limited.
Click to expand...
This is the sort of information that should be in the Wiki. So I've updated the Manual
 
Good idea. I've linked that in from the front page. It can start out as a FAQ, but in time it could be refactored eventually into a more traditional manual. Or perhaps if it works best as a FAQ it can stay as one and be renamed and we start a prose written manual on another page.
 
Some os images are designed to automatically flash emmc while others can be used to boot from sd card ? How to differentiate which image is for what ? or any image from left sd card will overwrite emmc while same image in internal sd card will boot ?
 
docbroke said:
Some os images are designed to automatically flash emmc while others can be used to boot from sd card ? How to differentiate which image is for what ? or any image from left sd card will overwrite emmc while same image in internal sd card will boot ?
Click to expand...

Yeah, some images are like that for systems where you can’t just boot an iso burned to a flash drive or DVD. I have a Pinebook Pro, and it’s the same there.

In the Pyra’s case, the system images are here: https://packages.pyra-handheld.com/images/buster/ with the latest one as of now being test33. The images with “install” in the name will automatically flash the system to emmc, erasing anything that was on it previously in the process. On the other hand, images that don’t say “install” in the file name can run directly from the SD card that you write them to, leaving emmc untouched.


Sent from my iPhone using Tapatalk
 
Dit someone else notice that the LED On the LID Logo wasnt ON after the last Update? It charged, the RED LED on the Power Button was on, then it was full, the LED on the Button was Off, and you can just Boot the Pyra fine..
After my Reflash, and after the first apt update apt upgrade, its green LED that indicates that the CPU was on during Charging was on when i charged it this night..
So i had to shutdown the CPU by pushing quite long on the Power Button (More than 8 seconds), i hope my Reflashed Version gets Updated to the state where it was when i screw up the File System ^^

EDIT: And i have to think about this Signature: On Pyra its fine, but im currently on my Work PC whit WIN 10 and Firefox..
 
matzesu said:
Dit someone else notice that the LED On the LID Logo wasnt ON after the last Update? It charged, the RED LED on the Power Button was on, then it was full, the LED on the Button was Off, and you can just Boot the Pyra fine..
After my Reflash, and after the first apt update apt upgrade, its green LED that indicates that the CPU was on during Charging was on when i charged it this night..
So i had to shutdown the CPU by pushing quite long on the Power Button (More than 8 seconds), i hope my Reflashed Version gets Updated to the state where it was when i screw up the File System ^^

EDIT: And i have to think about this Signature: On Pyra its fine, but im currently on my Work PC whit WIN 10 and Firefox..
Click to expand...
Maybe an "apt full-upgrade" is needed?

But the general way you do it is correct:
apt update (Debian searches for updates in it's repositories)
apt full-upgrade (The updates are being installed AND old stuff will be replaced if necessary for upgrade)
reboot (or shutdown at the moment, since reboot is not working if I remember correctly)
 
Ok, but i dintnt used apt full-upgrade, just the normal apt upgrade (whitout full)..
Will Full-Upgrade still work now that i allready installed the Updates?

Maybe i should sometime make me a TXT Dokument whit all of these neccesarry scrippts
 
Ok made the Full Upgrade, but this thime it ditnt made something, seems like this works only when there is an update
i will try to remember some comands,
Apt update, apt full-upgrade are easy..
 
That's because apt ain't apt-get. The former is "better suited for interactive usage" and supposed to be more higher-level than apt-get so you don't need to interact directly with all the other related tools anymore. It's been around for a few years now and gained more popularity recently.
 
Ah, stupid users and all of their dependencies. If a tool's broken, fix it, don't write another tool that uses that tool but does the same things differently.

But it looks to me like you can do an apt upgrade followed by an apt autoremove to have the same effect as an apt-fullupgrade, but maybe I'm misunderstanding the different between apt upgrade and apt full-upgrade because what NetBloks said and the debian man page don't seem to be in complete agreement as I read them.
 
  • Like
Reactions: rSl
full-upgrade is AFAIK just dist-upgrade with a less confusing name. It does not replace autoremove, but it will remove installed packages if they are conflicting with an updated version of another packages. The default upgrade behavior does not touch package updates that cause new conflicts, so they will appear as updates that are being held back. dist-upgrade/full-upgrade just tries to fix these new conflicts.

autoremove on the other hand simply removes all packages that are marked as automatically installed but do not have any other package that depends on them, this is used for getting rid of old unused dependencies like library packages that have a separate package for each mayor version. If an update depends on a newer version in a separate package, the package of the old version always remains installed on the system until you do an autoremove.
 
I though this morning about some sort of a "OS Tracker" Thread: If you make sudo apt update sudo apt full-upgrade on your pyra, and it makes something, you just leave a posting (which should work whit the Pyra quite good), that there was an update, but if there arend any Updates, you could write that there arend got any updates (whit Date and Time Stamp)..
Because outher than IRC i dont find any Info about Software Updates, and on the Pyra, every small update is good..
 
Normally you should use "upgrade" rather than "full-upgrade", as the latter does additional things you may not want or expect. I'd leave a full upgrade to when it's advised to do so.
 
This is strange, because in this thread, i got the Advice to make full-upgrade, because this also makes sure everything fits whit the new versions..
And i think at least the next Upgrade will be full, because after my Reflash, my Pyra runs the CPU whyle its on Charging, and the CPU dosnt shutdown when its full..

So lets say: I put the XBOX Controller Cable in my Pyra on Evening, the Red LED on the Power Button is on, and also the Green LED on the LID Logo,
then somethimes in the Night, the Charging is finished, the RED LED gos off, but the Green LED is still on, which i assume stands for "CPU is Running".., allthough its dosnt cost that much energy, its causes a drop on the Batterie Indicator of 10 %..
I know, after the last update bevor i screwed up my Filesystem, it was Charging whitout the CPU because the LED was dark whyle charging, and when i pull the Cable out, and push the SC Cards out, i was able to boot quite normal..
This and the last morning, i had first to push the Power Button more than 8 seconds to first shut down the CPU to make a normal boot..
 
matzesu said:
This is strange, because in this thread, i got the Advice to make full-upgrade, because this also makes sure everything fits whit the new versions..
Click to expand...
It's certainly a good thing to do it occasionally, but it does install / remove additional applications. It's not something you need to run every day. As a general rule, I used to use dist-upgrade (now full-upgrade, albeit there are slight differences), when I wanted a newer kernel version, or if a new version of a specific application was only available if I did so. If the system is stable, and I have nothing new I want to upgrade and/or use, I'd normally just use the "upgrade".

Edit: I'm happy for someone to correct me. I haven't used apt much as I currently use an Arch-based distro that doesn't use apt
 
Last edited:
You must log in or register to reply here.

Similar threads

jedi23
Pyra Unofficial Quick Reference
2
Replies
32
Views
13K
TeDaDeS
TeDaDeS
matzesu
How to Develop/Port for the Pyra as Noob
2
Replies
21
Views
4K
kuru
kuru
EvilDragon
Information about OS / Kernel / Prototypes
2 3 4
Replies
79
Views
46K
docbroke
docbroke
spaceharrier
Using Old SD card (with Emulators & ROMS) in new 1GHz Pandora
2
Replies
35
Views
5K
foft
foft
G
Information Gathering For Gp2x Review
Replies
7
Views
2K
donny662
D
Back
Top