unless I am terribly wrong, you have a physical problem with your hd. You get an I/O error which means that the hd could not read the sector containing the partition table. I can imagine two reasons: 1) you changed the BIOS settings for LBA access and the like [in this case: undo the changes and re-try] 2) a block on your hd went bad after the last boot. [in this case: prepare yourself for a lot of work...] IMHO, lilo has nothing to do with that.
You could try & run badblocks on /dev/hda from a rescue system to check for bad blocks (this will NOT change anything on your hd).
badblocks -b512 -o /test /dev/hda 1000
gave me: 0 This is the problem, as I guessed. Blocks 0 and 1 went bad and as these have to be read to get the partition table, you're in trouble. 1 130 131
cannot access my manpages at the moment (as you know...hmmm) so what does that tell me?
This tells you that blocks 0,1,130 and 131 are bad blocks (physical problem; drive cannot read them any more).
If you know the byte offset of your partitions on hda, you could try and copy the partitions to image files on another hd by issuing
dd if=/dev/hda of=imagefile skip=OFF bs=512 count=N
OFF: partition offset in 512b blocks from beginning of hda This will skip the bad block at the beginning of the hd. N: size of partition in 512b blocks (a too big value does not do any harm here but a too small one is bad) [A quick test on my box showed that skip=63 for hda1 for my hd.]
how2 calculate that skip value?
A wizard is able to calculate it from fdisk output (partition table data). As we do not have it, you may try some reasonable values.
THIS IS THE SOLUTION!!!!!!
I TRIED IT! I CAN ***ONLY*** VIA THIS WAY ACCESS THE DRIVE!!!!
i just tried for a start dd if=/dev/hda of=/image skip=1024 bs=512 count=xxx
Try with skip=63. It`s worth an attempt.
and guess what? i have now been able to read the autoexec.bat of my there existing dos paartition.
now, i plan to entirely evacuate all the data of the 4 partitions which still ARE there on hda.
WHERE exactly does the data of the partition start on the drive?
Well... You need the start of the filesystem on /dev/hda1, /dev/hda2, etc. First, remember your swap device becuase you will certainly not want to evacuate swap. Then, to get a disk image of /dev/hda1, try dd if=/dev/hda of=image_not_on_hda skip=63 bs=512 count=SZ with SZ being at least the size of the hda1 partition (size in 512byte blocks). To save hda2, you have to use a larger skip value (should be around the offset where hda1 ends, i.e. 63+SZ, but note that you have to get the exact value (worst case by try & error) so that each image file starts exactly at filesystem start. It sounds reasonable to me that this is always on a 512 byte boundary, but I'm not sure.) [But for now, forget saving your partitions and calculating offset values, I recommend saving the whole hd on an image file first, see below for my proposal.]
if i run using skip=63 with count=100 i get an i/o error and only 67 records copied.
Yes. This is probably due to read failure accessing block 130 which is also bad (check kernel logs on /dev/tty10). You need a self-hacked tool. I wrote such a thingy to get data off corrupt floppies (hehe) and I may send it to you (see below).
so it seems that a bit of the beginning of my valuable hda1 is damaged (test: 100-67=33*512 bytes lost ###IS THAT RIGHT?###)
According to badblocks only 4 blocks are lost. This can pose problems when you try and mount the image files because the filesystem may have got corrupt. Try reiserfscheck or e2fsck on the image files in that case. And, ALWAYS mount the image files read-only (losetup /dev/loop0 image ; mount /dev/loop0 /mnt/ -o ro). [But again, I recommend saving the complete hd first, see below.]
this question is about the SKIP= value which i shall enter. next, can you go into detail for the above "N" value (count=N) i tried with 63 but am unsure about it.
Count is the number of 512 byte blocks that shall be copied. If you copy hda1 and hda1 has 1Gb, enter 1Gb/512b = 2097152.
next is: i cannot find that damn piece of paper. i have now for 3 hrs been searching my whole appartement. it is gone :-(((( i have yet a file on /dev/hda..... shit :-)))
so what other ways are there?
1) Try & error 2) Finding filesystem magics or superblock patterns on /dev/hda. The filesystem start is near these locations. Sorry, I don't know these magics and searching a block device with bad blocks will likely require a hand-coded tool, too. Okay, if your data is really important, the best thing is probably to copy the complete content of /dev/hda to an image file on a different hd (the free space must be larger than the size of hda). Do you have such a drive? In this case, I'll send you a small copy tool to save your hda's data replacing all bad blocks with zero blocks on the copy. Using this image file should make further data recovery less dangerous. (You do not modify hda, even by accident, you don't get these IO errors each time you hit a bad block, etc.) Hope we'll get your data, Wolly