Re: fsck error on boot: /dev/sda1: UNEXPECTED INCONSISTENCY and Partition 1 does not start on physical sector boundary
On Thu 18 Mar 2021 at 18:49:57 (+0300), IL Ka wrote:
> >
> > Steady on. There's likely to be a load of personal data on this drive.
> >
>
> Yes, backup should be done first!
>
> > That partition table looks perfectly normal for disks of a certain vintage;
> >
> I agree, but from "fdisk" output I see 4K (advanced format).
>
> Is your drive advanced-formatted?
No. I'm not saying the disk is optimal, but only that it looks as if
it's of a certain vintage. I don't know whether the OP is the sort
of person to ascertain and archive the disk properties when acquired,
but I'm assuming they have had some period of successful use of the
disk in that state, whatever they were using it for.
BTW I'm not even certain what that version of fdisk was concerned
with, nor why it report blocks instead of sectors, but notice it
was careful to report tracks and cylinders!
> Of course, it's been reformatted since then, but not when it was
> > holding any data as yet unbacked-up.
> >
>
> Btw, reformatting is not enough.
> To fix alignment one must delete the partition and create a new one.
Yes, confusing terminology, isn't it, having to "repartition" the disk
to conform with "advanced format".
But sure, it's been zeroed, repartitioned, reformatted, and contains
an encrypted filesystem:
# fdisk -l /dev/sdz
Disk /dev/sdc: 1.4 TiB, 1500301910016 bytes, 2930277168 sectors
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: gpt
Disk identifier: 535847E6-C170-4B13-94C1-378A16323878
Device Start End Sectors Size Type
/dev/sdc1 2048 2930277134 2930275087 1.4T Linux filesystem
#
# cryptsetup --align-payload 2048 luksFormat /dev/sdz1
> AFAIK any modern tool (GNU parted, Windows Disk Manager, diskpart) will use
> 4K alignment by default for any drive.
I habitually add --align-payload because of disks which report
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
which screws up the alignment for encryption. (33553920 is 65535*512.)
> Very old boot loader installed to the MBR may have problems with booting
> (the one that uses CHS instead of LBA), but modern grub should deal with it.
I don't know how the OP uses the NTFS disk, or whether they ever boot
from it, and, if so, what it boots with. AIUI, NTFS disks just come
that way from the shop, by default.
> > Then ask yourself why you're using NTFS on this disk, and whether
> > it might be better to adopt a different filesystem. For myself,
> > I only use NTFS readonly, for reading disks written on Windows.
>
> +1.
>
> NTFS support is not very stable in Linux, it is better to avoid it
Cheers,
David.
Reply to: