New file system location!(/bin /sbin /usr/sbin

[jakebpg]

Is there a new image that already takes care of this huge mess?
I've burned one SD card already that can not be read from any device reader at all!
I have a backup of all my important data and another SD card with other important data that I don't want to lose either.

This is a huge mess, why in the world didn't the devs include a script to take care of this huge mess that can and does burn SD cards into an unusable state forever?

Yes I tried using the instructions from the Arch Linux site which is what I resort to to solve problems for alarm and also for my laptop, but that is what burned my SD card to a piece of worthless plastic!

Peppe, is there an image with all of this mess already fixed? I would rather load a new image and reinstall all the software then burn yet another SD into a worthless piece of plastic!!

Please HELP, SOMEONE ANY ONE, FIX THIS MESS CREATED BY THE DEVS THAT WERE TO LAZY TO FIX IT THE RIGHT WAY!

Sorry for shouting but at $40.00 a card it is not cheap in this day to replace these cards much less alone all the data that can potentially be lost in the process!

[pepedog]

I would say it's impossible for a card to be burned out by this.
Yes, there are images past this, here is the latest
http://downloads.raspberrypi.org/images ... 013-06-15/
I have got at least 5 different arm machines past this, only one had a glitch and resorted to unusal methods, someone did similar here
http://archlinuxarm.org/forum/viewtopic ... 713#p32342
The image he had was a lot older, glibc and filesystem had to be done together
The basic thing is if it appears it's all gone wrong, you prefix command with something, and give full paths, like this
/usr/lib/ld-2.17.so /usr/bin/nameofcommand
So if you got to the point of bash upgrade, deleted the 3 directories, and --forced, you can continue
If the ls command begins to work, you are out of trouble and can reboot

No one can write a script because it depends on either how old a rootfs is, or when updates were last done.
We only pickup what arch does, at least that gives us a few days breathing space

[jakebpg]

Well pepe, the SD card does not work in any device I've tried it in. It is not recognized by any OS from windows, mas and Linux and the Linux machines I tried it in are Arch 64 bit, Ubuntu. I've even tried it in a digital camera just to see if it could even see the card of which it did not! Now maybe the card just burned from all the writes but I seriously doubt it since the card is only a year old with the standard arch load.
Now there is one caviot I can actually get to a command prompt but it says something about commands not available or something like that. But the card is useless for any other device since it is not even recognized by the system as being there at all.

Even my Arduino UNO card does not see it as being present. Now maybe if I had another system where I could chroot maybe I could save it but I don't don't so the card is a useless piece of plastic.

[jakebpg]

Oh and thanks for the links, so that I can start anew with a fresh card.

[jakebpg]

Also if you want the card I'll send it to you so that you can verify what I'm saying it true. Just let me know.

[pepedog]

Are you in the uk? Yes, I have had cards burn out but will look
If the card seems useless try this
parted /dev/sdX mklabel msdos
Where X is that card, then run fdisk on it

[jakebpg]

Yes pepe I realize you pick up what arch does and many people have complained about this mess they created. The same thing happen with glibc. That's why I always read the Arch site for fixes when I have a problem with the alarm system since it is mostly the same thing but for the arm architecture.

But there is no reason for a stock system not to be able to run this upgrade without failing and having to physically manipulate the file system to get it to work.

I was a dev for windows for many years and if I had released a mess like this I would have been fired on the spot! I worked for a global corporation where software was auto updated when new releases were ready to be pushed , and critical updates had to work right out of the box so to speak. And yes this is a critical upgrade, I just don't understand how a critical update like this needs so much intervention by the user that in all likelihood will end in disaster.

And yes I also realize that most if not all of these upgrades are done by volunteer devs willing to spend who knows how many hours doing this work but never the less at least make it work with minimum intervention by the user.

Were my updates perfect, no not by a long shot but at least they did not require so much intervention as to render a system unusable requiring tech support to be on site to reload the system that already had all the fixes incorporated into it.

[jakebpg]

Are you in the uk? Yes, I have had cards burn out but will look
If the card seems useless try this
parted /dev/sdX mklabel msdos
Where X is that card, then run fdisk on it

The card is not even recognized by any system. So how can one identify what the system is supposed to address it by?

If I could get any system to see it I wouldn't have a problem but I can not find a single system that sees that card at all.

No I'm in the US.

[sdjf]

I agree it is not so nice that they rolled out the file system change without everything being updated at the same time, but that is not realistic. We know when we run arch that this sort of thing with messed up updates can happen.

But, what kind of SD card is it? If it is Kingston, it likely has a lifetime warrantee and they will replace, I have one I have to send back to them. I am sure it was not Arch that did the card in, but something else.

We are using volatile media that even thought we want to count on it, was not meant for the kind of use that we are giving it. And it is fully possible that the card had bad blocks in the section used for the partition table (my best guess) that when they got written to, totally decimated any device's ability to recognize the card. If a file system gets messed up, we can repair it, but when a card cannot get read, something is more seriously wrong with the hardware. You know that, I am sure.

I am not happy that my backup card somehow got trashed to the point where it cannot get mounted on anything, but am chalking it up to a hardware problem. It could well have been the Pi crashing or writing to the card at the wrong moment due to problems with the power supply in my case, that should not cause a card to die, but I am guessing it can if the writing whacks out at a critical block.

[surfatwork]

I agree that the filesystem update could have been done smoother, but with all due respect, Arch is not the best linux distro for someone who is not comfortable with linux and the commandline. The instructions on the arch website are fairly clear and the forums have loads of help too. There is also a specific thread related to this upgrade.
If you are dependent on pre-built images to run your system, then you should probably not be running Arch.

[sdjf]

Almost all of us running Arch on the Pi are dependent on pre-built images and have not rolled our own.

There is a giant difference between comfort with command line Linux and willingness to learn about same, and being dependent on pre-built systems. Issue is in part one of semantics.