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.
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
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.