We have a new boot log at
http://ludenkalle.de/ide_change_kernel.txt
With CONFIG_BLK_DEV_IDEDISK=y but unset CONFIG_BLK_DEV_HD_IDE and the
inserted (and no used) printk stuff.
Regards, Konsti
--
2.6.0-test8-love3
Konstantin Kletschke <[email protected]>, <[email protected]>
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E A080 1E69 3FDA EF62 FCEF
keulator.homelinux.org up 1:01, 13 users
On Mon, Nov 10, 2003 at 11:24:44AM +0100, Konstantin Kletschke wrote:
> We have a new boot log at
>
> http://ludenkalle.de/ide_change_kernel.txt
>
> With CONFIG_BLK_DEV_IDEDISK=y but unset CONFIG_BLK_DEV_HD_IDE and the
> inserted (and no used) printk stuff.
Good. Now it really does partition reading.
At some later time we must come back and find out what is
wrong with hd.c. You call the printk stuff unused, but
it was used and printed
partition start 63 size 4096512 type 85 p1
partition start 4096575 size 15904350 type 85 p2
partition start 0 size 0 type 0
partition start 0 size 0 type 0
Let us compare with your data from earlier:
Device Boot Start End Blocks Id System
/dev/hda1 * 1 365 2931831 83 Linux
/dev/hda2 366 1245 7068600 5 Extended
/dev/hda5 366 487 979933+ 83 Linux
/dev/hda6 1185 1245 489951 82 Linux swap
Clearly, you have EZDrive installed, the table below is what
is found in sector 1, the data printed above is what is in
sector 0. The tables differ - fdisk was used after installation
of EZDrive.
I suppose that booting with boot parameter "hda=remap" should work.
At some later time we must worry about how to get rid of EZDrive.
Andries
On Mon, Nov 10, 2003 at 11:56:50AM +0100, Andries Brouwer wrote:
> >
> > With CONFIG_BLK_DEV_IDEDISK=y but unset CONFIG_BLK_DEV_HD_IDE and the
> > inserted (and no used) printk stuff.
>
> At some later time we must come back and find out what is
> wrong with hd.c. You call the printk stuff unused, but
> it was used and printed
It was unused earlier, now, with CONFIG_BLK_DEV_IDEDISK=y but _unset_
CONFIG_BLK_DEV_HD_IDE it gets printed (to clear that).
> Clearly, you have EZDrive installed, the table below is what
> is found in sector 1, the data printed above is what is in
> sector 0. The tables differ - fdisk was used after installation
> of EZDrive.
Hm, interesting... I don't know what was on this disk in earlier days...
So it may be a help dd'ing Sektor 0 and 1 and create new table?
But of course after debugging that if you are interesting in that (which
seems to be the case here :)).
Here is what 2.6.0-test6-mm4 looks like when booting (wo printk mod):
http://ludenkalle.de/2.6.0-test6-mm4.txt
> I suppose that booting with boot parameter "hda=remap" should work.
> At some later time we must worry about how to get rid of EZDrive.
OK, lets see...
Konsti
--
2.6.0-test8-love3
Konstantin Kletschke <[email protected]>, <[email protected]>
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E A080 1E69 3FDA EF62 FCEF
keulator.homelinux.org up 2:00, 18 users
On Mon, Nov 10, 2003 at 11:56:50AM +0100, Andries Brouwer wrote:
>
> I suppose that booting with boot parameter "hda=remap" should work.
Seems so...
http://ludenkalle.de/2.6.0-test6-mm4-remap.txt
Konsti
--
2.6.0-test8-love3
Konstantin Kletschke <[email protected]>, <[email protected]>
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E A080 1E69 3FDA EF62 FCEF
keulator.homelinux.org up 2:35, 19 users
>> I suppose that booting with boot parameter "hda=remap" should work.
> Seems so...
Good. So there were two problems. One was devfs+hd.c, caused by
the fact that hd.c fails to set devfs_name. And the second was
EZDrive, solved by booting with "hda=remap".
Probably it is a good idea to warn when we see EZD or DM.
A minimal patch would be
--- 2.6.0test9/linux/fs/partitions/msdos.c Fri May 30 18:12:57 2003
+++ fs/partitions/msdos.c Mon Nov 10 16:20:11 2003
@@ -425,6 +425,10 @@
put_partition(state, slot, start, size);
if (SYS_IND(p) == LINUX_RAID_PARTITION)
state->parts[slot].flags = 1;
+ if (SYS_IND(p) == DM6_PARTITION)
+ printk("[DM]");
+ if (SYS_IND(p) == EZD_PARTITION)
+ printk("[EZD]");
}
printk("\n");
The next project for you is getting rid of EZD (if you want).
Backup valuable stuff.
Boot a kernel that remaps, say vanilla 2.4.
Print partition table (in sector units) on paper.
sfdisk -d /dev/hda > hda.pt
gives the full table in a format that sfdisk can restore.
dd if=/dev/hda of=hdapt bs=1 count=64 skip=446
gives the primary part of the table in binary.
dd if=/dev/hda of=hdambr bs=512 count=1
gives the entire fake sector 0 (that is, sector 1).
Save the output files somewhere not on hda.
Now boot a kernel that does not remap. Since you won't see
your root filesystem on hda, this should probably be from
a rescue floppy or CD. Recent kernels understand the "hda=noremap"
boot parameter. Make sure no remap is done (e.g., *fdisk
mentions partitions of type 55). Now write the desired partition
table (e.g.
dd if=hdapt of=/dev/hda bs=1 count=64 seek=446
or
dd if=hdambr of=/dev/hda
or
sfdisk /dev/hda < hda.pt
).
That should do it, but be careful that you can boot again afterwards.
Sector 0 has the partition table in bytes 446-509,
a signature in bytes 510-511, and a boot loader in bytes 0-445.
You may have to reinstall LILO or grub or so. In some cases
copying the entire sector 1 to sector 0 will suffice.
Good luck!
Andries
On Mon, Nov 10, 2003 at 05:02:36PM +0100, [email protected] wrote:
>
> Boot a kernel that remaps, say vanilla 2.4.
[...]
> Now boot a kernel that does not remap. Since you won't see
[...]
All this rebooting into kernels that DO or DON'T remap would have been
unneccesary if the remapping would not have cloned block 1 to appear
in block 0, but would just have swapped them.
In remapped mode, you now read block 1 wether you seek to block 0 or 1.
If the remapping would have swapped them, just copying over the block
from block 1 to block 0 would have allowed the removal of the stupid
remapping.
ide.c:1381
/* Yecch - this will shift the entire interval,
possibly killing some innocent following sector */
if (block == 0 && drive->remap_0_to_1 == 1)
block = 1; /* redirect MBR access to EZ-Drive partn table */
should have been:
if ((block <= 1) && drive->remap_0_to_1)
block ^= 1;
(IMHO, it's not worth going in and fixing this for say 2.4 or 2.6
kernels(*), but it IS worth noting and not making the same mistake again in
the future.....)
Roger.
(*) For example because that would change established behaviour which is
bad and can lead to surprises. If we'd change it, Andries' "how to fix"
emails would become even longer: He'd have to start: IF you have a
modern kernel, you can just ... but otherwise you'll have to .... and
then comes the whole mess I didn't fully quote.....
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
**** "Linux is like a wigwam - no windows, no gates, apache inside!" ****