Quick update and summary

[hns]

I believe from what I thought I heard from slaeshjag, There was some features of AUFS that can't be done with OverlayFS, I just know it's something that fundamentally breaks how the DBP system works.

I have not yet heard about that. Generally it would be much easier for everyone to avoid out-of-tree drivers or file-systems because they may block upgrading to newer kernels with security fixes. So maybe someone knows details.

 

[Linux-SWAT]

A standard button set up for applications should be put on vote soon to avoid the OP mess.

 

[levi]

As long as nobody designs software to use the A button, as happened for some early Pandora software we're fine IMO. Nobody would choose Y, the top button by default, and as long as they choose between B and X I don't mind which they use personally. I had a PS1 where Japanese games used O for yes while western games used X, and that's just the same.

 

[lukey]

AFAIK OverlayFS doesn't work with FAT32 SD-Cards.

 

[Zook]

While waiting for the Pyra preorder, I've started college, almost have my Associates, and am officially over 30 years old now as well.

2 more months though and I'll have a Pyra.. and probably my BA.

 

[Grench]

AFAIK OverlayFS doesn't work with FAT32 SD-Cards.

I don't plan to use FAT anything on an internal card in a Pyra.

 

[Silent-Hunter]

I think they want people with Windows PCs to be able to put the SD card in their computer to put media on it.

 

[levi]

I don't plan to use FAT anything on an internal card in a Pyra.

Yeah, but it also applies (or perhaps only applies, I've not considered the full eventualities yet) to removable cards inserted into your Pyra. People have and do use FAT32 cards on their Pandoras, and will likely do so on their Pyras too, probably mainly because they just bought a card and inserted it into their device, I guess. Whether you consider removable cards to be internal or external is debatable though.

 

[Zwerg01]

While waiting for the Pyra preorder, I've started college, almost have my Associates, and am officially over 30 years old now as well.

2 more months though and I'll have a Pyra.. and probably my BA.

Check this forum again, when you have your PhD.

 

[hns]

AFAIK OverlayFS doesn't work with FAT32 SD-Cards.

I have found such a hint (German Heise forum): https://www.heise.de/forum/c-t/Komm...n-und-Raspbian-Stretch/posting-30979477/show/
So it appears that there is (was?) a limitation with FAT as "lowerdir". According to https://wiki.archlinux.org/index.php/Overlay_filesystem or https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt the "lowerdir" is the directory that is made read-only and overlaid by a writeable other directory.
I do not really know details how PyraOS is using overlays, but would assume that in our case the "lowerdir" is the factory installed PyraOS in eMMC. And the "upperdir" are the files on the SD card that is inserted, so that files from the SD card appear in the correct locations of PyraOS but don't overwrite anything. This is opposite to that OverlayFS would not work with FAT SD cards becasue it would not be used as "lowerdir". It seems as if it would not work with FAT in eMMC.
Maybe the PyraOS developers can clarify.

 

[levi]

The overlay is between the DBP (which is generally some kind of archive or an iso) and the appdata folder. The former is read only, so it might be workable, but they both originate from the sd card. The eMMC would only be used for loading shared libraries in the main.

 

[Splintercat]

Just did some testing with overlayfs, in the hope that maybe NTFS or ExFat would support the needed features.
Overlayfs refuses to mount Fat32 (Through vfat) filesystems even as a lower directory...
It can mount exFat and NTFS filesystems as a lower directory, but cannot use them as upper directories...
(Lower being read-only directories or devices, Upper being where changes are written back to..).

So right now if you used OverlayFS on any of the common Windows filesystems you wouldn't be able to store things like config data for a pnd in the /media/SDCARD/pandora/APPDATA/APPNAME.

There's probably some clever way you could deal with that issue, but if AUFS works it's probably the better call. Additionally AUFS appears to still be compatible with the latest Linux Kernels so I don't think it'll cause any potential upgrade problems, at least for a while.

That all said.... I think Flatpack, or possibly Snapcraft could be worth looking into for packaging systems, or at least be worth studying for features for DBP to support...

If I get really motivated about it, I will see about contributing to DBP and could research adding the option of it supporting OverlayFS mounts when the underlying filesystem can support it.

 

[levi]

If I get really motivated about it, I will see about contributing to DBP and could research adding the option of it supporting OverlayFS mounts when the underlying filesystem can support it.

What would be the benefit of that? I can only forsee problems where developers are only testing using one technology and some users end up using something else. That already causes some problems, but I can see it being a lot more complex with their being more variables to consider. You could add it as a #defined configure option or something so that if we ever go down that route in the future, you've already done the work, but I wouldn't have it auto-deciding when aufs might be older and perhaps a little crufty, but does work for us.

Thanks for testing out OverlayFS though. I'd have thought exfat would be the primary fat format in use today, what with everything being formatted that way when you get them, but it doesn't help to not support even relatively common filesystems.

 

[mclien]

Don't die ED.

Not till I have my Pyra. Then... you have my permission to die.

Hmmm, so you dare to raise the wrath of fenfire?? I think that might not be very wise, but well it's your life

 

[Swordfish II]

@EvilDragon

It's been 20 days since the original post. Surely there must be an update on the new case manufacturer or how many prototypes have been made and sent out?... Devs can't get working without them and there are only 10-13 right?

 

[TrashyMG]

@EvilDragon

It's been 20 days since the original post. Surely there must be an update on the new case manufacturer or how many prototypes have been made and sent out?... Devs can't get working without them and there are only 10-13 right?

All the major Devs have Prototypes already...

 

[docbroke]

All the major Devs have Prototypes already...

Eagerly waiting for images/videos of new prototypes

 

[TrashyMG]

Eagerly waiting for images/videos of new prototypes

they all have older prototypes, some have just internals from what I understand.

 

[Swordfish II]

they all have older prototypes, some have just internals from what I understand.

So not the fully revised with the cases from form action....which was what i was asking about. ED mentioned mass production would not happen without test and eval of the latest

 

[Grench]

Eagerly waiting for images/videos of new prototypes

Agreed. When we last left off in the saga, @EvilDragon had to order up some stronger magnets for lid switch activation...

they all have older prototypes, some have just internals from what I understand.

I think he was pretty clear that he/we would like to see something of the new prototypes. Yes, the most important software devs have some early prototypes - some of them even have semi-functional cases on them. What we're all hitting F5 for in this thread is more news of the latest generation of prototypes - hopefully fully functional with shoulder buttons, etc... I.e. we're all sitting with our fingers crossed in hopes that this round of prototypes will be nearly the final step prior to mass production. It is an exciting time for the project.

Sometimes lack of news can be more disturbing than bad news - though we're all hoping for good news. But - is there any new news?