MEPIS Community Forum

This might work, and can't hurt.

Boot to your Windows disk, enter Recovery Console, then run

fixboot
fixmbr

Reboot and confirm you can boot to Windows.

Then boot to the MEPIS live disk, and try 'fdisk -l' again. If you get good output, use the MEPIS System Assistant and run the Repair System Boot tool.

OK, I tried those things from the Recovery Console.

Says fdisk: "Unable to seek on /dev/sda".

I would bet good money that if I deleted these partitions, and reinstalled Remix_OS, it would work. It might even work if i deleted them and installed Mepis. I like to install partitions from the end, forward, because I can keep reducing the size of my "D" drive using MiniTool Partition Wizard (free) to make room for them.

Are both hard disks SATA? If so then boot the Mepis LiveDVD and run (from Konsole/Terminal) TestDisk (as su). On both hard disks. It seems to me that the partitioning and repartitioning may have scrambled things. If TestDisk confirms the cannot seek error from fdisk I suspect that sda has been toasted and will have to be repartitioned, reformatted and/or reinstalled. Perhaps even wiped before doing that.

When partially repartitioning a hard disk it's easy to loose track of which partition is which. I speak from personal experience.

But if you have a mixed SATA/PATA hard disk system they are probably confusing GRUB.

No. My "C" drive is IDE, but my "D" drive, which I attempted to install Mepis to is SATA. As mentioned in previous posts, my "D" drive has not been toasted. I can get files from it fine. However, there seems to be some problem with its partition table nonetheless. I'm pretty sure I didn't lose track of which partition was which. I have some content on my "D" drive I most definitely do not want to erase, and the Remix_OS partition came in at /sda5 and its swap at /sda6. When I used the KDE Partition Manager, it created a /sda3 for me, which I overwrite with Mepis. I was quite sure I did not want to overwrite /sda5, as it was working at long last with my Presonus FP10: a Firewire audio interface.

I'll reboot and try TeskDisk later.

One thing that might have been unusual about my install: I reused the Remix_OS swap partition for the Mepis partition. That was my /sda6. I don't know if there is ever an issue about using e.g. a recent Ubuntu swap partition for a Debian swap partition. This seems unlikely to have been the problem, however, since Mepis should have been happy to have been assigned a swap partition, and I had not booted Remix_OS before finding a completely unresponsive Grub.

I thought I might have needed to reboot to run it, but I ran the Windows version of TestDisk. It calls my "C" drive "/sda", unlike the Mepis install disk, which calls it "/sdb". Of "/sda", it says:

1 * HPFS - NTFS 0 1 1 34580 254 63 555543702 [First SATA]
2 E extended LBA 36603 76 17 38913 70 5 37109761
5 L Linux Swap 36603 76 18 37089 164 3 7813120
X extended 303952 165 20 306262 159 9 37109762
Must be in extended partition
2 E extended LBA 36603 76 17 38913 70 5 37109761
X extended 303952 165 20 306262 159 9 37109762

When I tell it to do a quick search, I get:

Disk /dev/sdb - 320 GB / 298 GiB - CHS 38913 255 63
Partition Start End Size in sectors
>D HPFS - NTFS 0 1 1 34580 254 63 555543702 [First SATA]
D Linux 34581 0 1 36602 254 63 32483430
D Linux Swap 36603 76 18 37089 164 3 7813120
D Linux 37089 164 4 38913 70 5 29296640

When moving the selection to the second entry, it tells me it is ext3 - thus it must be the Mepis partition. When moving the selection to the fourth, it tells me it is ext2 - evidently the Remix_OS partition. As expected, the size in sectors is a little larger in the second than the fourth: 15.49 GB vs. 13.97 GB, the sizes I originally made the partitions; using 512B/sector.

First let's get nomenclature corrected. Forget calling a hard disk C or D or E or whatever. These are Windows terms. If you're in Windows by all means call them that if you wish. This is a Linux forum.
In Linux the first hard disk in the system (Port 0) is sda if SATA, (hda if PATA). In a mixed system with both SATA and PATA IDE hard disks things get complicated in a hurry. Mainly because (usually) the BIOS and GRUB see things differently.
Using UUID is the preferred way to handle this sort of thing. UUID = http://wiki.debian.org/Part-UUID
To impliment it see our wiki = http://www.mepis.org/docs/en/index.php?title=Uuid
and the second answer here: http://forums.debian.net/viewtopic.php?f=10&t=48821
for syntax.
This means that you'll need to edit the /boot/grub/menu.lst file manually. This is easily done by left-clicking on that file in Dolphin as su ( Find Dolphin as su under the System menu entry), this will open the file to be edited as root.
There you will need to change the kernel line as the forum post linked above says in those instructions.

PS: I had so much trouble with this (before I knew about UUIDs) when I was trying to use both PATA and SATA ports in a new motherboard that I got a USB external case and put the PATA drive in that!

I am calling them drive "C" and "D" here, since drive "C" is always the same, as with drive "D". (By "D", I mean the disk with the Windows "D" partition, along with Linux ones.) As I mentioned before, I installed Remix_OS, an Ubuntu derivative; and when I warm-booted, it had /sda different than /sdb. I am not yet convinced that Mepis is any better at keeping them straight. Since Linux cannot keep /sda and /sdb straight, using these to refer to them is useless.



Thanks for the helpful hint. I really had no idea. Here I am, a prospective Linux user, and I'm getting a lot of attitude for even referencing the letters that Windows keeps my drives straight with. Way to win converts.



Are you sure? I wonder if other users of this forum would find my referring to my drives by their UUID's more intuitive than "C" and "D".



In case you missed it, the topic of this thread is that I CAN'T BOOT MEPIS!!! How do you expect me to edit a file when partition utilities can't even agree on its presence? Now imagine the frustration of searching for solutions among posts that assume I can. Perhaps you are suggesting that I edit a file on the Live disk's RAM disk? That seems the simplest interpretation of your suggestion.

UUID's are not a great solution either. Before Kubuntu released an update that locked the updater and produced an unbootable OS for me, I had created a new partition to install yet another OS, by resizing my "D" drive, using MiniTool Partition Wizard. This resulted in a grub that could no longer find one of its partitions by UUID.

Your first shot out of the barrel was



and you want to talk about attitude? Most anywhere else they would have run you off on a rail.

People have bent over backwards to help you. It appears that you've got an oddball partitioning problem that may or may not be related to the sequential shrinking you've done to the sda1 partition. You have yet to post the output 'fdisk -l' and your menu.lst file that I asked for. And most of the time your responses are nothing but rehashing the same irrelevant information you've posted previously or arguing about the suggestions you've been offered.

And you want to talk about attitude???

I can't/won't speak for anyone else, but as far as I'm concerned, you're on your own.

Actually, if you'll read my previous post, I wrote:



I have found people here helpful save the one post by lucky9. Have you noticed the number of times where I pointed out a question was answered in a previous post? I count four or five. I am currently using the TestDisk utility to try to recover partitions, as pointed out by lucky9. The Mepis partition itself seemingly has been recovered, but sadly, not the React_OS or the swap partition. I thank him for that; and the other attempts to help.

When running TestDisk, I don't seem to have the option to bring back a partition that it finds with Quick Search, unless it is with "Add". A deep search revealed the Mepis partitions also, but when I hit enter to continue, it shows me only two partitions, and asks if I want to write them out. Perhaps I need to not use the most recent beta version.



I don't believe that at all. Mepis deleted another operating system's partition; not to mention failing to boot. This is pretty serious. Yes, Linux is freeware, but perhaps the inability to tolerate the things that need to be said hampers it. Yet, I want an alternative to the anti-competitive practices of M$. I stand by my statement. I provide a fair amount of feedback to a fair amount of programmers - just google my nick. Soon, I plan to release my xwGNUPlot control, which runs in a pipe under Windows (no trivial feat), as a way of giving back. I don't pull any punches. I think it makes for better feedback, and better software. If you'll notice, I too have been going the extra mile to try to resolve the problem and provide useful feedback, as opposed to just giving up on Mepis. I am even willing to try the sequence of installing React_OS and installing Mepis again, to see if it has the same effect, and wasn't just a random hardware glitch. My relatively new SATA drive has been running like a top.



So, you're saying that Mepis works just fine the way it is, deleting partitions and all? You may not believe it, but I am arguing for civility, and reading posts before responding to them. It helps more get done.

Some corrections, Mepis or any other OS will not delete any partition, that is without you tell it to, and the same goes for MS,
terms used for the components in Linux are different to MS, eg hard drives, so use them, you will find it easier to identify components as Linux expects them to be named.
Mepis just works, is a bit of a myth, while it may just work on some systems, it certainly does not work on all.
Do not, expect Mepis or any other Linux OS to be the same as MS, it is not.
But what do I know, well you could try doing a search in Google for Danum remaster