openSolaris hosed the partition table. Why? Changing primary to secondary partition?
 

I installed openSolaris and booted the first time from the hard disk. Shutdown did not go to power down so after a few minutes I pressed the reset button and all hell broke lose, i.e. GRUB said error 17 (?) no kernel found.

I went into command mode and told it where a kernel is located and also searched for the kernel. Error.

Gist: The partition table contains nonsense. Worst, /dev/hda4 is now of type 1f (undefined / unknown) and can't be changed to extended lba by fdisk. I hoped that my system is still in /dev/hda9 but I can't manually re-create my partitions :(.

I'm afraid, that while the MBR seems to be working (GRUB stage 1) /dev/hda1 is gone as well -- that was /boot with my menu.lst. Sh*t.

Anybody any ideas how to start from this mess and how to avoid it in the future?

It is unclear what happened. You shouldn't have reset the PC while it was shutting down as it was probably still in the process of building a recovery environment (this is done at first shutdown and after kernel related modifications). However, that shouldn't have affected the partition table.

Are you sure you didn't overwrite the other partitions at installation time by installing opensolaris on the whole disk ?

Did you backup your partition table ?

Is the live CD able to access your ZFS pool ?

What is your current partition table looking like ?

I realized that too -- now, when it is too late. But I could not hear any activity from the hard disk so I assumed (wrongly) that the shut down process didn't work as it should.

I am. I installed a SuSE 11.0 after openSolaris and used it for a week. I just had succeeded in creating a working menu.lst (trick is to hide all partitions) to be able to start openSolaris from the main boot menu.

Indeed. Ten minutes before the final crash. In my /root directory on /dev/hda9 ... gone with the wind :(.

I didn't try yet.

Well:

/dev/hda1 83 linux (my /boot)
/dev/hda2 ?? solaris
/dev/hda3 a5 FreeBSD
/dev/hda4 1f (unknown)

The first three I corrected with fdisk, e.g. hda1 was amoeba, solaris was okay and FreeBSD was something else too. But fdisk won't touch /dev/hda4. I am considering to delete it and re-create the old partition table by hand. I've got a printout without the last partition. I thought to make that large and install the original MBR back as soon as I can lay my hands on the MBR I saved there.

<edit> Had a unusual behavior with FreeBSD too. After shutdown a week ago I had to repair my linux system. Dunno whether that is linked somehow...</edit>

Have you tried changing the partition type back to 5?

I tried to change "1f" to "Win95 extended LBA", i.e. extended partition (can't remember the hex-code right now) and got back the error message of fdisk, saying something like "can't change primary partition into extended, you must delete it." And there I balked.

If there come no better ideas, I'll do just that, delete it and re-create an extended partition by hand with the parameters according to an old printout -- and a very large last partition, in which my newest system ... was located, until recently ;).

What might have happened is the partition 2 and 4 starting and ending locations have been "adjusted" by some of the partitioning tools you used and now point to the wrong location.

Also, it is quite possible the presence of both a *BSD and a Solaris primary partitions had confused Linux. The Linux kernel is usually able to detect all of them and treat the inner partitions/slices as extended partitions but I doubt it is able to handle both at the same time.

duplicate thread. The other one on this topic is in software. And you still haven't responded to my post on that thread, other than to say that you were not in front of that computer.

Solved
 

But I'll answer you first.

At the time of the crash I hadn't used any partitioning tool. I was just shutting down openSolaris and probably too impatient to wait out its shut down procedure thus I took the "shortcut" of a hard reset.

Hm, no. Linux was running for more than a week without outright complaint. This was an openSolaris effect during an interrupted shutdown.

You are right in as much as during boot I get the translation from the inner slice numbers into /dev/sdan of the openSolaris partition (hda2) but not anymore of the FreeBSD slice (hda3). So I can't read my home directory in FreeBsd anymore, can't I? :(

No. Tattletale ;). You didn't read the topic there, did you? I am asking there for software which can change a primary into an extended partition, which fdisk can't (and I give the reason).

I'll go there right after I post the solution here. Was away on business for two days, sorry.

Solution
 

In the end I took the plunge (using Knoppix as root). First I reset the partition type of amoeba (0x93) of /dev/hda1 back to linux (0x83). Then I mounted /dev/hda1 and my /boot was back under the living, unscathed and whole.

So I reset /dev/hda3 to FreeBSD (0xa5) but I haven't tried that yet, since there is an other issue with that: http://www.linuxquestions.org/questi...loader-674519/

After that I deleted /dev/hda4 and re-created it as extended partition (0x5). Next I rebuilt the lost secondary partitions from an old printout using the number of cylinders. A bit tricky, since there were a "hole" from an older, deleted partition and also the number of blocks in the "new" partitions didn't match exactly the numbers in my printout, don't know why, different versions of fdisk?

After rebooting (else the kernel would have used the old partition table) -- I got a nasty kernel panic. Well, what else? So I corrected the /boot/grub/menu.lst to point to the changed root (remember I filled up that old "hole"? New partition, and the rest gets new numbers.). And while I was at it I edited the /etc/fstab as well, rebooted and -bingo- Linux was back with us -- sort of. E.g /root and some other directories were missing.

So I deleted the / partition again and re-created it 5 GB larger and then everything was (probably) there. I didn't really care then, since /root hosted a practically brand new copy of my original MBR including the partition table, which I dd'ed back immediately.

My error was that the data of the secondary reside somewhere else (I'll have to dig that up and save them in the future). But still, up to now everything works and from memory I'd say the now used size for / is the one I used during installation.

What would have happened if I had made / much larger, i.e. the partition's file system left a gap at the end? :scratch: