Fast start and safe switch off

Sounds like you need to set up a read-only file system (if nothing is written it can't corrupt the FS). I know this is possible with Linux generally - hence USB live distros, but have never seen the process described clearly enough for me to set it up myself :(

It is easy enough to mount the root fs readonly, just add the ro option in /etc/fstab. However, that could make many of the programs that are started by default fail. It depends on the use of "init" or "systemd" by the OS, the latter sometimes is used and it has a couple of ramdisks for directories that for sure need to be written.

Of course, it would always be advisable to not start any of the services that the particular application does not need. That makes it start faster as well.

James, for what it's worth, I've pulled the power on RPi cards on many occasions, and not seen a problem.

How fast do you need it to boot?

Unfortunately that's not reassuring enough because it doesn't guarantee/explain lack of corruption but thanks for pointing it out.

I am thinking of using the Pi to replace a CD player in a public broadcast system (but holding more tracks than would fit on a CD). There's no set boot speed but users are accustomed to their existing equipment starting immediately so it would be best if the Pi starts quickly.

I suppose the users could kill the power accidentally or otherwise and switch back on then quickly need to play a certain sound file though that is unlikely. Reliability is by far the more important requirement. It would not be good if the machine were to fail at times or simply to break.

James

RISC OS will start up on a pi in around 15 seconds, and it doesn't write to the file system thereafter. (There's no swap file for example). You can even remove the SD card. It's dead easy to include an automatically started application.

The question then is whether there is an application available to do what you need.

one way is to have two partitions data and scratch, mout data readonly when you boot and then reformat scratch and use it with unionfs (or equivalent) to fake a read-write filesystem.

using a ramdisk with raspberry pi is likely to be problematic as there's not much ram (more ram than my first linux system had disk, but not much by today's standards)

You can boot a Pi into a single non-GUI application in about 5-6 seconds. The kernel boots in about 2-3 seconds, the next second or 2 will depend on how much userland you let it run - ie. to initialise the keyboard, USB, etc.

However at that point, there is no networking, and the filesystem is mounted read-only. This may be enough for your canned application though.

Wouldn't you just be better off buying a stand-alone CD player with built-in speakers?

Gordon

Well, there's !RiscDJ which does exactly what you want.

AIU it's still beta ATM but might be woth investigating. There's a thread on

Patric

Maybe you need to study how those ramdisks (tmpfs) work in Linux...

Also I do not recommend it to store all your data. It is just for storing those directories that you need to have writable but do not take much space, like /var/run or /var/lock.

All this is of course about Linux. As others already wrote, you can use another OS. Maybe you do not need much of an OS at all.

Tiny Core Linux usually runs entirely in RAM with no writable persistent storage, and I'm told it has a Raspberry Pi port. It also boots pretty quickly as a result of its small size. There are several tools to help remaster it. On x86, it's not difficult to remaster it manually, but the Raspberry Pi boot sequence might make that a little more difficult.

HTH

That looks promising. The Tiny Core web site seems to hide the non-mainstream downloads but if anyone else is looking for them they can currently be found via

James

...

Do you mean it writes nothing to the file system? Doesn't it even write a log file or similar? (In itself that wouldn't be a problem. I am only concerned about writes potentially stopping the system working, for example, filling the file system or corrupting files or free-space lists if the Pi gets switched off when a write is part-way through.)

They may change over time but initial requirements are *very* simple. In terms of user interaction they could be summarised as

1. User enters a track index number
2. Program displays info about the track
3. When ready the user clicks Play

More of issue is recognising and playing the file format which is likely to be mp3 but I see other programs on RiscOs play mp3s so it must be possible.

BTW, since reading your suggestion I have been looking at what is required to program RiscOs. If it helps someone else I found

One term puzzled me. I was looking for a text entry widget. Apparently RiscOs allows text entry into elements of other types (which is probably a better idea).

James

A full-screen TUI (i.e. non-GUI) would be fine.

Yes, it would be enough but how do you get the file system to stay mounted read only. I presume you are talking about Linux and AIUI Linux writes all kinds of stuff to the file system on boot.

No, the app is to choose one of far more tracks than can fit on a CD so I was thinking to store them read only on the SD card. Even if there were to be a later requirement to allow users to load and play other tracks they could provide them on USB flash memory. So I think the SD card could remain completely unchanged.

James

W dniu ?roda, 23 pa?dziernika 2013 09:40:22 UTC+2 u?ytkownik James Harris napisa?:

it

ite

ch

as

For such simple applications I usually use Buildroot generated Linux distri bution, which works in initramfs. After boot the SD card is mounted in read

-only mode. Startup time for such system should be ca 30 seconds, and it can be switche d off without risc of corruption.

As I wrote before, it is possible to put the things that you absolutely need to be writable in a ramdisk/tmpfs in Linux. This is nothing new. Dedicated devices often run Linux these days, and there has been a long time when NAND flash was not cost effective and the entire root fs was only changeable as a whole (i.e. "flash new firmware") and all writable data was in a ramdisk and maybe some EEPROM. In this case /var is usually on a tmpfs and is loaded from e.g. a tar file at boot, and there are many symlinks from files in /etc that point to locations in /var e.g. under /var/etc. E.g. my old Dreambox always worked that way. The newer box I have now uses NAND flash and just modifies data wherever it likes.

It still puzzles me if you are not trying to re-invent the iPod or one of its many clones and parallel developments...

It's read-only at that point - unless you do something to make it read/write it will stay read-only.

What I was doing was booting my BASIC interpreter - which is a stand-alone program that does its own graphics, but any text-based program would also run.

I did it by hacking into one of the early /etc/init.d/ scripts - keyboard-setup (I think - it was some time back).

I could load & run programs, but not save anything - there was no system log running, nothing at all.

As long as your application didn't need to write files, you should be OK.

Gordon

or just an SD card with the "lock" slider in the correct position.

gregor

Which is ignored on the Pi and many SD card readers.

Dom.

Are you saying the lock slider on an SD card works on the honor system, is at the mercy of host software, and is not enforced by hardware/firmware on the card?