SSD Auto-Mount Issue "offset:original/backup"

Troubleshooting
1

Greetings,

First and foremost, thanks to the DietPi Team for building an absolutely amazing OS with all these pre-built software packages - while I am somewhat new to Raspberry Pi’s and Linux coding in general, I do fancy myself a fast learner (meaning, please bare with me by ELI5).

So here’s the issue: I setup NextCloud and JellyFin on a 2GB Pi4, and attached an external SSD via a NESPi case which powers the SDD and the Pi. After the successful installation of these programs, I did a reboot and noticed that the SSD was not being mounted at boot as I had configured it to do in the DietPi Configuration. I ran the DietPi Device Manager’s “repair” tool and found the following error (to which I have no idea what it means):

There are differences between boot sector and its backup. This is mostly harmless. Differences: (offset:original/backup) 29:08/00

After 2 hours of searching Google, I came up with exactly nothing. I removed the SSD (safely) and ran a Windows Disk Check and Repair to no avail. I even tried removing the line in etc/fstab, rebooting, remounting, and still continue to get this error. Can anyone explain how I can fix this issue so that the SSD is automatically mounted to the same location each time a reboot is required?

Thanks in advance!

2

Hi,

not sure if I understood you correctly but can you share following

cat /etc/fstab
lsblk -o name,fstype,label,size,ro,type,mountpoint,partuuid,uuid
3

See below…

# cat /etc/fstab
# Please use "dietpi-drive_manager" to setup mounts
#----------------------------------------------------------------
# NETWORK
#----------------------------------------------------------------


#----------------------------------------------------------------
# TMPFS
#----------------------------------------------------------------
tmpfs /tmp tmpfs size=1938M,noatime,lazytime,nodev,nosuid,mode=1777
tmpfs /var/log tmpfs size=50M,noatime,lazytime,nodev,nosuid,mode=1777

#----------------------------------------------------------------
# MISC: ecryptfs, vboxsf (VirtualBox shared folder), gluster, bind mounts
#----------------------------------------------------------------


#----------------------------------------------------------------
# SWAPFILE
#----------------------------------------------------------------


#----------------------------------------------------------------
# PHYSICAL DRIVES
#----------------------------------------------------------------
PARTUUID=e8af6eb2-02 / ext4 noatime,lazytime,rw 0 1
PARTUUID=e8af6eb2-01 /boot vfat noatime,lazytime,rw 0 2
UUID=1B1E-0A70 /mnt/1B1E-0A70 vfat noatime,lazytime,rw,nofail,noauto,x-systemd.automount




# lsblk -o name,fstype,label,size,ro,type,mountpoint,partuuid,uuid
NAME FSTYPE LABEL   SIZE RO TYPE MOUNTPOINT PARTUUID                             UUID
sda               931.5G  0 disk                                                 
└─sda1
                  931.5G  0 part /mnt/1B1E-                                      
mmcblk0
│                  59.5G  0 disk                                                 
├─mmcblk0p1
│    vfat   boot    256M  0 part /boot      e8af6eb2-01                          DC3E-E470
└─mmcblk0p2
     ext4   rootfs
                   59.2G  0 part /          e8af6eb2-02                          a7adb26a-8b87-4729-99c8-9f5ac069d51e
4

ok by default DietPi will create the mount with option x-systemd.automount. Means the drive is not mounted during boot process already. It will be done as soon as someone is trying to access the drive. You could do a test and reboot the system. Once back online, try to access your drive cd /mnt/1B1E-0A70 and check if the drive was mounted now.

5

That is correct - from my searching around Google, I was able to come to the same conclusion, however because of the error listed above in my original post (which was an output of the “DietPi-Drive Manager’s” “Scan and Repair” feature), accessing it after boot still doesn’t mount it.

As you mentioned, I have completed 5 tests:

  • Reboot > Terminal > cd /mnt/1B1E-0A70


  • Reboot > PCManFM File Manager > /mnt/1B1E-0A70


  • Reboot > Attempt Connection from a Separate Linux Laptop via Samba


  • Reboot > Attempt Connection from a Separate Linux Laptop via JellyFin


  • Reboot > Attempt Connection from a Separate Linux Laptop via NextCloud

All of which failed to automatically “re-mount” the SSD upon attempting to access it. Instead, I am required to open the “DietPi-Drive Manager” and remount the SSD from there.

Again, from what I was reading from numerous articles, blogs, and forums, this seems to be caused by the error in the original post however I do not know what it means or how to fix it.

There are differences between boot sector and its backup. This is mostly harmless. Differences: (offset:original/backup) 29:08/00

Thoughts?

6

can you share as well dmesg -l err,crit,alert,emerg

7

See below…

# dmesg -l err,crit,alert,emerg
[  200.114672] sd 0:0:0:0: [sda] tag#0 timing out command, waited 180s
[  200.114794] blk_update_request: I/O error, dev sda, sector 1953521536 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[  611.609425] v3d fec00000.v3d: MMU error from client L2T (0) at 0x3f81000, pte invalid
8

MichaIng
pls can you have a look? You are more the expert on file system corruption :slight_smile:

9

That is actually not an error but more a warning, but probably it still breaks automount. How did you format the drive, i.e. did you use dietpi-drive_manager to format it?

The warning indicates that it is formatted with a GPT partition table (default as well with dietpi-drive_manager) but that it has a boot sector (which should be purged by dietpi-drive_manager). GPT partitions have a primary boot sector (and as well a primary partition table) and a backup of it at the end of the drive. This backup is missing or wrong in your case, likely because it is not used as boot drive :wink:.

The following can be used to re-create the backup section on GPT patitions: sgdisk -e /dev/sda
But it’s probably good to first verify my guess :wink:: fdisk -l /dev/sda

10

I formatted it as FAT32 (previously NTFS) using EaseUS on a Win10 PC at the recommendation of DietPi’s, NextCloud, and JellyFin’s documentation.

Thanks for that info, but I thought I formatted it as a MBR partition, but I could be wrong.

Can you elaborate when you say “But it’s probably good to first verify my guess :wink:”? Should I verify something first? Or simply run that script?

Thanks again to you both for your continued assistance! Might be time for me to buy you guys a cup of coffee! :wink:

11

simply run fdisk -l /dev/sda

12

Apologies - I missed that somehow. Here is the output…

fdisk -l /dev/sda

Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: Generic
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xac13b40b

Device Boot Start End Sectors Size Id Type
/dev/sda1 2048 1953521663 1953519616 931.5G b W95 FAT32

13

Okay it is not a GPT partition. Then I’m wondering if the message is even related to that drive.

Is there any output when you manually unmount and remount the drive?

umount /mnt/1B1E-0A70
mount /mnt/1B1E-0A70

And when you manually run fsck, anything found?

umount /mnt/1B1E-0A70
dosfsck /dev/sda1
14

So the unmount command works, but when attempting to re-mount, it doesn’t. Additionally, you can see from running ‘fsck’, the same error pops up but this time I have options to correct the issue - which do you recommend that I select? See the output below.

root@MediaPi:~# umount /mnt/1B1E-0A70
root@MediaPi:~# mount /mnt/1B1E-0A70
root@MediaPi:~# umount /mnt/1B1E-0A70
umount: /mnt/1B1E-0A70: not mounted.
root@MediaPi:~# mount /mnt/1B1E-0A70
root@MediaPi:~# umount /mnt/1B1E-0A70
umount: /mnt/1B1E-0A70: not mounted.
root@MediaPi:~# dosfsck /dev/sda1
fsck.fat 4.1 (2017-01-24)
There are differences between boot sector and its backup.
This is mostly harmless. Differences: (offset:original/backup)
  29:08/00
1) Copy original to backup
2) Copy backup to original
3) No action
15

Okay, boot sector and partition table are both on the first 512 bytes if the drive. So purging or changing that sector will purge the partition table as well. Do you have relevant data on that drive already? Else I’d suggest to reformat it. Is there a certain reason why you used FAT? If it must be mountable on Windows, one would usually use NTFS, else ext4.

But before you reformat, probably a faster fix could be 2) Copy backup to original.

16

Yes, I have around 500GB worth of media that I use with Jelly Fin. The weird thing is that this drive held the same content (as NTFS) before I reformatted it to FAT32 (and then reloaded the data back onto the drive), so it was a clean format (which I did just a few days ago). So why would there be any issues at this point? A mystery for sure…

The reason why I used FAT32 was for its compatibility with all operating systems as I currently have a mixture of OS’s that I use (Linux based, Windows based, Android based, iOS based, etc) and I wanted to ensure I could access this SSD from any of those devices. Do you recommend just sticking with NTFS? Also, as a side question, what are your thoughts on booting directly from the SSD rather than the MicroSD (obviously I would offload the media from the drive, and then have the DietPi-Drive Manager reformat for me)?

Should I go ahead with applying the second option first before taking other steps?

17

Ah okay, if Android and iOS need to have access as well, probably FAT32 is best as I’m not sure how well those deal with NTFS. exFAT would be an idea in case of an SSD, and should be fine with Android and iOS as well.

Can you plug the drive to Windows and run an file system check there? In case of FAT and NTFS I trust the Windows repair tools more.

If Windows repair does not help, back on Linux 2) Copy backup to original is worth to give a try, yes.

18

Actually, I did a command line CHKDSK 2 nights ago (which took literally all night because this thing was full of files and is 1TB) and resulted in 0 issues found, 0 issues fixed.

Before I run option #2, I just want to make 100% sure that this won’t format the drive, correct?

19

Does the drive mount successfully on Windows?

Option 2 will copy the backup boot sector to the original boot sector. So if the backup boot sector is broken, it will break the drive. It won’t format the data, but making them inaccessible. However, it’s possible to re-create the partition table which should make the data available as well. However I cannot give a guarantee for this.

Option 1 will do it the other way round, so it won’t make the drive mountable, if it is currently not mountable, but it will copy the possibly broken boot sector to the backup location, at least fixing/muting the fsck error about the mismatch. But I don’t think that this mismatch prevents the mount.

To re-create the partition table manually:

fdisk /dev/sda
d # this deletes a partition (not the data, just the reference in the partition table)
1 # delete partition 1
n # create new partition
1 # partition 1
# hit return to accept the first sector default, which should be 2048 bytes
# hit return to accept the last sector default, which should be the whole drive space
w # write partition table to drive

All this is written to the first 512 bytes of the drive only, while the actual data start with the file systems at byte 2048, so they should be readable perfectly fine after the procedure.

20

Yes, the drive does mount on Windows without issue.

So, I decided on going with the red pill, err, I mean option 2 to which the same issues arose. So I decided to go back to good ole’ NTFS format. And everything works as it should. Just an FYI - I decided to test a brand new SDD (MBR partition; FAT32 format) on the Pi to see if it would happen to this drive as well - sure enough, same issue. After some searching online (and getting more confused), it turns out that FAT32 formatted drives (not all, but some based on manufacturer) do not play well with DietPi’s (and more specifically, linux) automount feature.

While I do not know why this inherent issue is persistent with both a Kingston and Samsung SSD’susing Linux automount function, I do sincerely appreciate the assistance by both MichaIng and Joulinar. Can I buy either of you a coffee for your time and patience?