1

Alright, long story short, I've been running a copy of Raspbian Lite for a while on a RPi 4, off a MicroSD card. I'm using it along with a couple of USB3 drives as a makeshift NAS, where I store my media for my Plex Media Server. It's been running really well for a while, until today.

This evening, I realized it won't boot anymore, and the message I was getting was the ol' "Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,2)". I've looked it up, been trying to find a way to fix it, but no luck so far. The last thing I've tried is from this thread: Kernel panic-not syncing: VFS: unable to mount root fs on unknown- block(179,6) running Raspbian on top of NOOBS

But I keep bumping into write-protect issues.

I'm not sure at this point if it's fixable, and being the dumb noob I am, I did not have a backup of my SD card...

One thing I picked up on during my research is the ability to boot the RPi from a USB drive. I had an old 120GB SSD collecting dust somewhere, with an enclosure, which should be a lot more stable than a MicroSD card. Using another guide and a fresh install from a different MicroSD than my bad one, I installed Raspbian Lite on the USB SSD, and now it's booting perfectly from it.

With that in mind, I'm now a lot less interested in fixing the old SD card back into functioning if this setup is viable.

Where I'm stuck is: is there way to copy my entire setup, users, programs, mounts, etc... from my "bad" MicroSD, onto my new fresh install on my SSD, effectively making it effectively an exact clone of my old setup, avoiding me from having to set up everything all over again?

I see a lot of guides on how to clone an existing, correctly running install onto a different card or USB drive, but I can't seem to find a guide on how to clone one's setup from a bad, but mountable, readable SD card... I've confirmed that I'm able to mount both partitions in read-only mode, so I have access to all the data.

I have backed up both partitions to separate directories on my SSD install using rsync.

I'm assuming it wouldn't easily be done by just copying all the data onto the corresponding directories on my new install, but hey... wouldn't be nice if it was that easy...

Any thoughts? Thanks in advance

Improve this question
3
  • Boot some other SDcard. Stick your broken card in a USB reader and run sudo umount /dev/sda1; sudo umount /dev/sda2 ignore any errors. Then run sudo fsck -f -y /dev/sda1;sudo fsck -f -y /dev/sda2. Power off, swap back to the original SDCard and keep calm and carry on.
    – Dougie
    Commented Jan 16, 2021 at 13:13
  • I'd tried that, but it's complaining about the partition being read-only. I can see that my boot partition might have issues: 0X41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt, but it can't run in update mode
    – ardendolas
    Commented Jan 16, 2021 at 17:05
  • Time to toss that SDCard in the bin and start with a factory fresh one.
    – Dougie
    Commented Jan 17, 2021 at 0:37

2 Answers 2

Reset to default
0

Do not attempt to apply ANYTHING in that link, which is a different error.

What the message means is partition 2 (of whatever drive contains the root file system) is CORRUPT, or missing.

What you are suggestion may be possible to a sufficiently skilled user, but most wouldn't even attempt this with a faulty OS and creating a bootable SSD is not entirely straightforward.

If you want to attempt recovery you can mount the SD on a linux computer attempt to repair, but this is often not successful and risks further data loss.

Your best bet is to save your data (which you have done) perform a fresh installation on a new SD Card and restore what user data you can recover AND next time make a backup.

I would mount the old SD Card on the new OS (see below script) and use rsync to copy what I could. NOTE this needs to be a selective copy to avoid overwriting the new OS.

#!/bin/bash
BOOT_MOUNT='/mnt/SDA1'
ROOT_MOUNT='/mnt/SDA2'

# Check/create Mount Points
if [ ! -e $BOOT_MOUNT ]; then
    mkdir $BOOT_MOUNT
fi
if [ ! -e $ROOT_MOUNT ]; then
    mkdir $ROOT_MOUNT
fi
    echo "mounts " $BOOT_MOUNT  $ROOT_MOUNT
if [ -e /dev/sda ]; then
    SD1='/dev/sda1'
    SD2='/dev/sda2'
else
    SD1='/dev/sdb1'
    SD2='/dev/sdb2'
fi
echo $SD
# Mount Partitions
if ! $(mountpoint -q $BOOT_MOUNT); then
    mount $SD1 $BOOT_MOUNT  # mount partition containing boot files
fi
if ! $(mountpoint -q $ROOT_MOUNT); then
    mount $SD2 $ROOT_MOUNT  # mount root partition containing OS files
fi
Improve this answer
2
  • Thanks, I'll look into doing this if I can't repair the SD. Lessons learned!
    – ardendolas
    Commented Jan 16, 2021 at 17:23
  • Actually, I had a question: do you reckon it would work, if I booted off a fresh MicroSD card, then mounted my new USB SSD partitions, and also mounted my busted-but-readable MicroSD in a USB Adapter. Then use rsync onto the USB SSD copy? Would that potentially set this SSD as a copy of my old OS, setup and all? I know I'm grasping at straws to avoid a few days' worth of setup to get it back to how I was using it before. Thanks, love the nick and avatar btw!
    – ardendolas
    Commented Jan 18, 2021 at 0:34
1

It's possible that you can repair your SD card with fsck; aka e2fsck & fsck.vfat. There's a recent answer that will walk you through the process. This may not help, but it's not a huge effort - "nothing ventured, nothing gained" as they say. You might also review man e2fsck for background.

Since you are now booting from a USB SSD, you may be able to run fsck with the SD card inserted in the RPi's card slot. Before you do this, make sure the SD card is not mounted - verify this with lsblk --fs.

Good luck & follow up in comments if you have questions.

Improve this answer
3
  • Thanks Seamus, problem is when I try this, the command states my partition is read-only. I ran fsck.vfat on my vfat partition with the -n switch and I get: 'code' 0X41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt when I run it with the -p switch: open: Read-only file system edit: gah... sorry, can't get the formatting right for the code bits
    – ardendolas
    Commented Jan 16, 2021 at 16:57
  • @ardendolas: Sorry that didn't help. I think that Milliways answer is the best approach under these circumstances. The only thing I'd add is this: When using rsync in a recovery operation such as yours, it may be best to focus on those files and folders containing data thet you created - as opposed to a folder such as /etc which contains many files whose content was modified automatically based on conditions that may not exist on your "restored" system.
    – Seamus
    Commented Jan 16, 2021 at 19:11
  • @ardendolas: Looking forward, one other thing: If you decide to try image-utils as a backup, this step-by-step may be useful
    – Seamus
    Commented Jan 16, 2021 at 19:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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