Raspberry Pi Stack Exchange is a question and answer site for users and developers of hardware and software for Raspberry Pi. It only takes a minute to sign up.
Sign up to join this community
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.
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).
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.
using a working Linux machine, plug the micro sd to a USB port
sudo umount /dev/sdb2 (number may be other)
sudo e2fsck -y -f /dev/sdb2
Good luck!
/dev/sdb2 to work on, which is unlikely given the error message.
Jun 15, 2020 at 9:13
Using Win32 Disk Imager, read your SD card and save the image into a file. Then write the image to another SD card and try it.
