Still I managed to screw things up somehow by complete ignorance so
understand this more as a warning not just a bare bug report.
Consider my /dev/sdb with 1 the extended partion, 2 primary, and 5,6,7
logical partitions. For some temporary stuff I added part 8. Coz I forgot
to unmount some stuff on /dev/sdb it couldn't reread the part table. Claiming
to know what I do I unmounted those, changed the part table again and was
fine. Nevertheless this way I somehow managed to get a start of data at 0
in this new number 8 partition (this is what I claimed later). Still
everything worked fine, mke2fs etc.
Even after a reboot /dev/sdb8 was properly mounted. Unfortunately
it seems mke2fs cleared some important data. Some time later I called fdisk
and it complained about an illegal part flag 0 for sdb8. It suggested to fix
it (well it just fixes it when you do something else on the parttable)
fdisk-suggestion 1: I had preferred if I would have had a chance to leave
sdb8 just alone.
That fix rendered the sdb8 unusable. fdisk showed 0 entries for everything
in it. Was still unusable after deleting and repartitioning sdb8 at the same
location. With some effort I hunted for a secondary ext2 super block..
ext2-suggestion 1: Need a tool to sequentially scan a block device for
a ext2 super block. Maybe -B allows to do that. But I was unable to
understand what it exactly does from the man-page (it just didn't help me).
Found one at 8177 instead of 8193 (something like: dd if=/dev/sdb8 | od -x
| fgrep -n ef53), and so finally found the new partitions wa shifted 32
sects. But alas, fdisk didn't allow me to do that. It insisted on a minimum
offset of 32 for start of data. So:
fdisk-suggestion 2: When I am in expert mode I want to be able to change
anything. I might get a warning but when I say start of data is 0, then
start of data is 0 not 32 (big point). Fdisk is just a dump program it
has to do what I ask it to do.
Fortunately I had sources so I could ugly hack fdisk to make start of data
= 0. Woosh: sdb8 back and alive, no errors in it's ext2fs too (puuh.. well
actually the data there was only of minor importance, anyway).
Of course, my first thing was backing up that data to some other disk. Now
I deleted sdb8. No chance. Even after a power cycle sdb8 was still there.
fdisk deleted it and wrote the part table, but at next fdisk call or
reboot it was still there. Deleted and immediately overwrote it (this
time with valid 32 start of data offset). Fine, but still undeletable.
Probably fdisk has a bug there keeping it from writing some sector back.
I could finally get rid of sdb8, by deleting it and (in the same fdisk
session) changing the type of sdb7 to 81 (from 83). That helped.. away was
sdb8. Then I changed the type of sdb7 back.
That last bug reminds me of something some of my friend reported. fdisk
1.5b seems to have problems with at least deleting of extended partitions.
Unfortunately I've not the slightest idea how a parttable has to be
constructed so I can't explore myself.
Go figure,
Michael.
(eowmob@exp-math.uni-essen.de or eowmob@pollux.exp-math.uni-essen.de
Please do not use my vm or de0hrz1a accounts anymore. In case of real
problems reaching me try mat42b@aixrs1.hrz.uni-essen.de instead.)