On 06.10.2023 21:33, Glenn Washburn wrote:
This gives me more confidence in using 127, although its not clear to me without digging in the syslinux code that 127 is actually being used as the transfer size (or when it is). It appears to be a hard max transfer, which means the actual transfer size could be lower. In this series, we're using 127 as the transfer size always. So questions that would help clear that up are: where does MaxTransfer ultimately come from and when can it be less than 127? How is disk.maxtransfer used and when does it not represent the actual transfer size.
I haven't studied syslinux code deeply, but it seems they have a fallback code which decreases reading sector number on failures if larger reads were unsuccessful.
GRUB just falls back to CHS reading if int13_extensions read failed. I've checked with seabios debugging capabilities in qemu. disk_op d=0x000f3a20 lba=6544 buf=0x00010000 count=127 cmd=2 disk_op d=0x000f3a20 lba=6671 buf=0x00010000 count=127 cmd=2 disk_op d=0x000f3a20 lba=6798 buf=0x00010000 count=127 cmd=2 disk_op d=0x000f3a20 lba=6925 buf=0x00010000 count=127 cmd=2 disk_op d=0x000f3a20 lba=7052 buf=0x00010000 count=127 cmd=2 disk_op d=0x000f3a20 lba=7179 buf=0x00010000 count=127 cmd=2 disk_op d=0x000f3a20 lba=7306 buf=0x00010000 count=127 cmd=2 disk_op d=0x000f3a20 lba=7433 buf=0x00010000 count=127 cmd=2
Ok, this lends more weight to not taking those values too seriously then. Do you have an explanation of how you got an MBR with sectors == 2? I would have a hard time believing that debian would produce that.
That was just a regular automatic Debian installation in a VM on a 8GB disk size.
Check the thread https://lists.debian.org/debian-boot/2023/07/msg00043.html
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
