Re: Bug in EZ-Drive remapping code (ide.c)

Re: Bug in EZ-Drive remapping code (ide.c)

[Andries.Brouwer]

Jochen Hoenicke writes:

    The EZ-Drive remapping code remaps to many sectors, if they are read
    together with sector 0 in one bunch.  This is even documented:

    From linux-2.4.0/drivers/ide/ide.c line 1165:
    /* Yecch - this will shift the entire interval,
       possibly killing some innocent following sector */

Yes, I know - I added that comment.

    This problem hit a GRUB user using linux-2.4.2 but it exists for a
    long time; the remapping code is already in 2.0.xx.  The reason that
    nobody cares is probably because there are only a few programs that
    access /dev/hda directly.

    This is what happened: Grub reads the first track in one bunch and
    since a track has an odd number of sectors, linux adds the first
    sector of the next track to this bunch.  This sector contains the boot
    sector of the first FAT partition.  The result of the remapping is
    that grub can't access that partition.

What one wants is to remap access to sector 0 to sector 1,
and leave all other sectors alone. Thus, if someone asks
for sectors 0 1 2 3 4, she should get sectors 1 1 2 3 4.
Ugly, but can be done. But if someone wants to write
sectors 0 1 2 3 4 then what? Only sectors 1 2 3 4 should be
written, but what to write in sector 1? Nobody knows.
(Probably a write to 0 1 2 3 4 should discard the write to 1.)

Doing this would be a very ugly wart on the IDE driver, and
Mark Lord implemented a much smaller wart: shift transports by 1
if they start at sector 0. This was enough at that time
since only *fdisk and LILO access sector 0 and they do not
read an entire track but just one sector or one block.

So yes, the problem is known, but I do not see a clean solution,
unless the solution is to rip out all this EZ drive nonsense.
(I can well imagine that this would happen in 2.5:
the task of the IDE driver is to transport bits from and to
the disk, not to worry about the contents.)
And even if it were fixed somehow in a 2.4 kernel, lots of
people will have a 2.2 or older system for quite some time
to come. So probably grub should regard this as a quirk in
the Linux handling of disks with EZ drive and adapt
(that is, read sector 0, and then read sectors 1-N,
but do not read 0-N).

Andries

Re: Bug in EZ-Drive remapping code (ide.c)

[Jochen Hoenicke]

On Mar 30, Andries.Brouwer@cwi.nl wrote:
> So yes, the problem is known, but I do not see a clean solution,
> unless the solution is to rip out all this EZ drive nonsense.

Grub can already handle EZ drives itself so this would be a solution :)
However, fdisk depends on the remapping.

> (I can well imagine that this would happen in 2.5:
> the task of the IDE driver is to transport bits from and to
> the disk, not to worry about the contents.)
> And even if it were fixed somehow in a 2.4 kernel, lots of
> people will have a 2.2 or older system for quite some time
> to come. So probably grub should regard this as a quirk in
> the Linux handling of disks with EZ drive and adapt
> (that is, read sector 0, and then read sectors 1-N,
> but do not read 0-N).

I make a patch for grub to do that.  

  Jochen

Re: Bug in EZ-Drive remapping code (ide.c)

[Albert D. Cahalan]

Andries.Brouwer writes:

> What one wants is to remap access to sector 0 to sector 1,
> and leave all other sectors alone. Thus, if someone asks
> for sectors 0 1 2 3 4, she should get sectors 1 1 2 3 4.

No, because then you can't write to the real first sector.
Assuming translation is good, 1 0 2 3 4 is a better order.
Then "dd if=/dev/zero of=/dev/hda bs=1k count=999" will get
rid of all this crap. Otherwise, killing it is difficult.

> So yes, the problem is known, but I do not see a clean solution,
> unless the solution is to rip out all this EZ drive nonsense.

Linux should still be able to read the partition table.
The translation can go.

Re: Bug in EZ-Drive remapping code (ide.c)

[Albert D. Cahalan]

Andries.Brouwer writes:
>From acahalan@saturn.cs.uml.edu Mon Apr 16 08:35:09 2001
>>Andries.Brouwer writes:

>>> What one wants is to remap access to sector 0 to sector 1,
>>> and leave all other sectors alone. Thus, if someone asks
>>> for sectors 0 1 2 3 4, she should get sectors 1 1 2 3 4.
>>
>> No, because then you can't write to the real first sector.
>> Assuming translation is good, 1 0 2 3 4 is a better order.
>> Then "dd if=/dev/zero of=/dev/hda bs=1k count=999" will get
>> rid of all this crap. Otherwise, killing it is difficult.
>
> If you use EZdrive and damage its code, then probably you
> cannot boot anymore, or lose access to your data.
> Killing it must be difficult.

The above dd command wipes out out the partition table anyway,
with or without EZdrive. I think it also kills the EZdrive code.

EZdrive tends to come installed by default, to support DOS and
similar crufty Microsoft bits. For a pure Linux system it should
be removed.

What you are arguing for is protecting root from himself.
You want to limit the rope, but this is silly as the partitions
themselves are still completely unprotected.

The "1 0 2 3 4" order is nicely 1-to-1, unlike the other orders.

> EZdrive provides uninstall code itself, but if you really want,
> boot with "hda=noremap", and then your dd command will erase
> both EZdrive and your precious data.

This is a pain. The fdisk program ought to have a "wipe EZdisk"
option. More generally, it ought to let the user wipe everything
of a similar nature, by both brute force and by copying the second
sector over the first.

Re: Bug in EZ-Drive remapping code (ide.c)

[Andries.Brouwer]

    From acahalan@saturn.cs.uml.edu Mon Apr 16 08:35:09 2001

    Andries.Brouwer writes:

    > What one wants is to remap access to sector 0 to sector 1,
    > and leave all other sectors alone. Thus, if someone asks
    > for sectors 0 1 2 3 4, she should get sectors 1 1 2 3 4.

    No, because then you can't write to the real first sector.
    Assuming translation is good, 1 0 2 3 4 is a better order.
    Then "dd if=/dev/zero of=/dev/hda bs=1k count=999" will get
    rid of all this crap. Otherwise, killing it is difficult.

If you use EZdrive and damage its code, then probably you
cannot boot anymore, or lose access to your data.
Killing it must be difficult.

EZdrive provides uninstall code itself, but if you really want,
boot with "hda=noremap", and then your dd command will erase
both EZdrive and your precious data.

Andries

Re: Bug in EZ-Drive remapping code (ide.c)

[Andre Hedrick]

Jochen,

I don't really care about Disk Overlays.
However if you can fix it or if Andries can great.

Sorry,

On Fri, 30 Mar 2001, Jochen Hoenicke wrote:

> Hello,
> 
> The EZ-Drive remapping code remaps to many sectors, if they are read
> together with sector 0 in one bunch.  This is even documented:
> 
> >From linux-2.4.0/drivers/ide/ide.c line 1165:
> /* Yecch - this will shift the entire interval,
>    possibly killing some innocent following sector */
> 
> This problem hit a GRUB user using linux-2.4.2 but it exists for a
> long time; the remapping code is already in 2.0.xx.  The reason that
> nobody cares is probably because there are only a few programs that
> access /dev/hda directly.
> 
> GRUB is a boot loader that normally runs under plain BIOS but there is
> also a wrapper to run it under linux and other unixes.  Because it
> shares most code with its BIOS derivate it accesses the disk the hard
> way, reading directly from /dev/hda and interpreting the file system
> with its own (read-only) file system drivers.
> 
> This is what happened: Grub reads the first track in one bunch and
> since a track has an odd number of sectors, linux adds the first
> sector of the next track to this bunch.  This sector contains the boot
> sector of the first FAT partition.  The result of the remapping is
> that grub can't access that partition.
> 
> Please CC me on reply.
> 
>   Jochen
> 

Andre Hedrick
Linux ATA Development

Bug in EZ-Drive remapping code (ide.c)

[Jochen Hoenicke]

Hello,

The EZ-Drive remapping code remaps to many sectors, if they are read
together with sector 0 in one bunch.  This is even documented:

>From linux-2.4.0/drivers/ide/ide.c line 1165:
/* Yecch - this will shift the entire interval,
   possibly killing some innocent following sector */

This problem hit a GRUB user using linux-2.4.2 but it exists for a
long time; the remapping code is already in 2.0.xx.  The reason that
nobody cares is probably because there are only a few programs that
access /dev/hda directly.

GRUB is a boot loader that normally runs under plain BIOS but there is
also a wrapper to run it under linux and other unixes.  Because it
shares most code with its BIOS derivate it accesses the disk the hard
way, reading directly from /dev/hda and interpreting the file system
with its own (read-only) file system drivers.

This is what happened: Grub reads the first track in one bunch and
since a track has an odd number of sectors, linux adds the first
sector of the next track to this bunch.  This sector contains the boot
sector of the first FAT partition.  The result of the remapping is
that grub can't access that partition.

Please CC me on reply.

  Jochen