[SOLVED] ERROR: unsupported sector size 4096 on /dev/sdm.
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Whenever I run apt-get commands such as update, upgrade I get this error message pertaining to one of my external hard drives. Is it something I should worry about ? This error has been haunting me for over 4 years now.
Code:
ERROR: unsupported sector size 4096 on /dev/sdm.
ERROR: unsupported sector size 4096 on /dev/sdm.
ERROR: unsupported sector size 4096 on /dev/sdm.
ERROR: unsupported sector size 4096 on /dev/sdm.
ERROR: unsupported sector size 4096 on /dev/sdm.
ERROR: unsupported sector size 4096 on /dev/sdm.
ERROR: unsupported sector size 4096 on /dev/sdm.
However the Distro itself is old Ubuntu Mate 16.04, but I keep the kernel fresh.
Then I have to wonder just what program is producing that error message, because that kernel should support 4Kn just fine. About the only thought that comes to mind is an NTFS filesystem being mounted by an old version of ntfs-3g.
I do note that sdm is the only drive listed that is 4K sectors only. All the others are logical/physical 512/512 or 512/4096. Also, all the other drives except sda, sdm, sdr, & sds display this error.
Code:
GPT PMBR size mismatch (4294967294 != 3519002623) will be corrected by w(rite).
I do note that sdm is the only drive listed that is 4K sectors only. All the others are logical/physical 512/512 or 512/4096. Also, all the other drives except sda, sdm, sdr, & sds display this error.
Code:
GPT PMBR size mismatch (4294967294 != 3519002623) will be corrected by w(rite).
I fixed the problem by re-creating my gpt disklabel:
start fdisk
p to display current partitions
g to create a new gpt disklabel
n to add each partition that was previously on this disk. For First sector and Last sector, enter the values outputted by the earlier p command. Do not remove partition signatures.
w
His solution can't be replicated by me because my fdisk doesn't have the same options
Code:
root@odroid:~# fdisk
Usage:
fdisk [options] <disk> change partition table
fdisk [options] -l [<disk>] list partition table(s)
Display or manipulate a disk partition table.
Options:
-b, --sector-size <size> physical and logical sector size
-B, --protect-boot don't erase bootbits when create a new label
-c, --compatibility[=<mode>] mode is 'dos' or 'nondos' (default)
-L, --color[=<when>] colorize output (auto, always or never)
colors are enabled by default
-l, --list display partitions end exit
-o, --output <list> output columns
-t, --type <type> recognize specified partition table type only
-u, --units[=<unit>] display units: 'cylinders' or 'sectors' (default)
-s, --getsz display device size in 512-byte sectors [DEPRECATED]
--bytes print SIZE in bytes rather than in human readable format
-C, --cylinders <number> specify the number of cylinders
-H, --heads <number> specify the number of heads
-S, --sectors <number> specify the number of sectors per track
-h, --help display this help and exit
-V, --version output version information and exit
Available columns (for -o):
gpt: Device Start End Sectors Size Type Type-UUID Attrs Name UUID
dos: Device Start End Sectors Cylinders Size Type Id Attrs Boot End-C/H/S Start-C/H/S
bsd: Slice Start End Sectors Cylinders Size Type Bsize Cpg Fsize
sgi: Device Start End Sectors Cylinders Size Type Id Attrs
sun: Device Start End Sectors Cylinders Size Type Id Flags
For more details see fdisk(8).
Actually it does. If you start fdisk with the command like 'sudo fdisk /dev/sdX' you will open up the partition table for the designated drive and you will see the options in the menu it displays. What you display is the output of 'fdisk --help' which displays the command line options.
Please don't do the suggested fix unless the drives are not in use and not mounted (and you have a data recovery plan if something goes wrong). Altering anything in the partition table on an active / mounted drive can be disastrous.
Also, gdisk is better for use on drives with a gpt partition table, which those are. It works similarly to fdisk with minor differences.
One thing to note, since this thread is about the sector size on /dev/sdm, is that fdisk can also be used to alter the logical/physical sector size in the disk partition table as well. The errors seen on sdm with the invalid sector size can be eliminated by resetting the sector size. Again, I want to stress that changes in the partition table can cause data loss and should not be done without a backup and must not be done on a drive that is mounted / active.
I would guess that at some point fdisk was used with the -b option on /dev/sdm to set the sector size and that would be the origin of the reported error in this thread. The man page for fdisk says:
Code:
OPTIONS
-b, --sector-size sectorsize
Specify the sector size of the disk. Valid values are 512, 1024, 2048, and 4096. (Recent kernels know the sector
size. Use this option only on old kernels or to override the kernel's ideas.) Since util-linux-2.17, fdisk dif‐
ferentiates between logical and physical sector size. This option changes both sector sizes to sectorsize.
I bolded the part that led me to that conclusion. Also this from wikipedia leads me to suggest a mismatch in kernel vs the drive sector size as has already been noted.
If you have a backup of any data on /dev/sdm and you want to eliminate the errors a few simple steps will do that. It will, however, wipe out the existing partition information and require that you rebuild the partition table similar to the fix for the other errors and their fix in the link I posted. It also may lead to the potential for needing to reinstall the windows that is on that drive.
The untested fix I would try would be to simply follow the same instructions for the fix given for the other errors, and see what the results are. Since the partition table is the source of the sector size info the new partition table should fix the error. If the sector size error is not fixed then a little more aggressive fix may be needed, but I believe that would work.
Last edited by computersavvy; 11-23-2021 at 09:34 AM.
Actually it does. If you start fdisk with the command like 'sudo fdisk /dev/sdX' you will open up the partition table for the designated drive and you will see the options in the menu it displays. What you display is the output of 'fdisk --help' which displays the command line options.
Please don't do the suggested fix unless the drives are not in use and not mounted (and you have a data recovery plan if something goes wrong). Altering anything in the partition table on an active / mounted drive can be disastrous.
Also, gdisk is better for use on drives with a gpt partition table, which those are. It works similarly to fdisk with minor differences.
One thing to note, since this thread is about the sector size on /dev/sdm, is that fdisk can also be used to alter the logical/physical sector size in the disk partition table as well. The errors seen on sdm with the invalid sector size can be eliminated by resetting the sector size. Again, I want to stress that changes in the partition table can cause data loss and should not be done without a backup and must not be done on a drive that is mounted / active.
I would guess that at some point fdisk was used with the -b option on /dev/sdm to set the sector size and that would be the origin of the reported error in this thread. The man page for fdisk says:
Code:
OPTIONS
-b, --sector-size sectorsize
Specify the sector size of the disk. Valid values are 512, 1024, 2048, and 4096. (Recent kernels know the sector
size. Use this option only on old kernels or to override the kernel's ideas.) Since util-linux-2.17, fdisk dif‐
ferentiates between logical and physical sector size. This option changes both sector sizes to sectorsize.
I bolded the part that led me to that conclusion. Also this from wikipedia leads me to suggest a mismatch in kernel vs the drive sector size as has already been noted.
If you have a backup of any data on /dev/sdm and you want to eliminate the errors a few simple steps will do that. It will, however, wipe out the existing partition information and require that you rebuild the partition table similar to the fix for the other errors and their fix in the link I posted. It also may lead to the potential for needing to reinstall the windows that is on that drive.
The untested fix I would try would be to simply follow the same instructions for the fix given for the other errors, and see what the results are. Since the partition table is the source of the sector size info the new partition table should fix the error. If the sector size error is not fixed then a little more aggressive fix may be needed, but I believe that would work.
Thank you for the well-put answer, I can tell you took your time explaining it to me to which I am thankful. I am not sure where you get the idea that it's a windows drive, it's an XFat media storage drive filled with data, data which would be hard to back-up as the size of it. The issue has been haunting me for 4+years now so it's not something that is going to create acute damage, and I am very iffish about starting to mess with the sectors and be left with a 1lb paperweight. I am going to call this solved as you have explained in detail what is going on and what can be done about it, thank you again.
Thank you for the well-put answer, I can tell you took your time explaining it to me to which I am thankful. I am not sure where you get the idea that it's a windows drive, it's an XFat media storage drive filled with data, data which would be hard to back-up as the size of it. The issue has been haunting me for 4+years now so it's not something that is going to create acute damage, and I am very iffish about starting to mess with the sectors and be left with a 1lb paperweight. I am going to call this solved as you have explained in detail what is going on and what can be done about it, thank you again.
/dev/sdm IS a windows drive according to the 'fdisk -l' output you posted.
Code:
Disk /dev/sdm: 3.7 TiB, 4000752599040 bytes, 976746240 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: FB5BDDA9-5EFD-427B-B9C3-DCC82120A2B9
Device Start End Sectors Size Type
/dev/sdm1 6 76805 76800 300M EFI System
/dev/sdm2 77056 976745983 976668928 3.7T Microsoft basic data
It has an EFI system partition and a microsoft data partition so it is difficult to tell if it is actually an OS or just data, but fdisk clearly identified it as microsoft. Most disks that are not used for booting would not have an efi system partition. This is why I called it a windows drive.
I am glad we were able to identify the cause of the errors and that you understand the potential fix. I think I would follow along with the same conclusion you iterated if I did not have a suitable drive handy for backups.
HTH and good luck going forward.
Just as an aside. I have 4 3TB drives in my system in raid config for /home, containing about 3.6 TB data. I also have difficulty in doing backups since I do not have a spare drive large enough.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
