/ Sign-up
Your question


  • Linux
  • Grub
  • Windows XP
Last response: in Open Source Software
August 12, 2006 5:12:09 PM

Ok so I had posted a forum earlier about my linux/xp machine losing the GRUB for the multi-boot. Well now my computer has the GRUB but can't load either of the OSes and I have non-backed-up data on these drives ( I know I know I should have backed them up but I didn't have the money to get an extra drive or anything.) I tried reinstalling linux via the Package manager during a live session (that's how I fixed the GRUB) but now it won't work. Any way I can recover that or even restore the system to a date before it crapped out on me?

More about : recovering data

a b 5 Linux
August 13, 2006 5:46:03 AM

Yes, there are a lot of options here, depending on what you have available to you. From the livecd, you could...

...rework the partitions, move the valuable data to the new partition, reinstall without touching that partition

...recover the install from the livecd, would be helpful if you could give us an indication of what's happening when you try to boot either OS and what steps you've done and in what order.

...attach an extra drive to the system and transfer data over from the livecd. could be one or more usb flash drives, a usb or firewire based external drive, a burner, a new internal disk, etc. etc.

...transfer the data to another machine on the network (or internet). Could use ftp, sftp, rsync, etc. etc.

Those are the obvious ones that pop into mind, but we need to know a little more about the tools you have available and what has happened to get your machine into this state to be able to be of more assistance.
August 13, 2006 6:06:56 AM

Well ok... here's what I can't do:

I can't rework any partitions... even though I have free space I can't rework it without destroying anything (tried to resize the partition but that didn't work).

Now I have tried to reinstall from the livecd since I figured if I could fix my GRUB I should be able to fix everything else from there (after all with over 1000 packages I should be able to find something no?) Well even after reinstalling all 1046 packages I still got the message: Error loading OS.

Any other ideas? I tried the thing with the flash drive but it didn't work
Related resources
a b 5 Linux
August 13, 2006 3:46:03 PM

Resized using what tool(s)?

By "recovering" I meant tweaking things without doing a full reinstall. I still am a bit fuzzy on the steps that have led to the current situation and as such I am limited with what I can suggest.

The grub error you gave usually indicates an improper lower-level setting (e.g. improper master/slave IDE settings, not listing the drive in the boot sequesnce of the BIOS settings, having the primary boot partition not marked as "active", etc.) or the famous "post-install GRUB switcheroo" where device names/numbers given during install magically change when booting from disk (not that likely since newer distros have gotten really good about this).

I'd like a little more info about your system, specifically PATA/SATA configuration and steps taken to get to the point where your system is now, starting (presumably) with a working Windows install.
August 14, 2006 4:05:34 AM

Ok so I tried to resize the partition using the Ubuntu parted. As for the whole thing about the grub, Linux was on the master drive and it worked for a while but then all of the sudden my GRUB was gone. All I had to do was reinstall it and then when I booted up I got the message "Error Loading OS" and tried reinstalling Ubuntu but that didn't work. I only have 1 PATA channel and that's set up as this:

master drive: 80GB WD caviar
slave drive: 250GB Hitachi Deskstar

both oses were on the master drive.
a b 5 Linux
August 14, 2006 9:44:48 PM

Ok, what I'm going to suggest here is to use the nice functionalities built into GRUB to try to force a boot (and thereby indicating it's an issue with a corrupted grub.conf/menu.lst or a bad GRUb setup)

First, on system boot, you likely will have to type some key to prevent GRUB from automatically booting an OS. With only Ubuntu installed it looks like you have to hit "ESC" to enter the normal GRUB menu screen.

At this point, we want to drop into the console to try to boot a simple kernel, the "memtest86" kernel.

//now at the GRUB CLI

//get an idea of some of the tools we have to work with

root (hd0,1)
//this is just a guess based on your description of actions taken
//you should get confirmation along the lines of "Filesystem type is
// SOME_FS, partition type 0x##", 0x83=Linux
//if it doesn't look right (e.g. it is NTFS or FAT32) try something like
//"root (hd0,0)" or "root (hd1,0)", etc.
//basically, hdM,N corresponds to disk M and partition N
//and you cannot ruin things by entering a bad combination while
//searching for the right disk.
//Continuing, assuming you've found the Linux partition

kernel /bo[tab]
//this should change the entry to "kernel /boot/" and list all possible options

kernel /boot/mem[tab]
//you should get some output like [Linux-zImage, etc, numbers here]
//now you've set the memtest kernel image as the thing to try to boot,
//let's give it a go


This should boot you into a DOS-ish, very blue memory testing system called MemTest86+ If you got that far, things are looking better, now we just need to try to resurrect the linux options and such to boot your system in the same way we just did with MemTest (and later Windows too, although it's likely that that won't even be necessary once the problem has been fixed from within Ubuntu)

The standard Ubuntu kernel options are as follows (at least on my machine, should be fine or close enough for your system)
[code:1:661565cb19]//from /boot/grub/menu.lst
title Ubuntu, some version
root (hdM,N) //looks familiar, no?
kernel /boot/vmlinuz-2.6.some_version-arch root=/dev/XdYZ ro quiet splash
initrd /boot/initrd.img-2.6.same_version-as-the-kernel

Now, some explanation about that is listed above as we build the necessary options for booting. Drop back into the GRUB command line.... here we go...

Title is a nicety for you and I, just that. It is not needed for booting and should be skipped in the GRUB command line.

root is the same as when we were playing with MemTest, it tells GRUB where to start looking for files to try to boot (kernels, system images, the like). Reuse here what you discovered before, likely (hd0,1).

kernel tells GRUB what to try to boot and also what parameters to pass to that kernel before we get going. Note that you may of course use (and I suggest you do so) TAB completion to find that kernel name/version/architecture.
An example would be "kernel /bo[tab]"->"kernel /boot/" and lists vmlinuz-2.6.15_23-386 and vmlinuz-2.6.15_25-386, choose the latest kernel, so -> "kernel /boot/vm[tab]"->"kernel /boot/vmlinuz-2.6.15_25[tab]" should have all of the kernel image name listed.

I hope I am explaining this well enough, because tab-completion is one of the most powerful tools out there when dealing with systems this low-down and close to the hardware.

Anyway, now comes the kernel parameters.

ro tells the kernel to look at itself as a read-only file, to protect itself from corruption.

quiet tells the kernel to suppress unneeded output.

splash tells the kernel that there's a nice splashscreen that's already been setup, use it.

Now for the trickiest kernel param, the root option. This tells the kernel, in terms it can understand, what disk and partition holds the root filesystem for the Linux system. This requires a translation from physical layout of the system to the UNIX format. Since the disk is an ATA device, X will be 'h', so we have "/dev/hdYZ". Now, we have to figure out what Y is. The breakdown for ATA devices is this: Primary Channel: Master='a' Slave='b' Secondary Channel: Master='c' Slave='d'. So, let's say your main disk is the Master on the primary IDE channel (check your BIOS to verify). That gives us "/dev/hdaZ". The final part is the partition number. We've already figured this out in the "root (hdM,N)" step, N being the partition number-1, so Z=N+1 (to get it back to normal). Using my assumed settings you have, (hd0,1) and /dev/hda2 would be the values to use for the respective steps. Change to suit what you have found to actually exist on your system.

initrd is an image file that includes drivers and such for use by the kernel. You can have drivers built-into the kernel or have them separated into modules, some of which are packed into this image if they are important system-related stuff (like disk drivers, chipset drivers, etc.) Go through the same steps listed to locate the kernel, but re-focus it on initrd. An example would be "initrd /bo[tab]in[tab]5[tab]" leading to "initrd /bootinintrd.img-2.6.15_25-386" No options are needed here unlike the kernel line.

savedefault is not needed, skip it.

boot, cross your fingers, and let 'er rip! With any luck, this will bring you back into Linux.

This is a long way to come and I imagine some problem(s) will rear their head before you get here, but it's a start. Let us know what you find.
August 14, 2006 10:54:27 PM

Well if it helps... I have an old Dell Dimension 8200. I tried the whole esc on the GRUB but here's the problem... the only screen I'm getting is my boot screen which is the Dell logo and then it goes to "Error Loading OS". I'll try to see if I can get the GRUB to go first... but I'm not sure.
a b 5 Linux
August 15, 2006 1:27:24 AM

Ok, I didn't realize that's what was happening. Your BIOS is unable to find a bootable OS on any hard disks listed in the boot sequence setup in the BIOS configuration. Please double-check that, the "error loading OS" message does not have anything to do with GRUB or Linux at this point.

Check the disks' master/slave settings
Check the cable for obvious damage
Check the power connectors for any obvious issues
Check the BIOS to make sure all disks show up properly
Check the BIOS to make sure that disks are set to the proper access mode ("Auto" or "Large" should be fine)
Check the BIOS to ensure that the boot order lists the proper hard disk.

If you've done all of that and the issues persist, boot a diagnostic disk (the ultimate boot cd is a good one) and check your disks' health. The OS disk may be dying.

Edit: After reading the Dell Forums, another common cause of this issue is a dead/dying CMOS battery. Open the case, look for what basically amounts to a very large watch battery, get the info off of the battery, visit Radio Shack and pick up a replacement if none of the previous steps have helped.
August 15, 2006 4:31:12 AM

Well I just found something interesting out... apparently someone turned the master drive off in the boot menu. So I turned it on and now it's giving me "Error 2" while the GRUB is booting up.
August 15, 2006 5:32:01 AM

If the data is intact on the home partition (or whereever it may be), you could boot from a knoppix disk and ftp the data off to another computer. Google on knoppix.
a b 5 Linux
August 15, 2006 11:39:06 AM

Well I just found something interesting out... apparently someone turned the master drive off in the boot menu. So I turned it on and now it's giving me "Error 2" while the GRUB is booting up.

I believe you need to reinstall grub.


/sbin/grub-install --root-directory=/mnt/sysimage --grub-shell=/mnt/sysimage/sbin/grub --recheck /dev/sda

You will have to change the options accordingly to match your system.
a b 5 Linux
August 15, 2006 2:25:56 PM

Yup, a simple "Error 2" and nothing else indicated a stage 1.5 error, namely the location of stage 2 is pointing to a disk that does not exist, at least in terms of address (may change when doing things like modifying BIOS, removing/adding new storage devices, etc.) so GRUB throws it's hands up and quits.

While an "all-in-one" shot setup is gret if you know what you need, for one where you kinda have to "feel out" your hardware I prefer to use the interactive command line to try out configs first (then you can even install it from there too). Just my $.05 (since the penny's likely going away)
August 15, 2006 3:04:42 PM

Cool, thanks for your help guys... I'll see if I can get this thing up and running again but I'm just curious as to why this happened... I mean it was running fine and then one day it was kaputz... I didn't change anything and it just gave me that message.
a b 5 Linux
August 16, 2006 7:25:37 PM

My feeling on "why this happened": a glitch in the hardware (it was just a one-time deal) was enough to fool your system into thinking there was no hard disk with OS's on it (either it was removed from the BIOS boot list or the disk "disappeared" from what the BIOS could tell and it automatically removed the disk from the boot sequence as a result)

At this point, reinstalling took the address of the disk, now removed from the boot sequence, and used that to dictate where the stage2 stuff lived. As soon as you try to reboot the system, the BIOS doesn't try the disk as it's not listed as a boot device. It gives up. You move the disk from the non-bootable list in BIOS to the bootable one, which I suppose changed the way the BIOS doled out addresses to the drives and as such broke the GRUB install.

In short, I don't think GRUB ever broke, I think a short glitch caused some hardware weirdness and as soon as you reinstalled ubuntu to the slightly-changed system it broke GRUB once you reverted the system to how it was before. The real culprit here is the clandestine and arcane way BIOS works in order to support older hardware. I firmly believe we should just dump it as it has outgrown it's usefulness. If BIOS were gone there would be none of this multi-stage nonesense to get a useful pre-OS environment... [/steps from soapbox]

Edit: Just to ensure it wasn't an omen of a lurking issue, I'd go ahead and use one of a multitude of tools to check on the health of the disk. Many manufacuter's have SMART-scanning boot disks for download, and there are ones in the Ultimate boot cd (a fine tool) and some Linux liveCD's (not sure which ones, but look for the ide-smart and smartmontool/smartctl tools).
August 16, 2006 7:30:07 PM

Ahh... that explains it... Oy... well I'm going to try to liveCD the Knoppix and then transfer all my stuff to an FTP server that my friend and I share. Wow... the wonderful world of heiarchies never ends. so GRUB is fine and BIOS is there... IT'S SO CONFUSING!!!! Why can't they all just have something more simple? Something that won't cause this... oh wait, because then that would give microsoft the edge... whatever. Well thanks guys, you were a big help :D 
August 18, 2006 4:10:20 AM

Be sure and verify the files actually made it to the server by looking at them from another PC or the server. Knoppix is a great tool for many things, but can be funny when you copy stuff. I never had a prob. with ftp, but other ways to copy often resulted in copy to ramdisk (i.e. nowhere).
a b 5 Linux
August 18, 2006 7:05:00 PM

When you copy things to a locally mounted but external disk (e.g. usb flash or hard drive) make sure to unmount it or you may get those same results. This is due to not flushing the cached stuff in the VFS.

For any network-based transferring, I am unaware of any situations that could result in the behavior you described.

Nonetheless, it is a good idea to verify the transfer.
August 19, 2006 5:33:00 AM

The problem I had was several versions ago, so it may no longer apply. Or, it might <evil gr> If I have to guess, I'll say bmouring is right and the problems I saw are gone with the newer versions. Here's what happened:

Some fellow with a tear in his eye had brought me a HD with his whole life as he knew it riding on it's data. Some kinda NT, probably XP, but I can't recall. So, I plugged it into an old PC and booted knoppix. I think it was around Version 3. I could see his data and began to copy it to my RH server using some linux neighborhood tool or something. I'm not sure if that's even there anymore. It was just some GUI tool to mount and access SAMBA shares. So I copied everything, then went to the RH box to see if it was there and it wasn't. So, naturally, I copied it again the same way and it again did not show up. Being slow, I probably did this six or eight times before I decided to try and find out where it was going. I finally found it in the local filesystem under /ramdisk or something like that. So I tried to copy it to the local PC's drive and it did the same thing. Then I tried FTP and it worked. I think I used the old text Midnight Commander so as not to stress any tired brain cells with FTP commands.

I use Knoppix and Astrumi as tools for many tasks. Never really tried to figure out why some things work or don't work. Once my DVD knoppix iso gets downloaded, I may find out more. I'm curious as to what comes with a 4 GB disto of knoppix :D 
a b 5 Linux
August 19, 2006 6:09:14 PM

Ah, this makes much more sense. When it comes to recovery efforts I always suggest going as no-frills as possible.

Command-line ftp (or sftp) and you'll know when something goes arwy (my guess is the situation you described was a result of a misconfiguration which mounted the SMB "disk" as a writeback cached device, which I don't think is possible since the caching behavior is dictated by the SAMBA code itself, or more realistically there was some issue connecting to the server that wasn't being forwarded from the underlying VFS to the GUI).

But thanks for laying out your experience, it's something I wasn't aware was possible and as such I'll be sure to keep an eye out for it. :) 
a b 5 Linux
August 19, 2006 7:25:10 PM

:trophy: bmouring

I always advise people to md5sum and sha1sum their files to verify they have been transferred successfully.

August 19, 2006 8:09:40 PM

For giggles, I might try it again with the new version. Funny I had trouble writing to the local disk. Same result, it just went to ram. I'm sure I coulda played around and fixed that, but I really wanted to get the data onto a stable Linux box, so ftp was the way to go. I dunno why I even tried the samba gui thang. I guess because it was there :roll: