--- Begin Message ---
|
Subject: |
parted not recognizing partitions in "non-standard" MBRs with valid partition tables |
|
Date: |
Thu, 15 Nov 2018 00:27:02 +0200 |
|
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 |
Hello,
While parted 2.3 had no issues with whatever was in the first 446 bytes
of the MBR and only looked at the partition table, newer versions such
as 3.2 seem to be thrown by unusual boot code (e.g. Grub4DOS) and either
show the entire disk as unallocated space or as one big volume/partition
with the file system of the first volume. This is despite the partition
table being fully compliant and happily read by fdisk and sfdisk.
This may be a "feature" rather than a bug. Please pardon my ignorance,
perhaps newer partition table schemes require the first 446 bits to be
parsed. However it could save someone many hours of frustration if this
was noted prominently in the documentation.
In my case It was fixed with a simple:
dd if=/usr/lib/syslinux/mbr/mbr.bin of=/dev/sdb bs=446 count=1
after taking the requisite backups and a deep breath.
Thanks and regards,
Marc
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#33389: parted not recognizing partitions in "non-standard" MBRs with valid partition tables |
|
Date: |
Tue, 23 Apr 2019 12:42:13 -0400 |
|
User-agent: |
mu4e 0.9.18; emacs 25.2.2 |
Unfortunately to figure out what went wrong would require examining the
partition table, which it appears you have destroyed. If you happened
to have saved a copy and can provide it, please do so and we can reopen
the bug.
Marc Stenson writes:
> Hello,
>
> While parted 2.3 had no issues with whatever was in the first 446 bytes
> of the MBR and only looked at the partition table, newer versions such
> as 3.2 seem to be thrown by unusual boot code (e.g. Grub4DOS) and either
> show the entire disk as unallocated space or as one big volume/partition
> with the file system of the first volume. This is despite the partition
> table being fully compliant and happily read by fdisk and sfdisk.
>
> This may be a "feature" rather than a bug. Please pardon my ignorance,
> perhaps newer partition table schemes require the first 446 bits to be
> parsed. However it could save someone many hours of frustration if this
> was noted prominently in the documentation.
>
> In my case It was fixed with a simple:
> dd if=/usr/lib/syslinux/mbr/mbr.bin of=/dev/sdb bs=446 count=1
> after taking the requisite backups and a deep breath.
>
> Thanks and regards,
> Marc
--- End Message ---