Re: Bug in EZ-Drive remapping code (ide.c)
Andries.Brouwer writes: >From [EMAIL PROTECTED] 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bug in EZ-Drive remapping code (ide.c)
From [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bug in EZ-Drive remapping code (ide.c)
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bug in EZ-Drive remapping code (ide.c)
On Mar 30, [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bug in EZ-Drive remapping code (ide.c)
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bug in EZ-Drive remapping code (ide.c)
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Bug in EZ-Drive remapping code (ide.c)
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
