Million Thanks in advance!!!
Volumio 2 is what I see in axiom air presentation? smart move there having a product that runs on it, pretty sure it was the only way to deploy volumio 2 in a fast way 
BTW will it use SquashFS or something? you know: kids unplugging the power cable while it’s writing the sd… and then parents complaining about why it’s not working anymore … :mrgreen:
AxiomAir will be based on Volumio2, but with an heavy customization on top. So yes, basically we took the chance to develop the 2 projects in parallel thus obtaining Volumio2 in a faster way and ensuring that AxiomAir will take the best of what Volumio2 is, with some custom features added.
And yes: one of the good news is SquashFS. But we wanted to have best of both worlds: a fast boot, secure power removal and still mantain an easy way to install utilities and edit the system as the user wishes.
It will work this way: on boot we’ll load the squashFS filesystem layer and place it on RAM (fast boot and low memory footprint, optimized a lot on this side). Then, thanks to overlayFS, we’ll add a writable layer on top of it (a third user writable partition) where all configurations and user data will be stored. This way the core system will be protected against power failures while keeping all the customizability of a RW system.
So nothing will change when you apt-get something or add new deamons and functions. Only difference is that you can’t remove something pertaining to the SquashFS (so nothing of the core system can be removed).
On updates, we’ll just update the SquashFS images, therefore user data will be persistent . And we’ll have a fail-proof update system, thanks to a 1:1 copy.
We’ve put lot of thought into this aspect, and honestly this is one of the new features I am most proud of.
We are currently testing this part (required a lot of work and a custom initramfs from scratch) and it should make its way into the build repo in few days.
If everything goes as planned, we’ll release a new beta image later this week. It will be usable (but without spotify) and will give you quite an idea of what the final system will be.
I originally planned to release Volumio2 in the first days of october, but think there will be a slight delay.
If you guys are willing to start testing ,this could be a major help in spotting bugs and things to improve.
Needless to say, a huge amount of love and passion went into this. Guess you feel that!
PS: I removed the post by jonas because it was irrelevant and irritating.
Thank you for the detail. I plan for next project using, of course, Volumio2, to use an Oled display for information such as song title artist time volume etc. My question : will the next release advanced enough to start the write of a plugin to do this ? Or is it to early.? And how to start? And for hardware button ?
This sounds great, i am ready to beta test.
Let me know if you need any beta images hosted and i will update the servers with them 
Concerning filesystem: I’m now quite sure that many SD cards don’t have built-in wear leveling. I know because just now I found an issue with an old Sandisk I was using.
I think it would be extremely positive if the RW partitions are all formatted using one of the filesystems I suggested here:
filesystem-t652.html
Also, check well this page:
wiki.openwrt.org/doc/techref/filesystems
It states clearly that SquashFS has better compression over JFFS2, but it is very sensible to bad blocks.
Of course we all would like to have perfect SD cards, but that is not the real world and I again think JFFS2 would be the better choice. JFFSw can be booted nowadays, so why not… or be SURE to use UBIFS as basis layer for SquashFS to get wear leveling…
en.wikipedia.org/wiki/UBIFS
You are reworking Volumio, and you know that most people will use SD cards, why using an old filesystem known to have issues?
Ooh questions, questions 
Questions 
All the questions 
It’s good to see your eagerness Balbuze, mabey some of your questions will be awnsered when you try one of the beta’s 
I havent had time to test run the beta vm’s so i dont know either 
good answer Michelangelo, it was what I was hoping for (squashfs+overlay), but I wasn’t expecting it in volumio 2 :mrgreen:
Wish you the best for both projects. Still astonished by air’s kickstart success!
300+ GB lossless library and a picky user ready for beta testing
raspys 1 b+ and 2 | iqaudio pidac+
Been looking at volumio2, I must say it is promising! I like the support for plugins, will enable people to make interesting things.
I am ready to test it
Very promising and awaited version by the community :!!
Interesting, and agree that since we’re rebuilding it, is worth building it right.
So, it appears that we have this FS support:
btrfs cifs dlm ecryptfs fuse gfs2 hfs hfsplus isofs jfs nfsd nilfs2 nls ntfs ocfs2 overlayfs quota reiserfs squashfs udf xfs
No Ubi… But we have jfs… In your opinion what could be a good strategy? Use jfs as FS on the partition that contains the Squashed image and on RW layer?
We have the plugin system up and running, so yes, this will be a great chance to start developing some extra plugin… And maybe set up a guide while doing that…
What about organizing an hangout meeting where I’ll teach how to build a plugin? This would be a good piece of documentation once posted on YT…
ok for a metting!
but not possible for me before friday evening.
let us know.
Ok, I will see how the team also replies to this
Interesting, how did you get that list?
First of all, UBIFS is not suitable, my bad. It works on raw flash and not on SD/MMC cards.
JFFS2 is ok and already in the Kernel since 2.4.10, ages ago.
Maybe you simply didn’t compile it?
sourceware.org/jffs2/
Maybe it is also worth to open/search a question on Stackexchange about this topic, choosing the filesystem for SD cards.
Samsung has made Flash Friendly File System (F2FS). Designed to be used with flash storage like SD cards.
Over at XDA theres a review with a comparison tot EXT4, it looks promising.
http://forum.xda-developers.com/showthread.php?t=2697069
I would also be interested in this plugin building hangout, great idea!
I did some more search about SD cards, wear leveling and so on.
I know that some devices Volumio can run on have other storage devices, but you’ll see that it’s easy enough to solve every issue on all of them at the same time.
According to the specifications (read answer here: electronics.stackexchange.com/a/27626/17526) SD cards do not NEED to have wear leveling. Some do, some don’t.
I experienced how some from even Sony don’t!
Also, and this is very important, SD cards won’t report a writing error!
This is BIG. Really BIG.
I’m very sorry Michelangelo if I make you work more, but I really think that a device like Volumio which may run for months unattended should not experience issues with corruption, especially since this means reflashing, reindexing, and so on.
However, I found a solution for you.
The way is to use btrfs (or ZFS on Linux, that would be nicer and cleaner but more complex).
btrfs has three things that solve all the issues mentioned:
- it writes a checksum on the disk every time it writes data, and it checks the checksum when reading. Even if SD cards don’t report a “writing error” as HDDs, the checksum won’t match. Corruption is DETECTED (and the block marked as defective).
- btrfs can store two copies of each block written on a device (unix.stackexchange.com/questions … linux-with). This means that Volumio will take twice the space (but it’s not a big issue, Volumio is small), but when one sector is found corrupted, you still have the data elsewhere.
- btrfs is copy-on-write, meaning that when writing a sector or a block, it will not overwrite the old one, but choose another empty block. This means that before writing a block twice, all the other ones are used FOR SURE. At that point, round two of writing starts
In addition, and this may be useful for you, you can have snapshots. If you make a change you find disrupting or you want to cancel, you can roll back everything. Given the ridicule speed (=very low) of R-Pi, this can save a lot of time.
Moreover, in Volumio (final release before making the images to be distributed) you can save a snapshot and, if a user has a problem later on, with a button on the GUI you can “roll back to original state”. Not much different from what you wanted to do with SquashFS!!
And btrfs has on-the-fly compression (DO NOT USE DEDUPLICATION, EVER).
btrfs.wiki.kernel.org/index.php/Compression (use LZO, GZIP is too slow for devices like the ones you will be running Volumio on).
I hope I gave you a complete overview.
btrfs (that happens to be in the list of filesystems you can use) solves all the problems and gives you some useful tools that improve Volumio.
I think it’s worth trying it.
I run Windows, OS X, OmniOS (sort of Solaris) so I have no idea how to set btrfs, but it should be easy and there are many guides, it’s one of the next big things on Linux concerning fileystems (but let’s be honest, ZFS still is better, only requires one more kernel module zfsonlinux.org/ ).
I forgot to mention: the SD cards that have wear leveling may requires some seconds after writing to perform the routines. After unmounting the fileystem and before powering off the device, it would be better to place a 5-10 seconds delay, to avoid corruption.
This may explain why on the R-Pi (based on SD cards) some people experience SD card corruption (I know that overclocking the R-Pi causes it too, but maybe it’s not the only cause).
Lag-na, I do really appreciate your suggestions! But you should note also that using “particular” filesystems will have a major dropdown, which is portability accross devices (even squash gives such problems, for devices which cannot have >3.18 kernels…).
What about testing the squash solution and see?
I agree that this is a critical aspect, and I’m really committed to do the best possible.
I apologize, but my plan to deliver in the weekend has dropped… So my next plan is to deliver a Beta image for this weekend… With the update system up and working
I think we can focus on seeing SD Card issues from this one, what do you think?