Raspbian ready for prime time?

[cliffskoog]

I've been using Rasbian as well as Raspbmc for a couple months now, and I find it increasingly frustrating that the system is so vulnerable to unclean shutdowns. Because of system freezes and unresponsive input devices, unclean shutdowns seem unavoidable, and the consequence is almost always a kernel panic on rebooting. I'm a seasoned Linux user, and one of the hallmarks of a decent Linux distribution is that shutdowns are recovered. Why can't Raspbian conform to these norms? Backing everything up every day is impractical, and I'm getting fed up with reinstalling everything often.

I strongly believe that the developers should prioritise addressing a robust approach to recovering from unclean shutdowns.

[kbailey]

Since I started with RBP a week ago, I have not seen any unclean shutdowns except when I yanked a power wire. Based on experience, I am compelled to say this is no longer an issue- but the lack of sound is a serious limitation. The opsys needs to be rock solid stable and present all the normal expected services, including playing music.

Also, for pi to make pi, we need to be able to make SD cards for a pi with a pi. Alas, there is but 1 SD slot. Can we find a standard USB to SD adapter so we can plug in and use it to format and load SD cards? When the opsys is solid and pi can bake a pi, we are ready to knock on the world's door.

Until then, pi is not ready to become the world's internet Model T- but it is VERY close to it. Just a bit more, just a bit longer, then there will be an explosion.

[OtherCrashOverride]

I find it increasingly frustrating that the system is so vulnerable to unclean shutdowns

In the 3 months I've had a Pi, i have not experienced any SD card corruption despite pulling the plug on many occasions. The issue you are having may be attributed to over clocking or SD card quality rather than Raspian.

we need to be able to make SD cards for a pi with a pi

The is no *technical* limitation that I am aware of preventing this from happening. He is how this problem was solved in the 80's to duplicate floppy disks: 1) Insert media and boot OS into system RAM. 2) Launch the media copying program 3) Program loads a portion of the medium into free system memory and prompts to swap media. 4) Portion in system RAM is written to destination media and the user is prompted again to swap media. 5) Process repeats until the entire media is duplicated.

There is lots of room to improve upon this process 30+ years later. What seems to be missing is what the Raspberry Pi foundation is directly addressing: The lack of people with the necessary skills to address lower level issues (hint: HTML5 is not going to help on this one).

[ghans]

Can't BerryBoot already do that ?

ghans

[OtherCrashOverride]

Everything required to boot the Pi, allow the SD to be swapped, connect to the internet and write an image as its downloaded to a blank SD is present/available for Raspian. There is just no icon to click on the desktop to do it.

[OtherCrashOverride]

There is just no icon to click on the desktop to do it

Before someone files a bug report requesting the missing icon be added. I should clarify that is an idiom that means "you just have to posses the required skills to accomplish the task."

[Muzer]

I have noticed the distro isn't particularly complete in some regards.

One small example - the eject program is missing from the distribution (the Debian package is called eject). The lack of this means that when unmounting a USB stick from the default file manager, it gives an error message that eject wasn't found.

[Cloudcentric]

It was designed as a tool for learning programming, anything else is a bonus.

So yes the Raspberry Pi and Raspbian "wheezy" is nearly ready for the purpose it was designed for, only USB & Sound need to perfected.

[paul42]

I find the occasional need to reflash the SD card due to corruption to be a minimal problem considering the advantage of being able to quickly change between different releases by just swopping the card.

I make copy images often & document them in a database as i go so i know exactly what i have changed. It's just great to be able so easily to go back a step or two if something doesn't work out.

By the way it's well worth putting header pins on the pcb for the reset option. I have a small reset switch wired to mine. So far if i have had a freeze due to the usb issue i have recovered with no corruption using the reset switch.

[Montekuri]

Also, for pi to make pi, we need to be able to make SD cards for a pi with a pi. Alas, there is but 1 SD slot. Can we find a standard USB to SD adapter so we can plug in and use it to format and load SD cards? When the opsys is solid and pi can bake a pi, we are ready to knock on the world's door.

I think any SD card reader can be used for this purpose.
I use this kind of adapter:
http://www.amazon.com/Memory-Reader-256 ... d+card+usb

[rpdom]

I have noticed the distro isn't particularly complete in some regards.

One small example - the eject program is missing from the distribution (the Debian package is called eject). The lack of this means that when unmounting a USB stick from the default file manager, it gives an error message that eject wasn't found.

To be fair, the default minimum Debian install doesn't contain the eject program either. It is missing from some of my Debian PCs.

However unmount should not (IMO) rely on eject, as it is possible you may want to, for example, unmount /dev/sda1, then mount /dev/sda2, which wouldn't work if the device had gone offline due to an eject /dev/sda.

[Muzer]

However unmount should not (IMO) rely on eject, as it is possible you may want to, for example, unmount /dev/sda1, then mount /dev/sda2, which wouldn't work if the device had gone offline due to an eject /dev/sda.

Completely agreed there. I think PCmanFS should do something else. But as it is, an error message is hardly user-friendly

[sej7278]

from what i've heard the sdcard corruption is of the /boot partition which is fat16, not of the rest of the filesystem which uses ext4 (ext3?) which has journalling and can fix itself upon reboot.

so don't blame debian (or riscos or *bsd....) blame broadcom or whomever insisted on making /boot require fat16, or blame microsoft for making such a naff filesystem.