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

Having issues with your DietPi installation or found a bug? Post it here.
User avatar
Joulinar
Posts: 4804
Joined: Sat Nov 16, 2019 12:49 am

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

Post by Joulinar »

simply run fdisk -l /dev/sda
Pls let us know if a solution is working. This could help others if they hit by similar situation. Your DietPi Team
User avatar
dwr
Posts: 20
Joined: Thu Feb 18, 2021 3:46 am

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

Post by dwr »

Joulinar wrote: Fri Feb 19, 2021 10:43 pm simply run fdisk -l /dev/sda
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
dwr - SpicyLimes.io
User avatar
MichaIng
Site Admin
Posts: 3011
Joined: Sat Nov 18, 2017 6:21 pm

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

Post by MichaIng »

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?

Code: Select all

umount /mnt/1B1E-0A70
mount /mnt/1B1E-0A70
And when you manually run fsck, anything found?

Code: Select all

umount /mnt/1B1E-0A70
dosfsck /dev/sda1
User avatar
dwr
Posts: 20
Joined: Thu Feb 18, 2021 3:46 am

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

Post by dwr »

MichaIng wrote: Fri Feb 19, 2021 11:55 pm 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?

Code: Select all

umount /mnt/1B1E-0A70
mount /mnt/1B1E-0A70
And when you manually run fsck, anything found?

Code: Select all

umount /mnt/1B1E-0A70
dosfsck /dev/sda1
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.

Code: Select all

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
dwr - SpicyLimes.io
User avatar
MichaIng
Site Admin
Posts: 3011
Joined: Sat Nov 18, 2017 6:21 pm

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

Post by MichaIng »

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.
User avatar
dwr
Posts: 20
Joined: Thu Feb 18, 2021 3:46 am

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

Post by dwr »

MichaIng wrote: Sat Feb 20, 2021 12:54 am 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.
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?
dwr - SpicyLimes.io
User avatar
MichaIng
Site Admin
Posts: 3011
Joined: Sat Nov 18, 2017 6:21 pm

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

Post by MichaIng »

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.
User avatar
dwr
Posts: 20
Joined: Thu Feb 18, 2021 3:46 am

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

Post by dwr »

MichaIng wrote: Sat Feb 20, 2021 1:10 am 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.
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?
dwr - SpicyLimes.io
User avatar
MichaIng
Site Admin
Posts: 3011
Joined: Sat Nov 18, 2017 6:21 pm

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

Post by MichaIng »

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:

Code: Select all

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.
User avatar
dwr
Posts: 20
Joined: Thu Feb 18, 2021 3:46 am

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

Post by dwr »

MichaIng wrote: Sat Feb 20, 2021 1:56 am 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:

Code: Select all

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.
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?
dwr - SpicyLimes.io
Post Reply