Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[Solved - HPA] GDisk - Corrupted partition table recovery
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Other Things Gentoo
View previous topic :: View next topic  
Author Message
DigitalCorpus
Apprentice
Apprentice


Joined: 30 Jul 2007
Posts: 283

PostPosted: Sat Jan 30, 2021 1:47 pm    Post subject: [Solved - HPA] GDisk - Corrupted partition table recovery Reply with quote

I have 2, 4 TB EVO 860 SSDs I've copied my spinning rust data onto as I migrate from my old Q9400 server to my new i5-8500T server. I left one plugged in after having a full Gentoo install and DE functioning while I confirmed my overclock limit with this RAM & CPU, cause I forgot. The plugged in one suffered partition tabel corruption. Both SSDs are a single-partition with a Protected MBR & GPT layout,F2FS formatted. I *could* just wipe, copy, and MD5-verify everything on this single corrupted SSD, but I want to learn a bit more about how to properly recover the partition table. Here's the output of gdisk:

Code:
Warning: Partition table header claims that the size of partition table
entries is 0 bytes, but this program  supports only 128-byte entries.
Adjusting accordingly, but partition table may be garbage.
Warning! Disk size is smaller than the main header indicates! Loading
secondary header from the last sector of the disk! You should use 'v' to
verify disk integrity, and perhaps options on the experts' menu to repair
the disk.
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.

Warning! One or more CRCs don't match. You should repair the disk!
Main header: OK
Backup header: ERROR
Main partition table: OK
Backup partition table: ERROR

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: damaged

****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************

'v'-erifing the partition table nets the following:
Code:
Caution: The CRC for the backup partition table is invalid. This table may
be corrupt. This program will automatically create a new backup partition
table when you save your partitions.

Problem: The secondary header's self-pointer indicates that it doesn't reside
at the end of the disk. If you've added a disk to a RAID array, use the 'e'
option on the experts' menu to adjust the secondary header's and partition
table's locations.

Problem: Disk is too small to hold all the data!
(Disk size is 7814035055 sectors, needs to be 7814037168 sectors.)
The 'e' option on the experts' menu may fix this problem.

Problem: GPT claims the disk is larger than it is! (Claimed last usable
sector is 7814037134, but backup header is at
7814037167 and disk size is 7814035055 sectors.
The 'e' option on the experts' menu will probably fix this problem

Problem: partition 1 is too big for the disk.

Identified 5 problems!


This is where I get confused, the options below and the resuts thereof:
Code:
b       use backup GPT header (rebuilding main)
c       load backup partition table from disk (rebuilding main)
d       use main GPT header (rebuilding backup)
e       load main partition table from disk (rebuilding backup)
f       load MBR and build fresh GPT from it
...
w       write table to disk and exit


If I attempt to 'w'rite out the existing partition table in an understanding that the corrupted backups will be fixed, I already made a backup of the partition table, I get this output:
Code:
Recovery/transformation command (? for help): w
Caution! Secondary header was placed beyond the disk's limits! Moving the
header, but other problems may occur!

Warning! Secondary partition table overlaps the last partition by
2113 blocks!
You will need to delete this partition or resize it in another utility.

Problem: partition 1 is too big for the disk.
Aborting write operation!
Aborting write of new partition table.


If I then select 'e' and then 'v'-erify it, I get:
Code:
Problem: partition 1 is too big for the disk.

Warning! Secondary partition table overlaps the last partition by
2113 blocks!
You will need to delete this partition or resize it in another utility.

Identified 2 problems!


But if I only 'e' it and then verify it, I get:
Code:
Problem: The secondary header's self-pointer indicates that it doesn't reside
at the end of the disk. If you've added a disk to a RAID array, use the 'e'
option on the experts' menu to adjust the secondary header's and partition
table's locations.

Problem: Disk is too small to hold all the data!
(Disk size is 7814035055 sectors, needs to be 7814037168 sectors.)
The 'e' option on the experts' menu may fix this problem.

Problem: GPT claims the disk is larger than it is! (Claimed last usable
sector is 7814037134, but backup header is at
7814037167 and disk size is 7814035055 sectors.
The 'e' option on the experts' menu will probably fix this problem

Problem: partition 1 is too big for the disk.

Identified 4 problems!


I'd rather not spend a day copying ~3 TB of data off of 2 spinning rust drives, but I can. The only 4 TB drive I have to mirror this onto is the original 4 TB HDD mirrored onto the *other* of the paired 860 EVOs. PhotoREC/Testdisk do no support F2FS (just found out because of this) and test disk doesn't seem to think there is a problem with the partition table, so I don't trust that software, but I'm not confident enough with gdisk's output to warrant

I did think of copying the disk and partition UUIDs of the corrupted table, importing a copy of the other SSD's partition table as a known good and then change the subsequent UUIDs, but... the non-corrupted SSD's output reports a disk size of 7814037168 sectors, not 7814035055 sectors. This makes me question doing whole disk partitions, even on read-heavy drives where I wouldn't, and didn't, provide 5-25% overprovisioning.

Guideance is appreciated. Most results I found online didn't deal with this collection of results so here I am.


Last edited by DigitalCorpus on Sun Jan 31, 2021 7:58 pm; edited 1 time in total
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54331
Location: 56N 3W

PostPosted: Sat Jan 30, 2021 2:46 pm    Post subject: Reply with quote

DigitalCorpus,

Maybe the filesystem is damaged?
How did you do the copy?
The wrong answer is dd, unless the drives are *exactly* the same size. If you used dd and the output drive is smaller than the input drive, the end of the input drive is truncated.
That's not recoverable.
So, is
Code:
Problem: partition 1 is too big for the disk.
correct or not?
We will likely need the same data (fdisk) from the source drive.

fdisk will show the disk size and the partition size.

Once we know if its a real problem, we can decide what to do next.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
DigitalCorpus
Apprentice
Apprentice


Joined: 30 Jul 2007
Posts: 283

PostPosted: Sat Jan 30, 2021 10:57 pm    Post subject: Reply with quote

I did rsync -a for the vast majority of the data copy from spinning rust to SSD. I did cp -a for a few outstanding files. sort-ed, md5deep -rel for verification.

Sorry, I skipped a part: I noted there was an initial problem when the disk presented but no partitions mounted and cat /proc/partitions showed that the partition, eg. /dev/sdb*1*, was no longer "detected" by the system. Opening the disk in gdisk then told me the backup structures were corrupted etc.

When verifying the OC limits, I did have a few kernel panics or oops after POST, during kernel loading, rc init, and/r logging into XFCE4. Disk corruption was expected /shrug

non-corrupted SSD:
Code:
Disk /dev/sdb: 3.64 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: Samsung SSD 860
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: FD8A9E7F-1B64-4D04-8EDC-A2E56F243BA7

Device     Start        End    Sectors  Size Type
/dev/sdb1   2048 7814037134 7814035087  3.6T Linux filesystem


corrupted SSD:
Code:
The size of this disk is 3.6 TiB (4000785948160 bytes). DOS partition table format cannot be used on drives for volumes larger than 2199023255040 bytes for 512-byte sectors. Use GUID partition table format (GPT).

Command (m for help): p

Disk /dev/sdc: 3.64 TiB, 4000785948160 bytes, 7814035055 sectors
Disk model: Samsung SSD 860
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: 0x00000000

Device     Boot Start        End    Sectors Size Id Type
/dev/sdc1           1 4294967295 4294967295   2T ee GPT


Because fdisk reported a problem with GPT, I went to gdisk instead of fdisk and was presented with more info, specifically about the GPT structure being damaged.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54331
Location: 56N 3W

PostPosted: Sat Jan 30, 2021 11:26 pm    Post subject: Reply with quote

DigitalCorpus,

Code:
Disk /dev/sdb: 3.64 TiB, 4000787030016 bytes, 7814037168 sectors
Disk /dev/sdc: 3.64 TiB, 4000785948160 bytes, 7814035055 sectors

Are the drives really different sizes?
The sector count should be read from the drive.

What does dmesg say about the Host Protected Areas on the drive?The right answer is nothing.
Grep for HPA.

cp -a and rsync should both be OK an they coy files.

What does
Code:
mount -o ro,offset=1048576 /dev/sd<whole_drive> /mnt/someplace
say?
That will mount the filesystem that starts at block 2048 without reading the partition table.
Have a look round.

There is one potential nasty. Even though the mount is read only, a journal replay can still happen.
This is usually a good thing ... unless the filesystem is corrupt, then in can be very bad.
If the filesystem mounts, what size is it?
df will tell the number of 1k blocks.
Then we need the GPT from the corrupt drive to see if it fits or not.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
DigitalCorpus
Apprentice
Apprentice


Joined: 30 Jul 2007
Posts: 283

PostPosted: Sun Jan 31, 2021 12:18 am    Post subject: Reply with quote

Yeah, it's odd that the pair of SSDs differ in size. I don't know which mechanisms are used for reporting from the various tools, but from /proc/partitions to smartctl, they differ. At the same time, the FTL is a layer of obfuscation and I *assume* that if NAND cells were damaged, the firmware blacklists them and, if it was possible, rewrites the data elsewhere from reconstructed parity info, else the data is viewed as corrupted in software.

Should say nothing... FWIW, this system is an Intel P965 (Intel 82801HB) w/ AHCI in case we get more into the weeds and things look atypical.
Code:
[    0.926768] ata2: SATA max UDMA/133 abar m2048@0xfb106000 port 0xfb106180 irq 29
...
[    1.258913] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
...
[    1.261229] ata2.00: HPA detected: current 7814035055, native 7814037168
[    1.261231] ata2.00: supports DRM functions and may not be fully accessible
...
[    1.261677] ata2.00: ATA-11: Samsung SSD 860 EVO 4TB, RVT04B6Q, max UDMA/133
[    1.261680] ata2.00: 7814035055 sectors, multi 1: LBA48 NCQ (depth 32), AA
[    1.263474] ata2.00: supports DRM functions and may not be fully accessible
[    1.265374] ata2.00: configured for UDMA/133
...
[    1.275059] ata2.00: Enabling discard_zeroes_data


I get this when attempting to mount as root:
Code:
mount -o ro,offset=1048576 /dev/sdc /mnt/recover/
mount: /mnt/recover/: mount failed: Operation not permitted.


In case it is my build that is causing the issue, i.e. the minimal USE flag for xorg-server disables 3D acceleration and I found *1* post about that from 2015 after 3 days of digging. Using the overlay for simpler access to the liquorix kernel sources for the MuQSS patche(s).

emerge -pv util-linux:
Code:
sys-apps/util-linux-2.36.1-r1::gentoo  USE="cramfs logger ncurses nls pam readline (split-usr) suid udev (unicode) -audit -build -caps -cryptsetup -fdformat -hardlink -kill -python (-selinux) -slang -static-libs -su -systemd -test -tty-helpers" ABI_X86="(64) -32 (-x32)" PYTHON_TARGETS="python3_8 -python3_7 -python3_9"


emerge --info:
Code:
Portage 3.0.14 (python 3.8.7-final-0, default/linux/amd64/17.1/desktop, gcc-10.2.0, glibc-2.32-r7, 5.10.7-lqx1-Trim+X11 x86_64)
=================================================================
System uname: Linux-5.10.7-lqx1-Trim+X11-x86_64-Intel-R-_Core-TM-2_Quad_CPU_Q9400_@_2.66GHz-with-glibc2.2.5
KiB Mem:     8161876 total,   4847204 free
KiB Swap:   33554428 total,  33171964 free
Timestamp of repository gentoo: Sat, 30 Jan 2021 10:30:01 +0000
Head commit of repository gentoo: 5a6d0d137db7439de398fedad5efe746c40359f3
sh bash 5.1_p4
ld GNU ld (Gentoo 2.35.1 p2) 2.35.1
ccache version 4.1 [enabled]
app-shells/bash:          5.1_p4::gentoo
dev-java/java-config:     2.3.1::gentoo
dev-lang/perl:            5.32.0-r1::gentoo
dev-lang/python:          2.7.18-r6::gentoo, 3.8.7-r1::gentoo, 3.9.1-r1::gentoo
dev-util/ccache:          4.1::gentoo
dev-util/cmake:           3.19.4::gentoo
sys-apps/baselayout:      2.7-r1::gentoo
sys-apps/openrc:          0.42.1-r1::gentoo
sys-apps/sandbox:         2.20::gentoo
sys-devel/autoconf:       2.13-r1::gentoo, 2.69-r5::gentoo
sys-devel/automake:       1.11.6-r3::gentoo, 1.16.3-r1::gentoo
sys-devel/binutils:       2.35.1-r1::gentoo
sys-devel/gcc:            10.2.0-r5::gentoo
sys-devel/gcc-config:     2.3.3::gentoo
sys-devel/libtool:        2.4.6-r6::gentoo
sys-devel/make:           4.3::gentoo
sys-kernel/linux-headers: 5.10::gentoo (virtual/os-headers)
sys-libs/glibc:           2.32-r7::gentoo
Repositories:

gentoo
    location: /var/db/repos/gentoo
    sync-type: rsync
    sync-uri: rsync://rsync.gentoo.org/gentoo-portage
    priority: -1000
    sync-rsync-verify-jobs: 2
    sync-rsync-extra-opts:
    sync-rsync-verify-metamanifest: yes
    sync-rsync-verify-max-age: 6

x-portage
    location: /usr/local/portage
    masters: gentoo
    priority: 0

heindsight
    location: /var/lib/layman/heindsight
    masters: gentoo
    priority: 50

thegreatmcpain
    location: /var/lib/layman/thegreatmcpain
    masters: gentoo
    priority: 50

ACCEPT_KEYWORDS="amd64 ~amd64"
ACCEPT_LICENSE="* -@EULA"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=native -O2 -pipe "
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php8.0/ext-active/ /etc/php/cgi-php8.0/ext-active/ /etc/php/cli-php8.0/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-march=native -O2 -pipe "
DISTDIR="/var/db/repos/cache/distfiles"
EMERGE_DEFAULT_OPTS="--jobs 3 --keep-going --quiet-fail y"
ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR"
FCFLAGS="-march=native -O2 -pipe "
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs ccache clean-logs compress-build-logs compress-index compressdebug config-protect-if-modified distlocks ebuild-locks fail-clean fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch parallel-install pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms split-log splitdebug strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-march=native -O2 -pipe "
GENTOO_MIRRORS="http://gentoo.osuosl.org/                       http://gentoo.mirrors.easynews.com/linux/gentoo/               https://mirror.leaseweb.com/gentoo/"
LANG="en_US.utf8"
LDFLAGS="-march=native -O2 -pipe  -Wl,-O1 -Wl,--as-needed -Bdirect -Wl,--hash-style=gnu,--sort-common,-znow,-zrelro"
LINGUAS="en_US en"
MAKEOPTS="-j4"
PKGDIR="/var/db/repos/cache/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_EXTRA_OPTS=""
PORTAGE_RSYNC_OPTS="--compress --compress-level=6 --delete --delete-during --force --links --perms --preallocate               --recursive --safe-links --stats --times --whole-file --timeout=15 --exclude=/distfiles                  --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/home/.tmp"
USE="X a52 aac acl acpi aio alsa amd64 berkdb bidi bindist branding bzip2 cairo cdda cdr cli crypt dbus dri dts dvd dvdr elogind emboss encode exif flac gallium gd gdbm gif gtk gtk2 gtk3 gui iconv icu initramfs introspection io-uring ipv6 jpeg jpeg2k lcms libglvnd libnotify libtirpc lighttpd llvm lm-sensors lzma minimal mng mp3 mp4 mpeg multilib native-cflags ncurses nls nptl nsplugin ogg opengl openmp pam pango pcre pcre16 pdf php png policykit ppds qt5 readline rule-generator samba seccomp sensord sna spell split-usr ssl startup-notification svg symlink tcpd threads tiff truetype udev udisks unicode upower usb vdpau vorbis vulkan widevine wxwidgets x264 xattr xcb xkb xml xscreensaver xslt xv zlib" ABI_X86="64" ALSA_CARDS="hda-intel" CPU_FLAGS_X86="mmx mmxext sse sse2 sse3 ssse3 sse4_1" ELIBC="glibc" INPUT_DEVICES="libinput" KERNEL="linux" L10N="en en-US" LCD_DEVICES="ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LLVM_TARGETS="X86" LUA_SINGLE_TARGET="lua5-1" LUA_TARGETS="lua5-1" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-3 php7-4" POSTGRES_TARGETS="postgres10 postgres11" PYTHON_SINGLE_TARGET="python3_8" PYTHON_TARGETS="python2_7 python3_8" RUBY_TARGETS="ruby26 ruby27" USERLAND="GNU" VIDEO_CARDS="nvidia"
Unset:  CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS
Back to top
View user's profile Send private message
DigitalCorpus
Apprentice
Apprentice


Joined: 30 Jul 2007
Posts: 283

PostPosted: Sun Jan 31, 2021 12:35 am    Post subject: Reply with quote

I used gdisk to backup the GPT to disk for both SSDs, sdb = good & sdc = bad, and here is the non-zero hex from them using dhex w/ a little padding:

Bad, sdc:
Code:
     198     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00     ........................
     1B0     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  02 00 ee ff ff ff 01 00     ........................
     1C8     00 00 ff ff ff ff 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00     ........................
     1E0     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00     ........................
     1F8     00 00 00 00 00 00 55 aa  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00 00     ......U.EFI PART....\...
     210     89 5e 68 38 00 00 00 00  01 00 00 00 00 00 00 00  af be c0 d1 01 00 00 00     .^h8....................
     228     22 00 00 00 00 00 00 00  8e be c0 d1 01 00 00 00  9e 67 f4 4a cb 40 26 45     "................g.J.@&E
     240     ad 80 00 a3 4f 53 c4 f7  02 00 00 00 00 00 00 00  80 00 00 00 80 00 00 00     ....OS..................
     258     26 eb 66 8e 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00     &.f.....................
     270     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00     ........................


Good, sdb:
Code:
     198     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00     ........................
     1B0     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  02 00 ee ff ff ff 01 00     ........................
     1C8     00 00 ff ff ff ff 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00     ........................
     1E0     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00     ........................
     1F8     00 00 00 00 00 00 55 aa  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00 00     ......U.EFI PART....\...
     210     40 f2 f0 76 00 00 00 00  01 00 00 00 00 00 00 00  af be c0 d1 01 00 00 00     @..v....................
     228     22 00 00 00 00 00 00 00  8e be c0 d1 01 00 00 00  7f 9e 8a fd 64 1b 04 4d     "...................d..M
     240     8e dc a2 e5 6f 24 3b a7  02 00 00 00 00 00 00 00  80 00 00 00 80 00 00 00     ....o$;.................
     258     53 5b 01 81 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00     S[......................
     270     00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00     ........................


I've installed the sleuth kit in case that is the next step
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54331
Location: 56N 3W

PostPosted: Sun Jan 31, 2021 9:53 am    Post subject: Reply with quote

DigitalCorpus,

Why do yo have a HPA on that drive?
Code:
[    1.261229] ata2.00: HPA detected: current 7814035055, native 7814037168
[    1.261231] ata2.00: supports DRM functions and may not be fully accessible


That account for the difference ins sizes shown here.
Code:
Disk /dev/sdb: 3.64 TiB, 4000787030016 bytes, 7814037168 sectors
Disk /dev/sdc: 3.64 TiB, 4000785948160 bytes, 7814035055 sectors


The HPA is a 'hidden' region at the end of the drive that the drive hides from the operating system. Its typically used by large vendors for storing a recover image and has been used it the past for BIOS too.
The drive reports that it is 7814035055 sectors but its actually 7814037168 sectors.
I suspect that the HPA was created after the GPT disk lable and filesystem were added, now the end of the filesystem and the second copy of the GPT are inside the HPA.
They are probably still there.

Code:
mount -o ro,offset=1048576 /dev/sdc /mnt/recover/
mount: /mnt/recover/: mount failed: Operation not permitted.
suggests that you were not root.
Don't do this again as its likely that the end of the filesystem cannot be read.

If you didn't create the HPA and there is no reason for you to have a HPA on that drive, remove it. I suspect thaf the errors will go away then. hdparm can change the HPA settings.
Its a dangerous tool, so go careful with in.

The HPA is created with some low level ATA commands to the drive. If that happened accidentality, who knows what else happened.
Random writes in the middle of any mounted filesystems for example?
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
DigitalCorpus
Apprentice
Apprentice


Joined: 30 Jul 2007
Posts: 283

PostPosted: Sun Jan 31, 2021 7:12 pm    Post subject: Reply with quote

I haven't heard of HPA until you had me grep my boot log. Don't know how it got "turned on"

I tried the mount as root and got that result, which is why I posted USE flags
Back to top
View user's profile Send private message
DigitalCorpus
Apprentice
Apprentice


Joined: 30 Jul 2007
Posts: 283

PostPosted: Sun Jan 31, 2021 7:27 pm    Post subject: Reply with quote

If I'm understanding the man page correctly, the following command should remove HPA from the affected drive, currently sdc.
Code:
hdparm -Np7814037168 /dev/sdc


I'll report back shortly

</break>

HPA was disabled sucessfully and auto mounting via label worked aye-okay. Unmounted and running fsck on the filesystem atm. I have no idea how it got turned on...


Last edited by DigitalCorpus on Sun Jan 31, 2021 7:34 pm; edited 1 time in total
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54331
Location: 56N 3W

PostPosted: Sun Jan 31, 2021 7:30 pm    Post subject: Reply with quote

DigitalCorpus,

I don't understand the
Code:
Operation not permitted
error.
Its just as well it failed though.

Creating the HPA is programming some memory in the HDD. Your data is still there unless something wrote to the HPA, then the data that was there is gone.
That offset=1048576 is supposed to be 2048*512 ... for the start byte of the first partition, counting from the start of the drive.

Reading the man page, I would take is slowly.

Code:
-N displays the
              current setting, which is reported  as  two  values:  the  first
              gives  the current max sectors setting, and the second shows the
              native (real) hardware limit for the disk.
Does that work and give the numbers you expect?
Next, try
Code:
-Nnative (real) hardware limit for the disk
.

/dev/sdc1 may mount now. The change has been made but its not yet permanet.
You may need a SCSI bus rescan first.
If that looks good, try the -Np version.

Then there is
Code:
       --dco-restore
              Reset  all  drive  settings, features, and accessible capacities
              back to factory defaults and full  capabilities.   This  command
              will  fail if DCO is frozen/locked, or if a -Np maximum size re‐
              striction has also been set.  This is  EXTREMELY  DANGEROUS  and
              will  very  likely  cause massive loss of data.  DO NOT USE THIS
              COMMAND.


Some or all of these commands may issue a whole drive trim command for free. That will erase the entire drive but you do have a backup.?
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.


Last edited by NeddySeagoon on Sun Jan 31, 2021 7:51 pm; edited 2 times in total
Back to top
View user's profile Send private message
DigitalCorpus
Apprentice
Apprentice


Joined: 30 Jul 2007
Posts: 283

PostPosted: Sun Jan 31, 2021 7:36 pm    Post subject: Reply with quote

NeddySeagoon wrote:
DigitalCorpus,

I don't understand the
Code:
Operation not permitted
error.
Its just as well it failed though.

Creating the HPA is programming some memory in the HDD. Your data is still there unless something wrote to the HPA, then the data that was there is gone.
That offset=1048576 is supposed to be 2048*512 ... for the start byte of the first partition, counting from the start of the drive.

This is dealing with lower level concepts than what I've touched on before in the past. The offset math made sense to me too so I don't know why it refused to work.


And, thank you btw for your guidance and support, Neddy
Back to top
View user's profile Send private message
DigitalCorpus
Apprentice
Apprentice


Joined: 30 Jul 2007
Posts: 283

PostPosted: Sun Jan 31, 2021 7:57 pm    Post subject: Reply with quote

If this data was not the backup, I'd have taken it a little slower and tested the non-once-per-instance version of the command. I did a little more searching and netted this writeup someone did that advised overprovisioning of an SSD with HPA. I mean, I get it, but that's rather a rather hardcore limit instead of just creating a smaller partition.

https://www.thomas-krenn.com/en/wiki/SSD_Over-provisioning_using_hdparm


Edit:
Possibly the mount command has a HPA check that prevented operation from continuing???


Edit 2:
fsck-ing checked out fine. All systems go.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54331
Location: 56N 3W

PostPosted: Sun Jan 31, 2021 9:01 pm    Post subject: Reply with quote

DigitalCorpus,

SSDs are over provisioned anyway. There is no need to 'footer' with a HPA.
Look at smartctl -a to see the over provisioning.

Code:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
180 Unused_Reserve_NAND_Blk 0x0033   000   000   000    Pre-fail  Always       -       4403

_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
DigitalCorpus
Apprentice
Apprentice


Joined: 30 Jul 2007
Posts: 283

PostPosted: Sun Jan 31, 2021 9:17 pm    Post subject: Reply with quote

Neddy,

I'd say the overprovisioning is dependent upon model and manufacturer. The MX500 and 2 860 EVOs I have have none listed under ID 180 or any similarly named ID listed out by smartctl.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54331
Location: 56N 3W

PostPosted: Sun Jan 31, 2021 9:25 pm    Post subject: Reply with quote

DigitalCorpus,

It will still be there. Its the only way to cope with manufacturing defects and through life sector fails.
Its been on rotating rust HDD for over 20 years now, hence you never find any bad sectors on a HDD until its end of life.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
DigitalCorpus
Apprentice
Apprentice


Joined: 30 Jul 2007
Posts: 283

PostPosted: Mon Feb 01, 2021 1:33 am    Post subject: Reply with quote

Needy,

Yes, it is there, but as Adandtech has pointed out over the years, it’s largely an unpublished spec. So if this were a write-heavy drive, I’d be adding a 10-20% on top of the unknown for performance consistency’s sake.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54331
Location: 56N 3W

PostPosted: Mon Feb 01, 2021 9:57 am    Post subject: Reply with quote

DigitalCorpus,

Agreed. It will be 10% or less though. Silicon storage is made in chunks of 2^n.
The 10% comes from the approximate difference between 1000 and 1024. That's kB or kiB.
Any more would need an extra address bit on the controller, which pushes up the cost. Any less is cost savings to the manufacturer.
Reducing it too far will upset buyers and push up the costs due to warranty returns.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Other Things Gentoo All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum