When booting, the sequence stops at the following:

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

What can I do to get my Raspberry Pi 2 to boot again using the existing Raspbian installation, as it contains many files and configurations that would be too painful to recreate?

NOTE: This, this and this are related but are different.

  • in my case the problem was caused by /boot/cmdline.txt missing 'rootwait'. Which caused no problem on RPi 3B but RPi zero gave this error. Commented Oct 12, 2022 at 11:54
  • Did you check the physical lock switch of the SD card? Commented Dec 8, 2022 at 8:25

7 Answers 7


Please note there is a clear distinction between errors, based on the numbers at the end and I won't go into much details as they can be easily discovered online if required. These fixes assume that you have all the needed connections working (power, SD card, HDMI, wired keyboard, mouse) and are using Raspbian along with NOOBS.

The details for error ending with 2 is at the end of the answer. If your error message ends with 6, like this:

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

you will need to do a filesystem check & repair:

  1. Start the Raspberry holding the Shift key.
  2. Once NOOBS loads, press Alt-F2 to access the recovery command line.
  3. Login with username root and password raspberry.
  4. Type fsck.ext4 -y /dev/mmcblk0p6. This will scan and attempt to repair the corrupted file system (replace ext4 with your partition type if needed). Note that the auto mode of fsck (i.e. only typing fsck instead of fsck.ext4) is not supported.
  5. Type shutdown -h now to shutdown the Raspberry cleanly.
  6. Unplug the power cable and plug it back in. The Raspberry should now start fine.

If your error message ends with 2, like this:

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

it is likely that the problem is caused by an update bug. The fix involves switching that 2 into a 6:

  1. Start the Raspberry holding the Shift key.
  2. Click the Edit config (e) button or press e.
  3. Click the cmdline.txt tab or press the right arrow on the keyboard.
  4. Replace:




  1. Click OK and then press escape on the keyboard to proceed with the boot sequence.

Your Pi should now boot fine. If the same error shows but with 6 proceed with the above steps.

In some cases, the Pi might ignore the change made in the NOOBS GUI and you would still see the exact same error, with 2 at the end when booting. In this case, tktbjp's answer might help:

Actually it is simple to use the recovery mode. I entered recovery mode and pressed alt-F2 to loging as root. Changing cmdline.txt from the GUI does not work.

After logging in as root with password raspberry, check if there is any /boot directory. Most probably it will not be present. If not then create it using mkdir /boot Then use vi editor to create cmdline.txt.

#cd /boot

#vi cmdline.txt

in vi editor change the root to mmcblk0p6. My cmdline.txt contents looks like dwc_otg.lpm_enable=0 console=ttyAM0,115200 console=tty1 root=/dev/mmcblk0p6 rootfstype=ext4 elevator=deadline rootwait

save the file. then it is important to do sync.


Then boot the board. Cross check using GUI if cmdline is really changed. My PI B+ is working now

  • 1
    instead of pressing 'y' or Enter manually, you could use '-y' option of fsck... Commented Mar 11, 2016 at 8:56
  • 1
    Great advice, thanks for the help. How ever, for me it didn't work with sudo command. System couldn't find it. But it was just fine without it! Commented Nov 4, 2016 at 18:54
  • 3
    Start raspberry by holding shift key? I assume you mean a physical keyboard, because a wireless keyboard won't work like this at boot Commented Dec 1, 2016 at 1:15
  • 2
    I have the (179,2) version of this message when starting a new Raspberry Pi Zero with Rasbian (Jesse). However, I tried pressing Shift on the keyboard but it doesn't make a difference. It doesn't enter a 'safe mode'. I'm not using the Noobs installation, just Rasbian boot files on an 8GB SD (which I tried reformatting).
    – Bill
    Commented Jan 9, 2017 at 2:25
  • 3
    Inside my cmdline.txt I found following: dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=ac0d3335-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
    – Micha93
    Commented Feb 2, 2021 at 9:25

To deal with the core of the problem (not a workaround), if you can't boot (or you have no "NOOBS"), you need to:

  • remove the SD card from your Pi and put it in a card reader in your linux computer.
  • if automatically mounted, umount both partitions. Check the correct device name with fdisk -l and mount -l. In my example, it is mounted as /dev/sdb1 and /dev/sdb2. So, to unmount, use umount /dev/sdb1 and umount /dev/sdb2. (BE CAREFULL TO CHECK YOUR PARTITION NUMBER. "2" here is just MY example).
  • Now you are ready to proceed the check-up with corrections.
    • With fdisk -l identify the DOS partition and check/fix it with fsck.fat -y /dev/sdb1 (Check your correct number)
    • Also, fdisk -l shows you the ext4 partition number. Fix it with fsck.ext4 -y /dev/sdb2 (Check your correct number)
  • If it automount again, umount both again. If not, you are ready to remove from your computer to your Raspberry Pi and turn it on.

If it is just a "block" issue, it will probably be up and running. If the Kernel Panic continue, check if the error message has changed to something else. In this case, you should look again for other answers, or maybe consider re-writing your SD Card from scratch.

  • fsck.fat: command not found
    – leonheess
    Commented Dec 25, 2021 at 20:16
  • That is a first. What appears to you if you type fsck and double <tab>?
    – DrBeco
    Commented Dec 27, 2021 at 4:40
  • Thanks, this worked for me. My Partitions where called /dev/mmcblk0p1 and /dev/mmcblk0p2. The second one (ext4) was not mounted in my case, probably because it was corrupted. fsck seemed to fix it! Commented Jan 7, 2022 at 11:24

I had the same problem but with unknown-block(179.7) and the first solution worked fine, just replacing this:

sudo fsck.ext4 -y /dev/mmcblk0p6

with this:

sudo fsck.ext4 -y /dev/mmcblk0p7

I'm not an expert but hope this could help others.

  • 3
    Is fsck.ext4 command available on Mac? Commented Dec 1, 2016 at 1:20
  • 1
    No, unfortunately it's not. Commented Jun 19, 2019 at 19:17

I ended up with this error after trying to install Raspbian (Lite) on an SD card that was too small. Of course, if I'd actually looked at the output from the dd process, I'd have seen that before blindly putting the card into my Pi:

$ dd bs=1m if=Downloads/2016-05-27-raspbian-jessie-lite.img of=/dev/rdisk3
dd: /dev/rdisk3: short write on character device
dd: /dev/rdisk3: Input/output error
969+0 records in
968+1 records out
1015808000 bytes transferred in 45.492548 secs (22329108 bytes/sec)

I ended up installing Minibian.


Got this error ending in 2 when duplicating a known good card. Basically what I did was copying the bytes from the original card to a fresh/new SD card with dd. I didn't expect any errors from this simple process, so imagine my surprise when I was confronted with this message:

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

After searching it turned out that the fresh SD card was slightly smaller than the original.

Because of this, mounting the root partition failed. And that in turn led to the infamous kernel panic message. I guess the kernel tried to reach blocks past the end of the SD card, or found that the partition (being the last in order) doesn't completely fit on the SD card.

Since I really wanted to keep my files and settings, I shrank the root file system. This involves running resize2fs first, then fdisk to adjust the partition. Be aware that one tool reports the size in 4k blocks, the other works with 512 byte sector start/stop offsets. It's really easy to mess up. So keep backups of known good images.

It's probably best to do this on another PC or laptop with card reader. Not on the raspberry itself.

It goes without saying that you should have enough space in the filesystem to be actually able to shrink it...


In my case I due to clone sd in another sd because the original was corrupted it that sector.

To clone in Windows you can use this tool: Win32 Disk Imager.

To shrink the sd image, if the new sd is smaller then original, you can use this script in a linux vm where you have shared the sd image: PiShrink.

Finally, if you want see the entire procedure in this video.


I had the same problem and the solution was to remove the physical lock of the SD card. Somehow, I was able to modify the content of the SD card on my Linux desktop environment, but the target board wasn't able to mount it properly. Then I realized that the physical lock was active on the SD card. Silly me :)

  • Are you saying your Linux box ignored the physical lock?
    – Chenmunka
    Commented Dec 8, 2022 at 16:36
  • @Chenmunka Yep. I'm using an Ubuntu 20.04 machine. When I plug in the SD card and try to modify its content, it doesn't give me any warning. I tested it on several different Ubuntu 20.04 machines. Commented Dec 9, 2022 at 11:52

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