search for: extended_boot_record

Hi All, Slightly OT as this is on a Centos 6 system I'm getting the fdisk message "partition does not start on a physical sector boundary" on a 4096 sector disk. I understand why this has happened. I just want to be sure of my parted syntax before I really mess things up. (before anyone says it - I know - do a backup) parted says that the offending partition 5 begins at 512 byte

Thomas Schmitt wrote: > Since we know that the isolinux.bin binary is well ok on other partitions, > i'd say that the MBR code does not load the right blocks from disk when > it wants to get isolinux.bin. Yes, these are my thoughts as well. I think the jump from GRUB to the isohybrid code on the logical partition is working fine, but when the isohybrid code is trying to jump to

Hi, i think i found the reason for the boot failure in the definition of Extended Boot Records. https://en.wikipedia.org/wiki/Extended_boot_record#Values "Starting sector = relative offset between this EBR sector and the first sector of the logical partition. Note: This is often the same value for each EBR on the same hard disk; usually 63 for Windows XP or older." So if GRUB hands the partition table entry of /dev/sdc5...

...ion table. The MBR format is maximally -compatible with all clients, but only supports up to 4 partitions. +compatible with all clients. + +If there are E<gt> 4 partitions then the first three files are mapped +to primary partitions, an extended partition +(L<https://en.wikipedia.org/wiki/Extended_boot_record>) is created as +partition 4, and the files starting from the 4th will appear as +partition 5 and upwards. =item B<partition-type=gpt> @@ -163,10 +158,6 @@ a Linux filesystem. =head1 LIMITS -This plugin only supports B<primary> MBR partitions, hence the limit -of 4 partitio...

An evolution of the patch I posted yesterday to qemu-devel (https://www.mail-archive.com/qemu-devel@nongnu.org/msg588920.html) which (a) works and (b) has a test. Rich.

This is a revised version of the two series previously posted here: https://www.redhat.com/archives/libguestfs/2019-January/msg00137.html https://www.redhat.com/archives/libguestfs/2019-January/msg00139.html There have been many smaller changes but the highlights are: - Using SECTOR_SIZE instead of hard-coding 512 everywhere. - Additional safety checks that the EBR chain doesn't jump