Anne BezemerJ.A. Bezemer wrote:
On Thu, 17 Nov 2011, John D. Hendrickson and Sara Darnell wrote:
I have 2 "large" WD hardisks both have EZ-DRIVE installed. lk 2.6.10
series hacked support by checking for it. Linux version 2.6.38-k7
(root@xyxy) (gcc version 3.3.5 (Debian 1:3.3.5-13)) has removed checking
# from 2.6.10
/* 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
due to "complete re-organization" of bsd / scsi (blocking, paging, hw
drivers doing the same, etc) in 2.6.38 ? they deleted the support.
I am being "force upgraded" to use the new firefox which says my libs
are too old to upgrade (again!)
I don't have a backup drive large enough: the drives are made as
backups of each other !
Question. anybody have advice on EZ-DRIVE in lk 2.6.38 series ? Any
I'm afraid if I just dd(1) all the data one block my partition tables
headers and supers will be all messed up. all supers and inodes would
be off by 1 i think.
#1) grub is no good - it's how the linux-ms-dos driver reads
partitions that is blocking dependant
#2) the ms-dos partition driver uses the block number, but the
blocking code doesn't know for sure (circular dependancy, this is
likely why EZ drive support was hacked out and lost)
If I hack /usr/src/linux/fs/partitions/osf.c so I am free of ms-dos
partition mayhem which causes the need ...
--> osf.c isn't complete <--
--> was provided as read-only support of certain unix partitions <--
--> only write code for MS-DOS partitions is avail ?? <--
I wanna return the dang drives with a thank-you note (ha!) Can't.
What junk IDE and BIOS is. scsi never gives me these problems, ide
always a new issue every board and kernel
If no one has heard of any EZ suport or way around it? Guess I have
days of copying todos and drive changing and what !
No idea what EZ does, but I have previously used
losetup -o NNN /dev/loopX /dev/hdY
to get a pseudo-partition starting at some weird number of bytes into
the real device. The /dev/loopX then mounted effortlessly. Maybe this
could be a workaround? (Don't know about performance though.)
If booting itself is a problem, maybe it's an option to boot from USB
stick and do the losetup trick inside the initrd. USB stick can be
removed once booted.
If I find or calculate all the offsets of each of the many and mixed partitions on each disk, yes.
losetup -o 32256 $loopdev /dev/hda
mount $loopdev /tmp/tmp2 -t msdos
(per partition, per disk, i can hack a linuxrc with it all)
This works? Yes. It isn't (and can't) using ms-dos to programatically determine partition location
using [bios/lba/all that bull that never worked as it should have].
I'm almost tempted! To NEVER use BIOS, IDE, FDISK again. By hand may be easier! If only every
boot image knew need supply such offsets. For maintenance will it be harder or easier down the
road? tftp boot ... need special images ... Easier if only supported I guess.
(i was thinking of creating osf partiion block by hand - no osf able fdisk)
Thanks Anne! I JUST realized. If mount can mount the EXT2 filesystem without any partition table
then that means the super and inodes are relatively indexed, not physically indexed: safely moved
with dd(1). I thought finding out _for_sure would be difficult. Why wasn't I thinking? Easy.
I already tried it but forgot: old mbr is dependant on EZ already. Thus I got an error.
I need a new mbr installed correctly after I move all drive data and re-create the partition table -
or hand fix the current linux one. So I gotta be real careful if I don't have a backup! Exactly
Or maybe I should just do it the "safe" way. (backing up & deleting orig. is not always safe)
Anyway thanks allot Anne. If there's any single women in .nl as cute as you I hope I get to meet
I wanna make Maxtor, IDE, BIOS, et al eat the damn drives. I never did one purchase (board, drive,
OS) or upgrade without problems they promised were fixed: always new problems waiting to blow loads
of my time and risk data loss.
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org