From: tuxic@posteo.de
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Trouble with backup harddisks
Date: Thu, 30 Apr 2020 20:08:39 +0200 [thread overview]
Message-ID: <20200430180839.iz4kxipst2i5stwp@solfire> (raw)
In-Reply-To: <22faa7cf-7291-b430-c646-b96c6d428f19@alyf.net>
On 04/30 03:44, Andrea Conti wrote:
> Hi,
>
> > > CONFIG_PARTITION_ADVANCED=y
> > > CONFIG_MSDOS_PARTITION=y
> > > CONFIG_EFI_PARTITION=y
>
> That's all you need.
>
> > This could be the key. Sector sizes have been changing from 512 to 4096
> > over many years. If your kernel has been updated to expect/use 4096 byte
> > sectors, it might not be able to read the disk properly.
>
> Sector size is only a (fixed) property of a specific block device, not something expected or required by the kernel.
> Sector sizes other than 512B have been around for ages without any problems, even in consumer hardware (e.g. CDs and DVDs have 2KB sectors).
>
> > Disklabel type: dos
>
> > Device Boot Start End Sectors Size Id Type
> > /dev/sdb1 1 1953458175 1953458175 931.5G ee GPT
>
> That looks... broken.
> fdisk is recognizing the disk as MBR (a GPT disk would have "Disklabel type: gpt"), but the partition table is a protective MBR, which makes no sense in a non-GPT disk.
>
> My guess is that this disk was at some time partitioned with GPT (possibly it came that way from WD?), but then it was only used in machines with no kernel support for GPT.
> Such a machine will happily treat that as a normal MBR and allow you to access the protective entry as a normal partition, which means you can create a filesystem on it and fill it with data, destroying the GPT structures.
>
> A GPT-aware kernel on the other hand will recognize that as a protective MBR and it will ignore it --but since the disk does not contain any valid GPT structures, it will not show any partitions.
>
> Try running "gdisk -l /dev/sdb"; for a valid GPT disk it will say:
>
> Partition table scan:
> MBR: protective
> BSD: not present
> APM: not present
> GPT: present
>
> If that's not the case and you have no GPT, you will have to fix things manually.
> Since the disk is only 1TB, there is no reason to use GPT at all, so your best bet is to use fdisk to make that a standard MBR by changing the partition type from 'ee' to '83'.
>
> andrea
>
Hi Andreas,
thank you very much for your analysis! :)
when doing a gdisk -l /dev/sdb I get this Rocky Horror Picture Show:
PT fdisk (gdisk) version 1.0.5
Caution: invalid main GPT header, but valid backup; regenerating main header
from backup!
Caution! After loading partitions, the CRC doesn't check out!
Warning: Invalid CRC on main header data; loaded backup partition table.
Warning! Main and backup partition tables differ! Use the 'c' and 'e' options
on the recovery & transformation menu to examine the two tables.
Warning! One or more CRCs don't match. You should repair the disk!
Main header: ERROR
Backup header: OK
Main partition table: ERROR
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.
****************************************************************************
Disk /dev/sdb: 1953458176 sectors, 931.5 GiB
Model: Elements 25A2
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): BCA95A74-1E0A-4648-9971-20ED4049CAE5
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 1953458142
Partitions will be aligned on 2048-sector boundaries
Total free space is 1953458109 sectors (931.5 GiB)
Number Start (sector) End (sector) Size Code Name
"fix manually" scares me...especially because I have no place for
1TB of an image file to with which I can experiment ...
Any ideas which could ease my burden and to un-scare my
"need to fix it manually" ??? ;) ;)
Cheers!
Meino
next prev parent reply other threads:[~2020-04-30 18:08 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-30 9:32 [gentoo-user] Trouble with backup harddisks tuxic
2020-04-30 9:55 ` Wols Lists
2020-04-30 10:36 ` tuxic
2020-04-30 12:17 ` Wols Lists
2020-04-30 13:10 ` Wynn Wolf Arbor
2020-04-30 17:04 ` tuxic
2020-04-30 17:21 ` Wynn Wolf Arbor
2020-04-30 19:32 ` antlists
2020-05-01 1:59 ` tuxic
2020-05-01 8:03 ` tuxic
2020-05-01 20:27 ` antlists
2020-05-02 1:42 ` tuxic
2020-05-02 17:31 ` Wols Lists
2020-05-02 17:49 ` tuxic
2020-05-02 17:55 ` tuxic
2020-04-30 13:44 ` Andrea Conti
2020-04-30 18:08 ` tuxic [this message]
2020-04-30 19:27 ` Wynn Wolf Arbor
2020-04-30 19:46 ` tuxic
2020-04-30 19:59 ` Wynn Wolf Arbor
2020-04-30 20:21 ` Andrea Conti
2020-04-30 20:47 ` Wynn Wolf Arbor
2020-05-01 5:07 ` tuxic
2020-05-01 6:52 ` Andrea Conti
2020-05-01 7:18 ` tuxic
2020-05-01 10:27 ` Wynn Wolf Arbor
2020-05-01 16:00 ` Andrea Conti
2020-05-01 16:32 ` Peter Humphrey
2020-05-02 2:03 ` tuxic
2020-05-02 7:49 ` Andrea Conti
2020-05-02 8:39 ` tuxic
2020-05-02 9:23 ` Michael
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200430180839.iz4kxipst2i5stwp@solfire \
--to=tuxic@posteo.de \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox