Re: [Wlug] Partition table blues
Hi Doug, I tried fdisk /mbr and it worked easily. As expected, I only have a windows partition (verified by fdisk). I suspect that I'm less than halfway there.
It came from ms. Maybe they're just playin' with our heads.
No, there's no lilo.conf and never was one on that installation. There is (was) a grub/menu.lst, which serves the same function, but as far as I understand it, the partition table needs to contain information about linux partitions for either of these to work. I went ahead and booted the rescue system and tried a grub-install /dev/hda, and it returned a message saying that no /dev/root was found. Maybe I'll try parted again, now that I can find where hda1 ends. Thanks, Greg
Hi again Gregory Avedissian wrote:
I'm glad you finally tried that! At least the easy part is taken care of so you can now focus on a smaller problem. I admit to some guessing here, but I would suggest you try both the Windows fdisk (just because I am a bit anal; I don't expect it to know about the linux partitions) and the Linux fdisk. (You may have done this but I can't tell since you say just "fdisk".)
Oops! Sorry about that; I misread an earlier email. :-(
I suspect that is true (can't recall off hand). If so, then remember to pray when you run the Linux fdisk! :- And do run the linux fdisk, i.e. fdisk /dev/hda and then chose option p (as in *P*rint the partition table. If you get a nice listing, then don't screw around with parted!
But do try both Windows fdisk and Linux fdisk (with the P option) first! doug
Doug, That was linux fdisk I was talking about. It only shows the windows partition. sfdisk -l shows four partitions - one windows, and three empty ones, with no start or end cylinders. I'm not sure what that's about. Here's the output for fdisk and sfdisk when that drive is hooked up as slave: fdisk -l Device Boot Start End Blocks Id System /dev/hdb1 * 1 1123 9020466 c Win95 FAT32 (LBA) sfdisk -l Disk /dev/hdb: 1123 cylinders, 255 heads, 63 sectors/track Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls #blocks Id System /dev/hdb1 * 0+ 1122 1123- 9020466 c Win95 FAT32 (LBA) /dev/hdb2 0 - 0 0 0 Empty /dev/hdb3 0 - 0 0 0 Empty /dev/hdb4 0 - 0 0 0 Empty Here's what I tried. I went into yast2 partitioning tool, setup the drive the way I did the first time, wrote down the cylinder numbers, then hit ABORT, so it wouldn't write to the disk. Then ran "parted -i /dev/hdb", then used the cylinder numbers for the "rescue partitions near START and END" function. It scanned, returned no errors, and made no changes. I don't get it, and I'm out of ideas for now. OK, one more idea. Can I use the partition tool to set the partitions again without formatting them, and then be able to access them? Thanks for all your help, Greg doug waud wrote:
On Sun, Jul 25, 2004 at 10:34:39PM -0400, Gregory Avedissian wrote:
There are always 4 primary partition entries in the partition table in first sector of the drive (MBR). The unused ones are filled with zeros.
Disk /dev/hdb: 1123 cylinders, 255 heads, 63 sectors/track
That equals 18040995 sectors of 512 bytes/each = 9,236,989,440 bytes total.
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0
Taking the blocks as 1024 bytes, thats 9020497.5 blocks.
Device Boot Start End #cyls #blocks Id System /dev/hdb1 * 0+ 1122 1123- 9020466 c Win95 FAT32 (LBA)
The Win95 partition is just about the entire disk, leaving only 31.5 1024-byte blocks left = 32,256 bytes. Where could any Linux partitions have fit?
OK, one more idea. Can I use the partition tool to set the partitions again without formatting them, and then be able to access them?
If you are absolutely sure of the correct start/end of all the partitions on the disk, then yes, you should be able to re-set them in the partition table and regain access to the data without formatting them. This is much more likely to happen if there are no extended partitions (hdb5 or higher). What happened to make Windows take over the entire disk? Are you sure /dev/hdb is still /dev/hdb, and didn't change due to a disk failure or recabling of the IDE bus? Is Windows 98 installed to /dev/hdb1? It is highly unusual to have Windows boot from anything other than /dev/hdaN.
Thanks, Charles. I was afraid that hdb designation would be confusing. That's just temporary, so I can do things to that drive from a working linux intall on another disk. I've got three drives within reach of the IDE cables, and I keep switching cables and jumpers to do all this. The disk in question is around 30GB, and originally, 6 GB were taken by windows on hda1, 1GB by swap on hda2, 8GB for hda3, and 10GB for hda5, leaving 3.7GB unallocated space in the extended partition. I did this by making the win partition with the win98 fdisk, and then making the linux partitions with the suse intall disk. It looks like the numbers aren't adding up right.
On the other 24GB which appear not to be partitioned. I'm a little bothered by the math, though. You came up with 9GB, and I made that partition 6GB.
No, I'm not sure, just assuming that if I use the same partition tool with the same drive, it'll come up with the same numbers. Guess I need to double-check the size of my win partition and make sure it hasn't changed. In fact, I seem to recall noticing that hda1 ended well below cyl 1023 when I set it up. At 8225280 bytes/cylinder, 6GB should end at cyl 750, not 1125. The partition tool shows the end of hda1 at 1023, and the end of hda2 at 1154. Uh-oh. I better sleep on it before I do anything else. Maybe parted didn't work because I gave it the wrong numbers? Thanks, Greg
Hi again Greg Gregory Avedissian wrote:
Now why did you not let us know that right from the start!? In particular, your second post had lines like
all of which referred to /dev/hda! It is hard to tell without mind-reading exactly what you did. Do you see why you *must* tell us *exactly* what you did/are doing. There is no way we can guess that you moved the drive from /dev/hda to /dev/hdb (and god-knows-what-else!). In turn, if we are assuming the /dev/hda you reported is correct, we stand a good chance of telling you to do something which could be a disaster if it is mounted as /dev/hdb. Now I hope you can see why I kept harping on telling us *what* you did rather than what you *think* you did.
Yes! You claim it is a 30 gig disk and, as Chuck points out, it is coming out about 9. Note that this is even before you get into the details of partitions. At this point I have not the slightest idea of where we are, especially since you have been swapping drives in god-knows-what order and fdisk /mbr on again an unknown (to us) drive.
See comments above, the summary for /dev/hdb *total* says there are not another 24 GB!
You *think* you did. It would appear the fact is that you really do not know what you did!
Chuck, you are more optimistic than I! :-) I think that right now we are flying blind. Also, he now refers to a /dev/hd5 and and extended partition, so the cards would appear to be stacked even more solidly against him.
Now, once again, that comes out of the blue (unless I lost something in all this long exchange). You just give the numbers in your edited version rather than tell us *exactly* what you did and then show us *exactly* what came out.
I better sleep on it before I do anything else.
As I indicated earlier, prayer might be more effective!
Maybe parted didn't work because I gave it the wrong numbers?
That "it' says a lot! Yes, wrong numbers is one of a zillion (and climbing) possibilities. doug
On Mon, Jul 26, 2004 at 12:55:36AM -0400, Gregory Avedissian wrote:
Ok, you need to stop right here and find out why fdisk thinks the disk is only 9GB before doing anything else. I can think of one reason. The MBR also stores C/H/S values. Normally, C*H*S*512 on the MBR should match the disk capacity. Since yours doesn't appear to, perhaps you overwrote the MBR C/H/S values when you restored the copy you had in /boot. Did you perhaps make that backup from a different sized disk? Linux 2.4 will trust the MBR values over the BIOS values. Linux 2.6 trusts the BIOS over the MBR (leading to the aforementioned Windows interop problem after installing a Linux 2.6 distro). What does the kernel think the disk size is on bootup? dmesg | grep hdb What does the BIOS say in the CMOS setup screen for the disk geometry? What does the disk say on the label for the geometry?
Charles R. Anderson wrote:
I'm sure I made the backups from the right disk. This was about a week ago when I installed this drive, and it was the only harddrive in the machine at the time. Once I got everything installed and working, I made the backups with debug and in linux with dd. I have noticed on several previous linux installations that disk geometry reported by linux is accompanied by messages that say something like "this is not the geometry we expected." I always have ignored those messages, because everything was working. I thought that was normal, but if I'm doing something consistently wrong on installation, I'd like to know about it.
What does the BIOS say in the CMOS setup screen for the disk geometry?
capacity 30740 MB cylinder 59560 head 16 precomp 0 landing zone 59559 sector 63
What does the disk say on the label for the geometry?
Model: DTLA-307030 Capacity: 30.7 GB LBA 60.036.480 sectors CHS: 16383/16/63 MLC: F80033 And here's more: DOS fdisk reports the partition as being 8032 MB. Win98 reports it (C:) as 5.8 GB. gnu parted reports it as: (note that the drive is temporarily connected as hdb for convenience) ide0: BM-DMA at 0xc000-0xc007, BIOS settings: hda:DMA, hdb:DMA hdb: IBM-DTLA-307030, ATA DISK drive hdb: attached ide-disk driver. hdb: host protected area => 1 hdb: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=3737/255/63, UDMA(100) hdb: hdb1 and here are the fdisk and sfdisk outputs again for reference: fdisk -l Device Boot Start End Blocks Id System /dev/hdb1 * 1 1123 9020466 c Win95 FAT32 (LBA) sfdisk -l Disk /dev/hdb: 1123 cylinders, 255 heads, 63 sectors/track Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls #blocks Id System /dev/hdb1 * 0+ 1122 1123- 9020466 c Win95 FAT32 (LBA) /dev/hdb2 0 - 0 0 0 Empty /dev/hdb3 0 - 0 0 0 Empty /dev/hdb4 0 - 0 0 0 Empty
Brian, Here's the info you asked for. I'll be busy reading for awhile. Greg kervnel version 2.4.20-4GB-athlon sfdisk -H 63 -l Disk /dev/hdb: 3737 cylinders, 63 heads, 63 sectors/track Warning: The partition table looks like it was made for C/H/S=*/255/63 (instead of 3737/63/63). For this listing I'll assume that geometry. Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls #blocks Id System /dev/hdb1 * 0+ 1023 1024- 8225248+ c Win95 FAT32 (LBA) /dev/hdb2 0 - 0 0 0 Empty /dev/hdb3 0 - 0 0 0 Empty /dev/hdb4 0 - 0 0 0 Empty Brian Waite wrote:
On Mon, Jul 26, 2004 at 02:27:01PM -0400, Gregory Avedissian wrote:
What does the kernel think the disk size is on bootup? hdb: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=3737/255/63, UDMA(100)
The BIOS and kernel agree on the size of the disk. 59560/(255/16) = 3737 cylinders. I would however make sure the BIOS is set to LBA mode if it isn't, which should cause the heads to become 255.
Strange. That doesn't add up at all. Ah, here it is: "There is an industry convention to give C/H/S=16383/16/63 for disks larger than 8.4 GB" [1]
Interesting.
Agrees with the kernel above.
Here is the problem. sfdisk is seeing the wrong number geometry. I would attempt to fix the C/H/S values in the partition table with sfdisk. First I would read [1] in it's entirety--it goes into all the gory details of geometry and size limits. Here are some useful documents on geometry and partitioning: [1] http://www.tldp.org/HOWTO/Large-Disk-HOWTO.html [2] http://www.microsoft.com/windows2000/techinfo/reskit/en-us/default.asp?url=/... [3] http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us...
Here's the update: Went into BIOS and set the disk to LBA. This resulted in sfdisk -l showing the same geometry as the kernel (CHS 3737/255/63) This put the start and end of the first partition at 0 and 1023. Somewhere along the line, my windows partition grew by 2GB. Is it possible that it's reading a previous partition table? Win98 was still showing c: to be 5.8GB, and dos fdisk was still showing it as 8.2 GB. So, I took Doug's advice and said a prayer, then went at it. Set the win partition back to 6GB with dos (win98) fdisk (with the drive hooked up as master.) This made windows unbootable, and fdisk /mbr didn't correct it. That's ok. I did have it working again until then, and I could have retrieved my data if I'd had any on that partition. Connected the drive as slave and put another drive I had with a non-critical linux installation on as hda (in case I screwed up and partitioned the wrong drive). Booted into linux and repartitioned with sfdisk /dev/hdb, putting in parameters for <start cylinder> <size in cylinders> <type> for each partition when promted: /dev/hdb1 0 765 c * /dev/hdb2 765 130 82 /dev/hdb3 896 1044 (L for linux is the default) /dev/hdb4 1941 1795 (tried both 85 for linux extended and 5 for win extended) /dev/hdb5 1941 1305 L /dev/hdb6 - it insisted on setting up hdb6, so I just hit enter, and let it take the rest of the disk. This was originally unpartitioned space. I then was able to mount /dev/hdb3 and access my root filesystem. I was not able to mount /dev/hdb5 to access my /home partition. Error message from mount was "wrong filesystem type or too many mounted filesystems). Unless someone knows the secret code to to mount a recovered logical partition, I'll assume that there's no easy way to do it and finish this project (i.e. wipe the disk and start over, without putting windows on this drive.) No more extended partitions for this boy. On a brighter note, I learned how to get windows98 to boot from the SECOND hard drive, and that gives me great satisfaction. It was way easier than I thought, and if anyone's interested, I'll give details. This means that when I figure out how to watch movies on dvd in linux, I can get rid of windows by simply removing the second drive. Thanks to all for your help with this. Greg Charles R. Anderson wrote:
participants (5)
-
Brian Waite
-
Charles R. Anderson
-
doug waud
-
Gregory Avedissian
-
Gregory Avedissian