Re: [PATCH] biosdisk / open_device() messing up offsets

[Bean]

On Sat, Jun 7, 2008 at 2:33 PM, Pavel Roskin <address@hidden> wrote:
> Quoting Robert Millan <address@hidden>:
>
>> If not, then we'd have
>> to figure out why sector 0 of the partition can be accessed directly via
>> hexdump.
>
> As I understand, "(hd0,1)" doesn't refer to an extent of data, i.e. it not a
> file or a block list that can be opened like a file.  "(hd0,1)+1" is the
> first sector of the partition.  But "(hd0,1)" is not all sectors of the
> partition.  It the partition name.  It can be used in the "ls" command,
> whereas "(hd0,1)+1" cannot.
>
>>> By the way, the current GRUB just failed to install on my test system.
>>> After I rebooted it, GRUB hung on startup after showing "GRUB".
>>
>> Please run a regression test, if you can.
>
> The installation was broken by that patch, so I reverted it.  It's easy to
> check the installation by doing it on a mounted flash drive, so that the
> real boot device is not at risk.

Hi,

I believe the problem is with hexdump. It open the device with
grub_disk_open, which returns the disk object related to the beginning
of partition. However, it read it using disk->dev->read, which is a
low level api that use absolute address. It should be using
grub_disk_read instead.

BTW, I also find an ingesting situation when writing the load_env
command. The read hook return absolute address, so grub_disk_read
would not work. In that case, we have to use the low level
disk->dev->read.

-- 
Bean