alright so i'm new here,
and new to linux really..
i just got a new laptop a couple days ago with windows 7 installed and i'm trying to setup to dual boot to linux Mint.
i did this once before on an xp machine and it worked fine but not today,
what happens is i popped the live cd in the computer with windows up, and told it to install inside of windows, it went through the installation process then it ejected the disc and rebooted the pc.
whenever i started back up it didn't load Grub and instead went straight to windows.
i talked to some other guys about it and they said to try to reinstall grub through the terminal on the live cd.
so i boot to the live cd and open the terminal, i had a site open telling me the commands to reinstall grub.
i typed:

sudo grub

[ Minimal BASH-like line editing is supported. For the first word, TAB
lists possible command completions. Anywhere else TAB lists the possible
completions of a device/filename. ]

grub> root (hd0,0)

grub> setup (hd0)

Error 17: Cannot mount selected partition

grub>

what's going on here? is it an incompatibility with 7 or something?

please help, thanks

If you want a dual-boot, I would strongly suggest you install it booting from the livecd. That is, not doing it while Windows is up, but restarting your PC with the Mint CD in your disc drive. I have dual-booted many time with no problem. But I never tried to set it up in Windows.

Ditto.....

I have no experience running Linux from within Windows, but it just seems like an unnecesary layer of complexity. Dual-boot is pretty straightforward to set up, and will give you better performance.

There is one caution: Many Windows machines today come with no install CD, so make sure you have a way of recovering if something goes wrong.

You might also want to consider a virtual machine such as VirtualBox.

Windows 7 creates a 200MB hidden NTFS system partition (containing the boot loader) located before the Windows NTFS boot partition (containing the Windows Operating System). NOTE, Microsoft terminology is somewhat backwards. They call the partition with the boot loader the "system" partition and the partition with the Windows OS the "boot" partition.

To make matters worse, the 200MB partition does not end on a standard boundary. The best way to avoid the problem is to create the NTFS partition to hold Windows BEFORE installing Windows. Then specify that you want to install the the existing NTFS partition. Make sure that there is no free space in front of the NTFS partition or Windows Setup may create the boot partition. It is a good idea to create all your partitions before installing Windows.

If you keep the 200MB partition then your disk drive IDs will be like this.

(hd0) - Hidden Windows 7 System Partition with boot loader
(hd1) - Windows 7 Boot Partition with Operating System files and WINDOWS folder
(hd2) - Linux root partition (if you put it after Windows)

It is not easy to remove the 200MB partition without reinstalling Windows. You have to copy the boot loader files and boot database to the Windows OS partition. Then remove the 200MB hidden partition and resize the Windows OS partition to fill the empty space. Finally use the BCDEDIT program or a Windows 7 boot disc to repair the boot configuration database. Of course you can't do any of those things while booted to the Windows 7 OS. You need some other boot disc to do everything except repair Windows. If you don't have a Windows 7 boot disc it is difficult or impossible to repair Windows 7.

If you need further help make sure to print your partition table and post the information here. The only way for anyone to know your system's exact partition layout is for you to list it.

that's the thing,
it didn't come with any recovery discs.
it gives me the option to make one but idk if that's for a completely blank hard drive or just a repair for a bad file system.
if i install it from inside linux will it be able to set up a partition by itself and not need to screw with my windows part?
i haven't thought about the virtual box idea, that'd probably work, although i really don't have alot of ram to spare.

Might I suggest you make the Windows 7 recovery CD. It will probably have what you will need to have it. If you fear it won't, you can add the GParted partition editor to your collection. I had to do this for my recovery cd because mine apparently didn't/couldn't edit partitions to install. This ensures that if something goes wrong you have a backup. So do that before anything else.

You definitely need to make the recovery discs because you might not be able to after you have a problem with the computer. I also recommend that you inspect the partition layout and sizes and write all that information down. Some recovery CDs (Acer in particular) will not work if you change the partitions. To restore the system you may need to create or re-create the correct partitions with the correct sizes.

Computer manufacturers often do not give you a Microsoft Windows Setup DVD that can run the normal repair tools. If you don't have the Microsoft Windows Setup DVD it's a good idea to make a boot CD with partitioning software and NTFS file utilities so that you can repair problems. Without the necessary repair utilities you can only reinstall Windows completely and may have to back up your user files first.

What your recovery discs can do depends on the manufacturer. HP usually has software that can save your personal files and reinstall Windows, but not repair Windows. Acer usually has only a disc that can completely erase the hard disk (including your personal files) and restore the partitions as they were from the factory.

There are basically three different ways to install Linux. The first is the most risky and the last is the least risky in terms of possibly affecting Windows operation.

• Install Linux in a separate partition (dual boot)
• Install with WUBI in Windows NTFS files (dual boot)
• Install in a Virtual Machine disk file to run under Windows (VirtualBox, etc.)

============

To install Linux in a separate partition, the Linux setup program will have to shrink your existing Windows NTFS partition to make room for a new Linux partition. Ubuntu and some other distros include the resizing software and run it automatically. Some distros such as Slackware require manual steps to re-size an existing partition and create a Linux partition. Mint is derived from Ubuntu and should handle resizing the NTFS partition.

When you install Linux in a separate partition, the GRUB boot loader is usually installed to the Master Boot Record (MBR) on the first hard disk. The MBR also contains the Partition Table. Installing to the MBR causes GRUB to start first, before the Windows boot loader (bootmgr). To uninstall Linux you may have to repair Windows. GRUB may also save a copy of the old MBR so that you can uninstall GRUB.

There are other, more advanced ways to install the GRUB boot loader so that the Windows boot loader (bootmgr) starts first. That also requires using the Windows BCDEDIT program and creating a boot sector file to chain to the GRUB boot loader. This is the method that I use to boot Linux but it requires more work than installing GRUB to the MBR. An advantage of this is that problems with the GRUB boot loader (or removing it) do not affect Windows.

============

You can use the WUBI installer to install Ubuntu into a set of normal files located in your normal Windows NTFS partition. That does not require resizing or creating partitions. There is a relatively recent WUBI version for Linux Mint called "Mint4Win" that I haven't tried. I have used the Ubuntu WUBI without any problems.

With WUBI the GRUB boot loader is started by the normal Windows boot loader (bootmgr) by chaining to a file. You can safely delete the Linux files without affecting Windows. The only drawbacks to WUBI are that hibernate to disk does not work and some disk defragmentation programs may relocate the GRUB files and cause GRUB to no longer boot.

============

You can install a Virtual Machine program like VirtualBox. Then create a virtual hard disk file and configure a Virtual Machine (VM). You will need about 256MB to 512MB of RAM for the Virtual Machine to use. More RAM is better, but Ubuntu runs fine with around 384MB (or slightly less). You need at least a 2GHz. Dual Core or 4 GHz. Single Core CPU in order for the Virtual Machine to run relatively fast. Other CPU features like hardware support for Virtual Machines or nested page tables will help. Some 3D effects in GNOME or KDE may not be available running inside a Virtual Machine. That's because the support for 3D graphics is usually limited. If you really want all the eye-candy then a Virtual Machine may not be the best choice.

With a Virtual Machine, the Linux boot files and linux partition are all located inside the virtual disk file. Running in the Virtual Machine, Linux sees a normal hard disk. Outside the Virtual Machine (in Windows) the virtual disk is a normal NTFS file in your normal NTFS partition. Although a Virtual Machine may be slower than using WUBI, it has the least risk of affecting your existing Windows system.

I would say since you have a odd situation, I would just use a virtual machine in this case. I would use VMWare or Virtualbox. I found VirtualPC is a resource hog and is useless.

@worm*

Ah I see. Well on that note I am gonna drop out of this convo. I don't know enough about Windows 7 and the partitions it creates to offer any solutions.

right, the virtual box probably won't work.
it's a 2.1 GHz solo core processor with 2GB of ram so yeah
why exactly couldn't the windows bootloader boot linux?

It can but microsoft chooses not to do so and you will need third party software to do it.

As suggested above, before you try doing anything, make the recovery CD. The reason your attempt to install Grub as indicated in your first post didn't work is because you were pointing it at the windows boot partition (hd0,0). Your recovery disk will allow you to access the recovery partition on your disk for win 7 to repair the installation if you need to and without the disk, I doubt you will be able to recover without getting some assistance from the manufacturer?

There are really two parts to starting up most modern operating systems.

• Booting
• Loading

The distinction may not seem important, but it is when you install multiple operating systems.

Booting starts with the BIOS. The BIOS loads just the very first sector of the boot device (usually first hard disk). That contains the MBR (Master Boot Record). Inside the MBR is some simple boot software and the partition table. The MBR is one sector (512 bytes).

The rest of booting depends on what software is in the MBR. The "standard" software will look at the partition table and find the partition marked as "Active". Linux fdisk refers to the Active flag as the "Boot" flag but it's still just one bit for each partition in the partition table.

The software in the MBR then reads the first sector of the Active partition (Partition Boot Sector). Since the software is extremely simple it uses BIOS services to read the hard disk. After reading the Partition Boot Sector the software in the Partition Boot Sector is executed.

Normally the Partition Boot Sector continues using BIOS services to read a boot-loader into memory. What each Partition Boot Sector does depends on the software installed there. Usually the operating system in a partition installs the software to the Partition Boot Sector for that partition. You can have up to four different partitions, and therefore four different boot-loader programs.

Each partition has a Partition Boot Sector precisely because a boot-loader for one operating system is not expected to know how to load a different operating system. Ignoring boot-loaders for a moment, the traditional way to boot an operating system was to set the Active flag for the partition containing the operating system and then restart the computer. One can still do that if the MBR is left with the "standard" software.

It is normal for GRUB to not know how to load Windows, and Windows "bootmgr" to not know how to load Linux. That's really the assumption in the traditional design of "booting".

So, how do you support multiple operating systems more conveniently than by changing the Active/Boot flags? Boot loaders may not be able to load some other operating system but they can usually read and execute a Partition Boot Sector for some other partition. To use the boot sector software, a boot loader simply has to "jump" to the software in the boot sector. The boot sector software never returns to the previous boot loader and probably reads in some other boot loader. That is called "chaining". Chaining allows a boot loader to start a different boot loader without knowing anything about the other boot loader. The only thing a boot loader needs to know to "chain" is the location of the boot sector (or the file containing the boot sector).

GRUB and LILO can chain directly to any sector of the hard disk, and also can chain to the contents of a file (usually a copy of some boot sector). The Windows bootmgr program can only chain to the contents of a file, but not directly to a sector of the hard disk. So, in order to have Windows start some other boot loader like GRUB, one has to first copy the boot sector from the hard disk into a file. Linux "dd" or the Windows DSKPROBE utility can copy disk sectors into files. For either GRUB or bootmgr you add a menu entry with the correct settings to "chain" to the sector or file.

Which boot loader happens to start first is not important if that boot loader can chain to the other boot loaders. In fact, every boot loader can have a menu choice to chain to the other boot loaders. Then it really won't matter which you start first, or even if you mistakenly select the wrong one from the menu. Just select a different boot loader from the new menu and start the correct one. You can even go around in circles, just starting boot loaders and staring other boot loaders without ever loading an OS

I mentioned five boot sectors, the MBR and one for each partition. It is possible to install a boot loader directly to the MBR. In that case it will always start first, and the Active/Boot flags of partitions are ignored. The default Linux installation often installs GRUB to the MBR. I don't like that because you can do exactly the same thing by installing GRUB to the Linux partition boot sector and then setting that partition's Active/Boot flag. Then you can easily change the Active/Boot flag later to start the Windows boot loader (bootmgr) first.

If you install GRUB to the MBR then the only way to start Windows is by having GRUB chain to the Windows boot loader. GRUB will always start first and if GRUB doesn't work you can't boot Windows either.

================

Now we get to loading. Why is loading separate? Part of the reason is filesystems. Boot code does not understand filesystems, and the BIOS doesn't even understand partitions. A loader has to access files for the operating system being loaded. Microsoft's boot loaders understand NTFS, FAT32 and FAT filesystems. GRUB and LILO understand ext2, FAT32, FAT16 and a few others. GRUB does not understand NTFS and Windows bootmgr does not understand ext2 or other Linux filesystems.

A loader for a particular operating system has to know how to load the operating system and start the operating system. The beginning of the loading process uses the BIOS to read the hard disk, but at some point the operating system takes over disk access using some kind of driver.

Once the operating system takes over disk access it usually continues startup and the boot loader is out of the picture.

Linux loading is rather straightforward. The boot loader reads in the entire kernel image from a file, and then may read an initialization RAM disk (initrd). All of that is read into memory before Linux starts. When Linux starts, it runs the kernel and an initialization task that may use scripts or files from the RAM disk (initrd). Eventually the "init" task on the hard disk runs and finishes Linux startup. The "init" scripts free the memory for the RAM disk image and reuse the memory.

Windows loading is more complicated because the boot loader (bootmgr) uses parts of the kernel and drivers to load other parts of Windows and other drivers. That is faster because the Windows disk driver is more efficient than the simple BIOS services. It's also a lot more complicated and depends on internal details of the Windows operating system. Windows is a lot bigger (in terms of memory used) than Linux and the bootloader has to be a lot more efficient to load Windows quickly.

The goals for GRUB and bootmgr are totally different. GRUB is designed to load as many different kinds of operating systems as possible using an open standard. However, GRUB can only load two files (a boot image and a RAM disk file). Also, those are not loaded very efficiently since the BIOS services are used. The Windows bootmgr is only designed to load the required Windows files (including drivers, registry, etc.) to get Windows started. It is designed to load an arbitrary number of files of different sizes efficiently using parts of the Windows kernel and drivers. Windows even keeps information about each boot and what was loaded so that it can load the files more efficiently on later boots.

GRUB supports loading things besides Linux. The file to be loaded can have a "multiboot" header in a standard format and GRUB can load it. I've used that myself to load embedded software that isn't based on Linux.

================

Since boot software uses the BIOS it has to refer to hard disks in a way that the BIOS understands. The BIOS uses a drive ID byte to identify each hard disk. I do mean hard disk here, and not partition (or drive letter). Here are the drive IDs in hexadecimal, followed by the GRUB device name that means the same thing.

80 (hd0) - First hard disk
81 (hd1) - Second hard disk
82 (hd2) - Third hard disk
83 (hd3) - Fourth hard disk
FF N/A - Disk drive used to load MBR

00 (fd0) - First floppy drive
01 (fd1) - Second floppy drive

When you install GRUB it usually puts drive ID FF in the software written into boot sectors. Windows always assumes that the first hard disk (ID 81) is being loaded and bootmgr must be somewhere on the first hard disk.

Windows identifies disks and partitions using a number of different schemes depending on how far it has gotten through the boot process. The Windows boot managers (NTLDR and bootmgr) each use a different method. NTLDR (Windows XP) uses a disk number (0, 1, 2...) and partition number (1,2,3...). The newer "bootmgr" (Vista / Windows 7) uses the drive serial number in the MBR along with a partition number or 128-bit Univerally Unique Identifier (UUID). NTLDR is configured using a simple "BOOT.INI" text file. Windows "bootmgr" uses a database file in a format similar to the Windows registry (but separate). Changing "bootmgr" menus and settings is done with a program called "BCDEDIT" included with Windows. When you use BCDEDIT the drive letters that it shows are how the currently running OS sees the partitions, and NOT always the drive letters some other Windows OS might use when it is booted by "bootmgr". You have to refer to the partitions using the drive letters assigned by the running OS in order to use "BCDEDIT". That's true even if you're changing the menu entry for booting some other Windows OS or chaining to a file.

As a general rule you should usually put boot loaders on the first hard disk and you should ALWAYS put a boot loader on the same disk with the boot sector that loads it. For example, you don't want to install GRUB to the MBR of the first hard disk if the GRUB files are on the second hard disk. That would require having both disks connected and working to even boot.

I prefer to leave the standard software in the MBR and only install a boot loader to the Partition Boot Sector of the partition containing the boot loader. Some disk partitioning programs don't write the standard software into the MBR and it may be necessary to install that MBR software when you don't install GRUB to the MBR. Since the standard MBR software is quite simple, many disk editing programs can install it. Windows Setup ALWAYS puts the standard software into the MBR and installing Windows may write over the GRUB software if you installed GRUB to the MBR.

When you copy boot sectors into files (for chaining) you can patch the files and change the drive ID bytes to handle unusual situations like a bootloader on some other hard disk. Since chaining is done with a menu choice, you can even have multiple versions of the same boot sector that refer to different drive IDs. You should usually not change drive IDs that are actually in boot sectors on the hard disk. They will almost always be either 81 or FF so that a disk will always boot if it is configured as the first hard disk. Patching boot sectors on the hard disk or in files requires detailed information about the boot sector software and layout for a particular boot loader. You can find the detailed information easily by searching the Internet.

The BIOS does not understand partitions. Boot software in boot sectors has to calculate the correct sector number for the BIOS, numbering the very first hard disk sector as 0. Most boot software does understand something about partitions, but usually not filesystems. It is the boot loader that usually understands filesystems.

The BIOS does not know or care what happens after it starts the MBR boot code. The only time the BIOS gets involved is if the boot software asks the BIOS to read some hard disk sectors into memory. If boot software decides that it can't boot the device it can jump back into the BIOS to try the next boot device.

use the Disk Management within win7 to shrink and expand partitions.
then boot from the Mint cd & install into the <new> blank partition.
& then dual boot both O/Ss.

alright i got the backup media created, now i have a question.
when running linux in virtualbox, how do you go about setting it up?
can virtualbox read the operating system as an disk image file or do i need to burn it to a cd or what?
i think i'm gonna give it a shot atleast before i go formatting my drive