New Pi

If it's on the network though and you generate & exchange ssh keys, it's as simple as "ssh raspberrypi sudo halt" from another computer.

I agree it will probably be fine most of the time. Note that there may still be filesystem errors but they would be recoverable, helped by ext4 journaling.

How about the "sync" command? I've used it but I can't promise I wasn't just lucky.

Mel

Somebody's got to sit down and write some new commands :)

What I do is put the SD chip in a reader, mount it on my desktop system, and do whatever I need. dd, edit files, anything.

Mel.

====snip====

He obviously meant "rinse". Although the C and S keys aren't _too_ far apart, I'm not entirely convinced that was a 'typo'. :-)

In this case, create a duplicate on a spare card using dd or equivilent utility.

Alternatively, if you have a spare PC, create a 'disk image' backup file you can use to restore the card from.

Not being in possession of a RPi, I don't know whether dd can be run on the RPi itself for _this_ job, so you might be dependent on a 'spare PC' in either case.

No doubt there are plenty of RPi enthusiasts in this NG only too willing to put me straight on this point of doubt. :-)

--
Regards, J B Good

Not if the SD card has been scrambled due to power being removed in the middle of remapping blocks for wear levelling. I've seen cases where most of the data seems to still be on the card, but its all in the wrong place, making any journalling or recovery tools useless.

---druck

I have two strategies:

- immediate backup: my house server contains a CVS file repository which is accessible from my RPi. Any file I consider valuable (source code, hand modified config files, shell scripts, etc. are committed to CVS once they are in a satisfactory state, so this has the effect of backing up changes to the CVS repository.

- weekly backup: I run rsync on the RPi. This copies changed and new files on the SD card to the backup copy and removes deleted files from the backup copy. The backup copy is on a removable USB hard drive attached to the house server. I have two of these drives and write to them in rotation. They live in a small fire safe.

Parenthetically, all my machines, including the house server are backed up as part of the weekly backup run, which is close to optimally fast because rsync does the minimum amount of work needed to make the copy identical to the original. The backups are done immediately before I run software updates on all the backed-up machines.

Of course there are other approaches: another would be to have an SD card reader and two additional SD cards for backups and regularly (weekly?) use the dd utility to copy your RPi's main card to the older of your backup cards. This is simple, cheap and easily automated by writing a shell script, but is probably slower than using rsync. Or, you could use rsnaphot, which should be about as fast as rsync and maintains a set of 'n' versions of each backup copy - useful if you think you may need access to older versions of anything not held in a version control system like CVS.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |

Brain subverted by the infamous Rincewind.

It can (Raspbian is quite capable), and I've done exactly that on my RPi when I transferred my RPi file system from a 4GB card to an 8GB one.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |

There's a hardware/software package, The Pi Supply Switch from http://

that does more or less the opposite. You plug it into the 5v supply line and it allows push button to shutdown and power off the Pi and to power on and reboot as usual.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |

sudo halt seems to work OK. Plenty of text tells what is happening, then it shuts down. I am running debian

Malcolm

--
T M Smith 
Using an Iyonix and RISC OS 5.20 in the North Riding of Yorkshire

Rather than "shutdown -h now" or "shutdown -r now" its easier to use the 'halt' and 'reboot' commands.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |

Thanks Dave, I certainly need to look into this aspect. I have overcome my previous misfortune by purchasing a Noobs sd card.

On w7 the new card and the one I have just formatted and copied the noobs download onto look identical but my copy will not load?

Malcolm

--
T M Smith 
Using an Iyonix and RISC OS 5.20 in the North Riding of Yorkshire

Sync, or fsync(), will guarantee that everything you want to secure on disk will be flushed to disk from in-memory buffers at that point in time but it can't guarantee that some other process hasn't started writing to disk when you pull the plug. Try running 'top' some time if you want to see just how many user and system processes are running at all times in a Linux system.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |

If block 0 is an MBR block, Windows will act like the first partition is the raw device, so copying an image that includes a *real* block 0 won't produce the desired result.

You need a copy utility that ignores any existing MBR and partition table.

--
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon

NOOBS isn't an image, so all you need to do is format the SD card using the recommended SD Card Association formatter, eject the card, then put it back in again so the partition table gets read properly, then unzip the entire contents of the NOOBS download into the \ directory of the card. This should create several files and a few "folders".

If the card still doesn't boot it is worth checking the contacts on the Raspi's card slot. Maybe squeeze the card against the board with finger and thumb on top and bottom of board to see if that helps. It's a common problem. Also inspect card and slot very carefully for any sign of damage, cracks or bending.

It should not be that bad, the filesystem used in most Linux distributions use journalling, and when the system crashes it should not be in a completely corrupted state. (the journalling is only for filesystem metadata, not for user data, so it may be that a file that was being written at that time contains some garbage at the end or is missing some data, but it should not destroy the entire filesystem structure and become completely unbootable because of that in most cases)

What I have seen go wrong with raspbmc was that the FAT bootpartition was mounted with the sync option, in an attempt to make it more robust. But this has the opposite effect: it means that every write to the disk is immediately flushed, including the word-by-word updates to the FAT that are done when a file is written sequentially. So for every sector written to the file, a write is done to two FAT sectors as well, reducing the write speed and increasing the number of writes to the same sector. Not good for the flash, and because of all kinds of timeouts it resulted in a corrupt FAT bootpartition when there was a kernel update. Of course, then the Pi is no longer bootable.

But this mistake has been fixed months ago, the partition is now mounted without the sync option, the update goes quickly and cleanly again. You still need to patiently wait during the update, even when progress bars halt or are displayed as garbage, or else you will still corrupt it. But that is because critical files are being rewritten and the system will not boot when they are in half-written state.

In my experience with Linux, although it is always better to shutdown cleanly, it will seldomly become unbootable when the system suddenly loses power or crashes while in normal operation.

But that all assumes its a simple storage system like a hard disc where once data has been written, it stays put. So the worse that can happen is a partial write and the journal information will indicate what the last consistent state was to recover to.

With all but the simplest flash storage performing wear levelling, there is an extra level of mapping between the storage the journalled filing system things there is, and the actual flash memory blocks. If the flash controller is changing this mapping when the power goes, the data will still be there, but in a completely scrambled order that journalling can't recover from.

---druck

However some (most/all) disks were found to be lying when the OS performed the fsync() and asked the drive for write conformation and still had data in their on-board RAM cache un-written to disk. This was driven by marketing to make it look like they were running faster than they really were. Not sure if this applies to SD cards though, but given the relatively slower speed of writing, it would not surprise me.

Have a read through:

Gordon

I've no idea what you mean by a "normal *nix system", but

sudo halt

(or just halt if root)

is SAFE on all systems I've used for many years. It's true that it used to simply halt the system, but that was a long time ago. (Decades) All recent Solaris and SunOS before it, OpenBSD, FreeBSD, NetBSD and all Linux systems will correctly sync the disks and halt.

Most systems do have flags to the halt command to not do the sync, but doing the sync is the default.

So

sudo halt

(or reboot)

and forget all that shutdown -h now nonsense - it's not as it you've got a multi-user machine these days and you have to warn people of the impending doom...

If you were really old you'd be typing sync three times, anyway... ;-)

The bad thing about using halt (or reboot) is that it doesn't give daemons a chance to shut down nicely - it just kills them stone dead. (Which is different from flushing the data to the disks) So if you had a controller than needed to know the system was shutting down down so it could make sure the control rods were in the pile to stop a nuclear meltdown[1], then it would get a signal and have a short grace period to tidy up before finally being killed.

Another example might be a database handler - as well as the kernel making sure data in-memory is on-disk (which it does!) an application like a database might want to finish a transaction and make sure it's in-memory data was on disk, or at least handed to the OS to make sure it ends up on disk.

But with most little Pi desktops, it's really not that important.

Gordon

[1] hopefully not a real example, but you get the drift...

If you Install the "acpi" you can use the keyboard's "power" button to initiate a shutdown, so make a one button keyboard:

--
umop apisdn