I logged in and I saw there were 10 updates. So I ran the update command and rebooted.
I then found “df: /mnt/dietpi_userdata: No such file or directory” in my banner.
I then ran Check and Repair in Drive Manager which returned:
e2fsck 1.46.2 (28-Feb-2021) │
│ ext2fs_check_desc: Corrupt group descriptor: bad block for block bitmap │
│ e2fsck: Group descriptors look bad... trying backup blocks... │
│ Pass 1: Checking inodes, blocks, and sizes │
│ Inode 62395055 extent tree (at level 1) could be narrower. Optimize? yes │
│ Inode 62395091 extent tree (at level 1) could be narrower. Optimize? yes │
│ Inode 62527033 extent tree (at level 1) could be narrower. Optimize? yes │
│ Inode 62527040 extent tree (at level 2) could be narrower. Optimize? yes
I still can not remount my drive?
Any suggestions and help are much appreciated as always.
(Can I format and then do a restore from backup?)
Weird that there is no output about fixing the errors.
You can run e2fsck -cpv /dev/sdX (replace X with the correct letter for your drive, e.g. /sdb2)
c checks for bad blocks; p fixes errors, if possible; v shows the progression in the terminal.
If this doesn’t help, there is a “last resort” option: you can try sudo mkfs.ext4 -S /dev/sdX
-S Write superblock and group descriptors only. This is useful if all of the
superblock and backup superblocks are corrupted, and a last-ditch recovery method
is desired. It causes mke2fs to reinitialize the superblock and group descriptors,
while not touching the inode table and the block and inode bitmaps. The e2fsck
program should be run immediately after this option is used, and there is no
guarantee that any data will be salvageable. It is critical to specify the correct
filesystem blocksize when using this option, or there is no chance of recovery.
You can find out the blocksize with sudo /sbin/dumpe2fs /dev/sdX | grep ‘Block size’
Don’t forget to replace the X in sdX
And good to know you have a backup. dietpi-backup does a full sytem backup, so you could wipe everything, flash new and then restore from the backup. Maybe run e2fsck after the restore, to make sure the backup is not corrupted (honestly I’m not sure if this possible, that a backup can contain corrupted data, because data which is not readable can not be backed up? Maybe somebody else knows better)
Or you try following
fsck -a /dev/sdX
to find out the name of your drive
lsblk -o name,fstype,label,size,ro,type,mountpoint,partuuid,uuid
None of the options seem to work. Can one restore a backup but redirect userdata back to the sd card in the process?
not sure what you mean exactly. Usually external drives are not part of a dietpi-backup. They are excluded on a default setup. Do you have a backup? If yes, you could have a look inside if your data are available.
So I am not sure where I picked up this practice but I typically mount an external hard drive and move dietpi_userdata to it off the microSD.
I am using the Backup Built into dietpi. Does it not backup dietpi_userdata?
if dietpi_userdata is located on the SDcard, it should be part of the backup. You simply could mount your backup drive and check it.