[ale] Success!! (mostly dumb luck) was Partially corrupt partition table, Mandrake 10.1
rb211 at tds.net
Sat Apr 2 13:08:27 EST 2005
On Friday 01 April 2005 07:48 pm, Joe Steele wrote:
> On Fri, 1 Apr 2005, William Bagwell wrote:
> > Knoppix (3.7) shows them with fdisk -l. (Have not yet run your full
> > script from Knoppix as it locked my "Documents" files for some
> > reason...)
> Whenever you access a hard disk in Knoppix (e.g., clicking on "hard disk
> partition [hda1]" on the desktop), Knoppix mounts the disk read-only.
> One way of changing this to read-write is by right clicking on the
> partition and choosing "actions -> change read/write mode".
I could access the rest of my home partition, only Documents and a few other
random (mostly .hidden) files were locked. Probably some weird permission
problem of my own doing, not going to worry about it at the moment.
> > Also discovered they show up in /dev as block devices. With fresh
> > back-ups would this be a convenient place to try to delete them?
> If you are suggesting keeping your existing partitions but wipe out all
> the data in them by reformatting them (e.g., mkfs -t ext3 /dev/hda19),
> then yes, you could do that.
This might have worked as hda19 was the main problem, too late to find out
> On, the other hand, if you are suggesting, for example, "rm /dev/hda19",
> the answer is no. That would not delete the partition; It would only
> remove the block-special file "hda19" from /dev/. (And if this were done
> by accident, then it's a simple matter of using mknod, chown, and chmod
> to recreate the file. In fact, you can create devices for partitions
> that don't even exist -- mknod /dev/hda63 b 3 63. But any attempt to
> mount the newly created device would obviously fail because the partition
> doesn't actually exist.)
Was what I was hoping....
> > root at ttyp1[knoppix]# fdisk -l
> > Partition table entries are not in disk order
> Progress! From this it looks like the disk space is pretty much fully
> allocated to partitions.
BTW, QT-parted (in Knoppix) also showed the extra empty two Gig "space". Out
side of and below the nested extended partitions.
> Your first posting of this thread mentioned DrakeX saying "error while
> reading partition table in sector 207270630". By my calculations, the
> error is referring to the partition table at the beginning of /dev/hda19.
> Since fdisk isn't complaining about this partition here, I wonder if
> possibly DrakeX just isn't up to the task (just like your first version
> of fdisk wasn't up to the task of handling 16+ partitions).
Yes, and regarding the DrakeX error in my first post, testing in an
installer (canceled without committing changes) when it asks "Do you agree
to lose all the partitions?" that is exactly what it means:(
> I'm not sure what exactly you want to do next, but it looks as though
> this version of fdisk could be useful in achieving your goal.
Well first I made a second mistake by forgeting to unmount a partion on hdb
before modifying it. Arrgh! Don't do this!
Deleted hda19 using QT-parted in Knoppix, then reinstalled MDK using custom
partitioning. With DrakeX now functioning correctly, I used a screen shot
of the tables as a guide. Which I had wisely (for once<G>) saved on another
computer. This had the happy side effect of them now being numbed in order.
Did lose my upgrades since I let it format / and /user....
Note to anyone following this saga in the future: The partition tables
listed by DrakeX and the tool in Webmin are off-set by one cylinder. One
starts counting at zero, the other at one. Safe to ignore when "fixing"
More information about the Ale