Hello everyone,
I used to run Manjaro KDE on a Rpi-400 through a USB SSD until a sudden power-off (my fault).
Now I’m getting unable to read FAT partition on start-up. I’m now on Rpi OS through an SD and I’ve used “Disks” to check the drive, which only sees “unallocated space”.
I’m not an advanced user, but I do my best. If there’s a slim chance to recover some data I’ll take it!
Any suggestions are greatly appreciated. Thank you for your time.
Depending on what damage is done. I am guessing maybe it might have shutdown during a write. You can mount the ssd boot/root partitions on your PiOS. In /var/cache/pacman/pkg/ find the latest versions of these packages.
rpi-overlays
raspberrypi-bootloader
raspberrypi-bootloader-x
The latest kernel (The same one that is in /usrlib/modules on the ssd)
Extract each package and copy /boot filles to your ssd boot partition
copy the extracted kernel package usr/lib/modules/* to the ssd usr/lib/modules/.
Just in case the ssd boot/initramfs_2712 is corrupted rem out this line in the ssd boot/config.txt like this. It is not need to boot the rpi.
#auto_initramfs=1
Shutdown the PiOS and remove the sdcard and boot up the ssd.
1 Like
Thanks a lot for the reply and instructions. I can’t seem to be able to mount the disk. I’m getting
sudo mount /dev/sda /mnt -o uid=pi,gid=pi
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/sda, missing codepage or helper program, or other error.
I then ran fsck which returns
sudo fsck /dev/sda
fsck from util-linux 2.33.1
e2fsck 1.44.5 (15-Dec-2018)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/sda
The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device>
and
sudo e2fsck -b 8193 /dev/sda
e2fsck 1.44.5 (15-Dec-2018)
e2fsck: Bad magic number in super-block while trying to open /dev/sda
The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device>
sudo e2fsck -b 32768 /dev/sda
e2fsck 1.44.5 (15-Dec-2018)
e2fsck: Bad magic number in super-block while trying to open /dev/sda
The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device>
I’m surprised the ssd did not auto mount in PiOS.
sudo mkdir /mnt/boot
sudo mkdir /mnt/root
sudo mount -t vfat /dev/sda1 /mnt/boot
sudo mount -t ext4 /dev/sda2 /mnt/root
Check if mounted
ls /mnt/boot
ls /mnt/root
You will have to be root or use sudo to write to these mounts.
1 Like
Unfortunately, it doesn’t 
sudo mkdir /mnt/boot
pi@raspberrypi:~ $ sudo mkdir /mnt/root
pi@raspberrypi:~ $ sudo mount -t vfat /dev/sda1 /mnt/boot
mount: /mnt/boot: special device /dev/sda1 does not exist.
pi@raspberrypi:~ $ sudo mount -t ext4 /dev/sda2 /mnt/root
mount: /mnt/root: special device /dev/sda2 does not exist.
Follow my directions line by line. If /mnt does not exist then sudo mkdir /mnt first.
If your ssd does not show up in lsblk then you have bigger problems.
The directories are empty. The drive (sda) is present in lsblk:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
ram0 1:0 0 4M 0 disk
ram1 1:1 0 4M 0 disk
ram2 1:2 0 4M 0 disk
ram3 1:3 0 4M 0 disk
ram4 1:4 0 4M 0 disk
ram5 1:5 0 4M 0 disk
ram6 1:6 0 4M 0 disk
ram7 1:7 0 4M 0 disk
ram8 1:8 0 4M 0 disk
ram9 1:9 0 4M 0 disk
ram10 1:10 0 4M 0 disk
ram11 1:11 0 4M 0 disk
ram12 1:12 0 4M 0 disk
ram13 1:13 0 4M 0 disk
ram14 1:14 0 4M 0 disk
ram15 1:15 0 4M 0 disk
loop0 7:0 0 0 loop
loop1 7:1 0 0 loop
loop2 7:2 0 0 loop
loop3 7:3 0 0 loop
loop4 7:4 0 0 loop
loop5 7:5 0 0 loop
loop6 7:6 0 0 loop
loop7 7:7 0 0 loop
sda 8:0 0 223.6G 0 disk
mmcblk0 179:0 0 14.9G 0 disk
├─mmcblk0p1 179:1 0 256M 0 part /boot
└─mmcblk0p2 179:2 0 14.6G 0 part /
sda does not show 2 partitions. Should show sda1 and sda2. Looks like you some how you wiped the drive.
1 Like
I didn’t do anything other than try to boot normally. Thanks for keeping up with me.
I guess this means my only option is to try and format the drive and reinstall the OS.
Sounds like it to me. My lsblk. I have an extra partition for archiving some files.
sda 8:0 0 931.5G 0 disk
├─sda1 8:1 0 250M 0 part /boot
├─sda2 8:2 0 219.7G 0 part
└─sda3 8:3 0 711.5G 0 part /
1 Like
Thanks again for all your help. I lost some important files in this crash. Oh, well.
Love Manjaro and people like you for the work and dedication. Keep it going.
1 Like
To me it sounds, like the partition table is lost. Depending on how important the data is, it may make sense to try to recover it. I would try to do it with ddresuce and testdisk. First create an image of the disk with ddrescue, then use testdisk on the image to recover partition data. Using an image has the advantage, that nothing on the disk itself is changed during recovery tries. I must admit I never did it myself, but thats the way I would go. Also see the Archwiki: File Recovery
2 Likes
Testdisk an Photorec do work
as described in Arch-wiki.
Recovering lost data is a grueling process. There are often several options. That’s why it’s always better to work on a copy (image) of the damaged disk/partition. This gives you the opportunity to try out different approaches.
- It may not work on the first try
- Losses must be expected
- Additional work is usually required to restore the file names
- The directory structure is often not reconstructable
- The rescued files are not 100% reliable
But it may be the only solution if no backup exists
1 Like