Closed boeckmann closed 11 months ago
I will revisit the forcelba logic. from my phone the changes looked good, but I will look better tonight. I had to force LBA access for testing as my VirtualBox BIOS was failing the check and reverting to CHS for my 2TB fake drive although it works fine to access using LBA. I have a different branch where I am reworking initdisk with GPT support, I just didn't want to bring over too many changes as I want to get 2044 release out then work on a 2045 with GPT support shortly after. Thanks for reviewing the changes!
I had to force LBA access for testing as my VirtualBox BIOS was failing the check and reverting to CHS for my 2TB fake drive although it works fine to access using LBA.
Well, that is interesting! Now I see what you wanted to achieve, basically forcing LBA even if the BIOS says it does not support it. Do you know where exactly this check failed, the INT13,41 or INT 13,48 call?
Hey Jeremy,
I had a look at the recent changes and found some places where I am not sure that it is correct. For instance, I think
ExtLBAForce
originally was meant to force LBA access for partitions contained inside an extended partition of type LBA (0x0E).ExtLBAForce is now set in
LBA_Get_Drive_Parameters
toInitKernelConfig.ForceLBA
. I understand you somewhat wanted to force the use of LBA (it is not clear to me in what case exactly), but settingExtLBAForce
inLBA_Get_Drive_Parameters
is in my opinion a) the wrong variable and b) the wrong place for it.I relocated the
ExtLBAForce
setting toProcessDisk
, setting it initially to zero. I think this is the right layer of abstraction for it.LBA_Get_Drive_Parameters
should only do what it is named after: getting drive parameters. Otherwise it is getting even more confusing.In this merge request I also restrict the disk size to 2TB. It was modulo 2TB before, leading to a 3TB disk becoming a 1TB disk.
It also includes other minor changes (should be reviewed).
Greetings, Bernd