Page 1 of 3

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

Posted: Thu Feb 18, 2021 3:58 am
by dwr
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):

Code: Select all

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!

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

Posted: Thu Feb 18, 2021 3:42 pm
by Joulinar
Hi,

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

Code: Select all

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

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

Posted: Thu Feb 18, 2021 5:54 pm
by dwr
See below...

Code: Select all

# 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

Code: Select all

# 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

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

Posted: Thu Feb 18, 2021 10:06 pm
by Joulinar
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.

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

Posted: Thu Feb 18, 2021 10:56 pm
by dwr
Joulinar wrote: Thu Feb 18, 2021 10:06 pm 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.
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.

Code: Select all

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

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

Posted: Thu Feb 18, 2021 11:01 pm
by Joulinar
can you share as well dmesg -l err,crit,alert,emerg

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

Posted: Thu Feb 18, 2021 11:52 pm
by dwr
Joulinar wrote: Thu Feb 18, 2021 11:01 pm can you share as well dmesg -l err,crit,alert,emerg
See below...

Code: Select all

# 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

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

Posted: Fri Feb 19, 2021 3:57 pm
by Joulinar
@MichaIng
pls can you have a look? You are more the expert on file system corruption :)

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

Posted: Fri Feb 19, 2021 6:23 pm
by MichaIng
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 ;).

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 ;): fdisk -l /dev/sda

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

Posted: Fri Feb 19, 2021 10:39 pm
by dwr
MichaIng wrote: Fri Feb 19, 2021 6:23 pm 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?
I formatted it as FAT32 (previously NTFS) using EaseUS on a Win10 PC at the recommendation of DietPi's, NextCloud, and JellyFin's documentation.
MichaIng wrote: Fri Feb 19, 2021 6:23 pm 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 ;).
Thanks for that info, but I thought I formatted it as a MBR partition, but I could be wrong.
MichaIng wrote: Fri Feb 19, 2021 6:23 pm 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 ;): fdisk -l /dev/sda
Can you elaborate when you say "But it's probably good to first verify my guess ;)"? 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! ;)