0

Hi I have 6 Raspberry Pis and none of them have encountered this error when using this EXACT setup. I boot up. Get a bunch of messages telling me that my CPU swapper is not tainted (not official drivers) and stops the CPUs and gives the following error:

Kernel panic - not syncing: VFS: unable to mount root fs on unknow-block(179,2)

Can somebody help? I have no data on this card but would rather not reflash.

1

unable to mount root fs on unknown-block(179,2)

This is a very straightforward message, except that it is couched in terms of the kernel's major/minor device numbers; if you search down that list for "179 block" you'll find it refers to "MMC block devices", and the minor number (2) to a partition, counting from 1, 0 being the (1st) card itself (you can see these with ls -l /dev if you are curious, but it is not very exciting).

Anyway, point being, if the second partition on the SD card is "unknown" this means the kernel did not find such a partition on the card. In an Rpi context this is usually because the card has been corrupted. It can also be (if you are using a customised kernel) because it lacks the appropriate drivers to access the partition (eg., the ext4 fs driver).

In the first case (corruption), fixing this can be done by re-writing the partition table to what it was. Since you have other pis running the same setup, this should not be hard; it is also easy enough if you have the original image the card was cut from. You want to run fdisk -l on the other card/image to get the layout, then use fdisk to make the corrupted card look the same. If this is a new process for you you can use trial and error before you write the table, although you can't really do any harm at this point as you are only writing stuff to the MBR, which is the first 1/2 KiB on the card and does not overlap any of the data partitions.

If the table viewed with fdisk is already correct, or after correcting it using fsck on the partition fails to find a filesystem, your only chances are with some more serious forensics which have no guarantee of success and are not worthwhile if you have your stuff backed up.

Hopefully fsck works, or at least runs. This doesn't guarantee the fs will be 100% ok, but you should at least be able to access it and boot the Pi (have a look in /lost+found afterward, it should be empty -- if not you lost some stuff and these are the bits and pieces found by fsck).

Unfortunately...

Your chances aren't good. If the partition table/MBR was screwed up, that is, again, only a 512 byte block, and it stands to reason that a lot of other corruption could also have occurred.

If the partition table is still OK, that means the fs on the partition is unrecognizable as such, and has to be reformatted.

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.