0

I was using my Raspberry Pi W for a while, exclusively over SSH. Everything went fine on the stock Raspbian distro. At some point I made a cronjob for a script that upgrades the system automatically once a day.

At some point my Raspberry Pi refused to boot at all, not even the LED was blinking. I changed the charging device and tried other things, but always the same result. At some point my friend put his readily configured and working Raspbian into my device and it immediately worked. So I figured the update script broke the system.

After a lot of waiting, I finally managed to get a card reader. Sadly the SD card is not mountable on my debian-based distribution for desktop use. I was looking for the SD card and assumed it didn't show up, until I realized that the /dev/sdf with only ~250 MB space showing up in gParted was the "actual" SD card that I couldn't mount. The program says, that the space is RAW and has only the above size. Which is not true.

After research I found out, that it might be a reserved protection part of the SD card. The biggest problem with all the "solutions" I found out there is, that it requires me to flash the SD card completely to make it usable this way again. But I spent a lot of time configuring the Raspbian to my liking, for example compiling some programs already took like half a day each.

Since it is obvious that the Raspi won't boot because of faulty updates, I think it is entirely unnecessary to make this radical step of just deleting all the work that went into it. All the information is in the same place, as to assume usually, but somehow I can't access it. Which is unreasonable.

How can I access the whole SD card properly, as expected, so I can chroot into the system and remotely update the Raspbian installation?

0

The program says, that the space is RAW and has only the above size. Which is not true.

The MBR is corrupted. This may or may not mean significant parts of the rest of the card are also trashed. You need to recreate the MBR as it was; fdisk is a decent tool for this.

All the information is in the same place, as to assume usually, but somehow I can't access it.

Exactly. You will need to find out what the original partition boundaries were (i.e., where "the same place" is). These seem to change slightly over time with Raspbian images, so if the card was created a while back and you do not have the original image it was created from, you may be out of luck. If you do have the image, you can get the boundaries like this:

> fdisk -l 2017-03-02-raspbian-jessie-lite.img 
Disk 2017-03-02-raspbian-jessie-lite.img: 1.3 GiB, 1393557504 bytes, 2721792 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xb2455b06

Device                               Boot  Start     End Sectors  Size Id Type
2017-03-02-raspbian-jessie-lite.img1        8192  137215  129024   63M  c W95 FAT32 (LBA)
2017-03-02-raspbian-jessie-lite.img2      137216 2721791 2584576  1.2G 83 Linux

The numbers that are important here are Start and End. These are (hopefully obviously) related to Size. This is from the 2017-03-02 jessie lite image, and the hurdle for you is determining the size of the first parition. The starting block (8192) is always the same, but looking back at a jessie image from Jan/2015, the first partition size is 56M, and in the March/2016 jessie lite, it is 60M.

So, most likely it is one of those. You can use, e.g., 60M as the size when creating a partition.

(Re)creating a partition table won't do anything to any of the data on the disk. The purpose of the table is to indicate where partitions are located. If the table is wrecked, those can't be found, but unless the card is corrupted significantly beyond the partition table, they are still there. So, if you create a partition table that matches where they are, you will be able to access them.

Do that with fdisk or gparted, just make sure if you use the latter that's all it is doing (do NOT format the partitions).

Presumably you expanded the root filesystem, so when you set the size for the second partition, use the end sector (which will be the default). Beware when entering the starting sector that fdisk may offer you something less than 8192, i.e., somewhere before the first partition. Don't go for that.

After you're done, you can test by mounting each one manually. If you get something to the effect "wrong fs type or bad starting block", then either the size is wrong (start over, try again) or else too much of the card is corrupted :(

If they mount, unmount them and run fsck to fix any corruption problems internal to the filesystem. If this becomes very long winded, there is a chance the filesystem is essentially wrecked anyway.

Since it is obvious that the Raspi won't boot because of faulty updates

That is not obvious at all. In fact, I'd say this definitely is not the cause. It is coincidental. By analogy, "I wore my hat and went for a walk. It rained. Since it is obvious it rained because I wore my hat..." -> Nope, that is not why it rained.

I spent a lot of time configuring the Raspbian to my liking [...] it is entirely unnecessary to make this radical step of just deleting all the work that went into it

This is why if you have something you like that took you a long time stored on digital media of any sort (spinning disk, SD card, a cloud somethere...) you should keep it backed up.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.