If windows 7 on my laptop is sda1,sda2,sda3 and I have two further partitions which are debian. I will be removing the linux partitions as part of the install and using them for suse. Every time I get to the disk and boot settings part of the install I get lots of red statements ensure you have got this right before proceeding.
What is the right setting? I believe I installed my grub into the MBR with debian. Just want to make sure everything is bootable when I am done, the guide doesn’t really go into this area much.
A bit more on the “below 128 GB” message you are getting.
I get that on my laptop. Ignoring it is fine.
More specifics. On my laptop, sda1 is the OEM partition (DELL utilities). Windows uses sda2, sda3. I shrunk Windows to use a little less than 100G, and created an extended partition sda4.
I made sda5 a small (100M) partition to be used for “/boot”. Then sda6 is a FAT32 partition that I can share between Windows and linux. Then sda7 for the root partition, sda8 for “/home”, sda9 for swap.
This works fine, and I do not get that 128MB warning. That’s because sda5 (for “/boot”) is entirely below 128MB, and grub is installed there. Incidently, it is set to boot from sda4 (the extended partition).
I later installed a second linux. For that, I used sda10. I currently have opensuse 12.1M5 installed there. When the beta comes out, I’ll install that. On that second linux, I do get the “128MB” warning. However, everything works fine, so I just ignore the warning.
For the second linux, I told it to boot from the root partition. Surprisingly, it did not warn me about that. There’s no way the installer could set that up to work. I had to set that up separately. I created an entry for that in grub for the main linux, which does actually work.
Let me add my normal Partitioning Suggestions as well.
Each hard drive can have up to four PRIMARY partitions, any of which could be marked active and bootable. No matter what you might hear, only one of the first four primary partitions can be booted from. That means you can boot from Primary partitions 1, 2, 3 or 4 and that is all. In order to boot openSUSE, you must load openSUSE and the grub boot loader into one of the first four partitions. Or, your second choice is to load the grub boot loader into the MBR (Master Boot Record) at the start of the disk. The MBR can be blank, like a new disk, it can contain a Windows partition booting code or generic booting code to boot the active partition 1, 2, 3, or 4. Or, as stated before, it can contain the grub boot loader. Why load grub into the MBR then? You do this so that you can “boot” openSUSE from a logical partition, numbered 5 or higher, which is not normally possible. In order to have more than four partitions, one of them (and only one can be assigned as extended) must be a extended partition. It is called an Extended Primary Partition, a container partition, it can be any one of the first four and it can contain one or more logical partitions within. Anytime you see partition numbers 5, 6 or higher for instance, they can only occur inside of the one and only Extended Primary partition you could have.
What does openSUSE want as far as partitions? It needs at minimum a SWAP partition and a “/” partition where all of your software is loaded. Further, it is recommended you create a separate /home partition, which makes it easier to upgrade or reload openSUSE without losing all of your settings. So, that is three more partitions you must add to what you have now. What must you do to load and boot openSUSE from an external hard drive? Number one, you must be able to select your external hard drive as the boot drive in your BIOS setup. Number two, you need to make sure that the external hard drive, perhaps /dev/sdb, is listed as the first hard drive in your grub device.map file and listed as drive hd0. I always suggest that you do not load grub into the MBR, but rather into the openSUSE “/” root primary partition which means a primary number of 1, 2, 3 or 4. If number one is used, then that will be out. You will mark the openSUSE partition as active for booting and finally you must load generic booting code into the MBR so that it will boot the openSUSE partition. I suggest a partition like this:
/dev/sda, Load MBR with generic booting code
/dev/sda1, Primary NTFS Partition for Windows
/dev/sda2, Primary SWAP (4 GB)
/dev/sda3, Primary EXT4 “/” openSUSE Partition Marked Active for booting (80-120 GB)
/dev/sda4, Primary EXT4 “/home” Your main home directory (Rest of the disk)
<OR>
/dev/sda, Load MBR with generic booting code
/dev/sda1, Primary, booting NTFS Partition for Windows (small < 500 mb)
/dev/sda2, Primary, NTFS Partition for Windows (Main / Large Partition)
/dev/sda3, Primary EXT4 “/” openSUSE Partition Marked Active for booting (80-120 GB)
/dev/sda4, Primary Extended Partition (Rest of Disk)
As to partition suggestions, the OP did not specifically indicate whether Windows (any flavor) was to be considered. As a general rule (as in 99.4% of the time), Windows must have at least one (1) primary partition. My remaining Windows/XP has two (2) primary partitions, and the HD containing Windows 7 (now safely esconced in a mylar wrap) has three (3) primary partitions. These requirements may significantly influence your partitioning plans.
If you might install Windows in the future, it will need at least one (1) primary, so plan accordingly. (If my “Windows-less” HD is ever a target for Windows xx or nn, I do have primaries to use. Of course, my openSUSE main environment would have to move to the extended partition.
As to openSUSE, I strongly believe in (and practice ) using a separate “/home” partition. This is by choice, and we can debate the relative merits elsewhere. A separate “/home” reduces the space requirements for the root ("/") partition from 80-120 GB to less than 40GB. I used 30GB in my latest install, and usually have satisfactory results with 20GB.
As to GRUB, I strongly believe in (and practice) generic code in the MBR, and GRUB in the extended partition, for multiple-platform machines. On a single-platform (one copy of <your-favorite-OS>), this may be moot. Do bear in mind that Windows will (at least attempt to) step on the MBR, and my most recent Ubuntu (aka “the other Linux”") install did as well, after cannibalizing my entire extended partition free space. GRUB recovery using Parted Magic may also step on the MBR, although I was able to avoid this whilst recovering from the Ubuntu transgression).
(*Teaser — * )
It is important that the partition plan you create fit your needs, subject, of course, to the restrictions that Windows and others may impose upon you. The time spent in planning now saves a lot of rebuilding (and angst) later.
Just enable both to install Grub in both locations. It’s always a good idea to have Grub in the root partition as well. And if you put it in the extended partition too (and you know how to use diskpart to activate partitions in Windows), you won’t need to use Linux live CDs at all whenever Windows overwrites the MBR or garbages the first track.
Grub in the root partition?
Always. It makes sense for a Linux distro to be able to boot on its own.
Grub in MBR?
Preferably (Highly recommended for Grub2). It makes sense for a boot manager to let you decide which partition to boot, rather than relying on bootflags. This is the purpose of a bootmanager after all. Grub in MBR is also better since it installs a part of its code (stage 1.5) in the sectors following the MBR. However this area might eventually get overwritten by Windows antiviruses or other rootkits, which makes people think (AFAIK only under openSUSE) that writing a generic bootcode in MBR (openSUSE’s default) is a better option. This is not true. It just seems clever in some way to dualboot with Windows.
Grub in the extended partition?
Makes senses if the root partition is a logical one, since logical partitions can not be booted directly. It allows to boot with a generic MBR by setting the bootflag on the extended partition. The trick is used mainly on Windows + openSUSE dualboot and is also the default in openSUSE’s setup. I don’t like the idea (smells too much like Novell/Microsoft agreement - for example, it destroys Grub2 installed in MBR by Ubuntu and latest Debian, and openSUSE as in 11.4 is not able to add them in its boot menu without external help: updategrub for openSUSE Legacy Grub (not update-grub!) ) but it “technically” works, as long as only openSUSE and Windows are concerned.
What happens if someone (something) unsets the bootflag on your extended partition?
What happens if more than one bootflag is set?
What happens if your Grub stage2 has been moved?
Do you still get a Grub shell in case the Grub menu can not be found or just a black screen?
How many hard disks do you have?
Does your multiboot setup also include some Unixes (FreeBSD, openBSD, NetBSD)?
What other OS than Windows (and DOS) use generic MBR?
Again, as long as only Windows and a couple Legacy Grub based Linux distros are concerned, it will work, and if you like it that way, it’s fine. But the method won’t work in all multiboot setups and should therefore not be considered as a golden rule (nor be the default IMO).
Thanks for all the advice, i am at work now so will try this when I get home.
Just to clarify its dual booting windows and debain currently, but debian will be replaced by suse. I wont install further distro’s it will stay a dual boot and I will just virtualbox/xen new distro’s I want to try.
Currently my setup is:
/sda1 # Windows must be utilities like @nrickert’s dell though mine is acer
/sda2 # windows
/sda3 #windows
/sda4 extended partition
sda5 / 20gb Root
sda6 / swap
sda7 / home
Suse correctly identifies that it only needs to format “/” and leaves my home and swap as is.
Will re-read the advice when I get home. It seems that if I don’t want to re-create my partition setup and leave them as is, i will need to enable boot from MBR and disable boot from hard drive.
You don’t “need” to enable boot from MBR, but you might and it’s better (as I already explained). You should also enable boot from root patition (it really doesn’t hurt).
Just like to say a big thank you. All your advice has been very helpful and I have a successful install . For the record I install with boot from MBR and boot from /.
Yes, and do so with respect. I think that is a good way to promote discussion.
Something (Windows, and, surprisingly, Ubuntu) have down just that! I boot up Parted Magic (or a Ubuntu liveCD), and set things to the desired state.
Now the documented GRUB recovery procedure (Re-Install Grub Quickly with Parted Magic) recovers and writes GRUB to the MBR, I tinkered with the procedure, and it 1) locates /boot/grub/menu.lst, 2) restores the MBR and 3) writes GRUB to the desired location (the extended partition, in this case).
I have not posted this procedure yet, as it has not been fully tested, submitted for review and may be risky. One could write GRUB over a location that should not be written.
At the time, I manually corrected GRUB, then use updategrub (yours, I believe) to tIdy things up. I need to test the suggestion of searching for stage2.
No. Now, only openSUSE (main), openSUSE (test), Ubuntu and Mint.
sean@linux-dobl:~> sudo /sbin/fdisk -l
root's password:
Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000d663c
Device Boot Start End Blocks Id System
/dev/sda1 63 62910539 31455238+ 83 Linux
/dev/sda2 62910540 79682399 8385930 82 Linux swap / Solaris
/dev/sda3 79682400 289394909 104856255 83 Linux
/dev/sda4 * 289394971 976773119 343689074+ f W95 Ext'd (LBA)
/dev/sda5 289394973 352305449 31455238+ 7 HPFS/NTFS/exFAT
/dev/sda6 352305513 369077309 8385898+ 82 Linux swap / Solaris
/dev/sda7 369077373 411023024 20972826 83 Linux
/dev/sda8 411023088 444582809 16779861 83 Linux
/dev/sda9 444585984 461361151 8387584 82 Linux swap / Solaris
/dev/sda10 461363200 503306239 20971520 83 Linux
/dev/sda11 503308288 534765567 15728640 83 Linux
/dev/sda12 534767616 576710655 20971520 83 Linux
/dev/sda13 576712704 618655743 20971520 83 Linux
/dev/sda14 618657792 660600831 20971520 83 Linux
sean@linux-dobl:~>
and
sean@linux-dobl:~> findgrub
Root User Permissions are required, Please Enter the ...
root's password:
Find Grub Version 2.3 - Written for openSUSE Forums
- reading MBR on disk /dev/sda ...
- reading bootsector /dev/sda1 (LINUX) ...
- skiping partition /dev/sda2 (swap)
- reading bootsector /dev/sda3 (LINUX) ...
- reading bootsector /dev/sda4 (Extended) ... --> Grub found in /dev/sda4
- searching partition /dev/sda5 (NTFS) ...
- skiping partition /dev/sda6 (swap)
- reading bootsector /dev/sda7 (LINUX) ... --> Grub found in /dev/sda7
- reading bootsector /dev/sda8 (LINUX) ...
- skiping partition /dev/sda9 (swap)
- reading bootsector /dev/sda10 (LINUX) ... --> Grub found in /dev/sda10
- reading bootsector /dev/sda11 (LINUX) ...
- reading bootsector /dev/sda12 (LINUX) ...
- reading bootsector /dev/sda13 (LINUX) ...
- reading bootsector /dev/sda14 (LINUX) ... --> Grub found in /dev/sda14
Press <enter> to Exit findgrub...
sean@linux-dobl:~>
This configuration is “Windows-less”. Partition -sda5 (NTFS) is a non-bootable “data” partition, used for a second backup of somethings I might need to read under Windows. (Remove this HD, mount in an external caddy, etc.) Partition -sda14 is solely a Clonezilla backup of the openSUSE (test) “/”.
I am not irrevocably bound to the “generic boot in MBR” philosophy. It undoubtedly stems from many experiences with recovering the MBR and GRUB courtesy of Windows (to be fair, Windows/7, now conspicuous by its absence). I may try alternate ideas at the next upgrade/install of the main openSUSE base.
I should have asked: What happens if someone (something) unsets the boot flag on your extended partition AND you don’t have a live CD on hand?
I explained somewhere in that thread or in another one that this was NOT the solution - even though it works without a doubt. Why? Because it doesn’t restore the original state but creates another “better” and “safer” situation. The way to restore the previous state would have been to reset the boot flag, either from Windows, using diskpart (although diskpart is a Windows command, which doesn’t understand why you would mark the extended partition as active but will let you do it), or by using fdisk, gparted … or even findgrub -a or updategrub -a (if it ever became installed on a live CD, as several people already suggested.)
That’s fine But what do you think would be wrong with having Grub in MBR? It would simply do its job as a boot manager. When installed on a partition’s boot sector it does not entirely, because it relies on the boot flag. So the boot flag (meaning the BIOS) decides what is going to be booted, not the boot manager (meaning the user), whether what is going to be booted is in turn a boot manager or not. If it fails for some reason, you’ll need a live CD, but the purpose of a boot manager is precisely to help the user avoid booting from external media.
It’s not a philosophy. It’s a religion. It neither considers all the aspects of multibooting, nor does it provides a solution which should work in all situations. It wouldn’t also work with Grub2 or is at least highly discouraged an would require the --force option and manual installing (under Ubuntu):
… installing to a filesystem means that GRUB is vulnerable to its blocks being moved around by filesystem features such as tail packing, or even by aggressive fsck implementations, so this approach is quite fragile; and this approach can only be used if the /boot filesystem is on the same disk that the BIOS boots from, so that GRUB does not have to rely on guessing BIOS drive numbers.
It’s a little bit easier with Legacy Grub, but there are situations where it doesn’t work, especially with more than 3 hard disks, SATA + IDE and some Unixes. Not to mention that without Grub stage 1.5, if stage2 can not be found, you’re lost (without a live CD), and you won’t benefit from Grub stage 1.5 if you put Grub in the extended partition, as shown below:
GNU GRUB version 0.97 (640K lower / 3072K upper memory)
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> find /boot/grub/stage2
(hd0,10)
(hd0,14)
(hd0,18)
(hd1,5)
grub> root (hd0,10)
Filesystem type is ext2fs, partition type 0x83
grub> setup (hd0,3)
Checking if "/boot/grub/stage1" exists... yes
Checking if "/boot/grub/stage2" exists... yes
Checking if "/boot/grub/e2fs_stage1_5" exists... yes
Running "embed /boot/grub/e2fs_stage1_5 (hd0,3)"... failed (this is not fatal)
Running "embed /boot/grub/e2fs_stage1_5 (hd0,10)"... failed (this is not fatal)
Running "install /boot/grub/stage1 (hd0,3) /boot/grub/stage2 p /boot/grub/menu.lst "... succeeded
Done.
This is not fatal, because it works (as you noticed, in your case and in most cases). But it is not optimal either. This is why I disagree with this method being the setup’s default (as in openSUSE “only”, AFAIK). Of course, I don’t care if people use it because it meets their needs or suits their taste.
This post is about Grub2, not about Legacy Grub. Please don’t try to use the commands described here under openSUSE.
To complete the example above, here’s what happens sooner or later - after several fsck checks an repairs - when you install Grub2 in a partition bootsector rather than in MBR. This is unconventional and discouraged, but I’ve seen Legacy Grub + Grub2 multibooters doing so.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can add the following entry to /boot/grub/menu.lst :
###Don't change this comment - YaST2 identifier: Original name: WindowsBootLoader###
title Windows on /dev/sda1
rootnoverify (hd0,0)
chainloader +1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- skipping partition /dev/sda2 (OpenBSD)
- skipping partition /dev/sda3 (NetBSD)
- reading bootsector /dev/sda4 (Extended) ...
- skipping partition /dev/sda5 (swap)
- reading bootsector /dev/sda6 (LINUX) .../usr/local/bat/findgrub: line 265: ^: syntax error: operand expected (error token is "^")
--> Grub2 found in /dev/sda6 => 0x (Ubuntu)
- reading bootsector /dev/sda7 (LINUX) ...
- reading bootsector /dev/sda8 (LINUX) ...
- reading bootsector /dev/sda9 (LINUX) ...
- reading bootsector /dev/sda10 (LINUX) ...
- reading bootsector /dev/sda11 (LINUX) ... --> Grub found in /dev/sda11 => sda11 0x83 (openSUSE)
- reading bootsector /dev/sda12 (LINUX) ...
- reading bootsector /dev/sda13 (LINUX) ...
- reading bootsector /dev/sda14 (LINUX) ...
- reading bootsector /dev/sda15 * (LINUX) ... --> Grub found in /dev/sda15 => sda15 0x83 (Fedora)
- reading bootsector /dev/sda16 (LINUX) ...
- reading bootsector /dev/sda17 (LINUX) ...
- reading bootsector /dev/sda18 (LINUX) ...
- reading bootsector /dev/sda19 (LINUX) ... --> Grub found in /dev/sda19 => sda19 0x83 (Mandriva)
- reading bootsector /dev/sda20 (LINUX) ...
What you see here is a syntax error in findgrub (that I fixed in the latest version - 3.4.3). But a syntax error often occures when a script reads a string or a value it doesn’t expect. In fact, it was expecting a partition number but got that garbage instead at the offset of the filesystem where it was supposed to read the location of the Core:
-> Grub2 found in /dev/sda6 => e8fcffffffa1^]c3U89e5WV89ceS89f783ecff8bcanc1ffus8bK083e9htQ89d1ffb0dc89c2ffb0d8hEstxffuffff
Obviously it didn’t work and didn’t boot.
So I reinstalled Grub2 into this partition:
# **grub-install /dev/sda6**
/usr/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists.
However, blocklists are UNRELIABLE and their use is discouraged..
/usr/sbin/grub-setup: error: if you really want blocklists, use **--force**.
As I said, it’s only possible with the --force option.
# **grub-install --force /dev/sda6**
/usr/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists.
However, blocklists are UNRELIABLE and their use is discouraged..
Installation finished. No error reported.
It was indeed successfully installed:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can add the following entry to /boot/grub/menu.lst :
###Don't change this comment - YaST2 identifier: Original name: WindowsBootLoader###
title Windows on /dev/sda1
rootnoverify (hd0,0)
chainloader +1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- skipping partition /dev/sda2 (OpenBSD)
- skipping partition /dev/sda3 (NetBSD)
- reading bootsector /dev/sda4 (Extended) ...
- skipping partition /dev/sda5 (swap)
- reading bootsector /dev/sda6 (LINUX) ... --> **Grub2 found in /dev/sda6 => sda6 0x83 (Ubuntu)**
- reading bootsector /dev/sda7 (LINUX) ...
- reading bootsector /dev/sda8 (LINUX) ...
- reading bootsector /dev/sda9 (LINUX) ...
- reading bootsector /dev/sda10 (LINUX) ...
- reading bootsector /dev/sda11 (LINUX) ... --> Grub found in /dev/sda11 => sda11 0x83 (openSUSE)
- reading bootsector /dev/sda12 (LINUX) ...
- reading bootsector /dev/sda13 (LINUX) ...
- reading bootsector /dev/sda14 (LINUX) ...
- reading bootsector /dev/sda15 * (LINUX) ... --> Grub found in /dev/sda15 => sda15 0x83 (Fedora)
- reading bootsector /dev/sda16 (LINUX) ...
- reading bootsector /dev/sda17 (LINUX) ...
- reading bootsector /dev/sda18 (LINUX) ...
- reading bootsector /dev/sda19 (LINUX) ... --> Grub found in /dev/sda19 => sda19 0x83 (Mandriva)
- reading bootsector /dev/sda20 (LINUX) ...
Grub installed in MBR with embedded Core or stage 1.5 is not the same as Grub installed in a partition bootsector. This is true for both, Legacy Grub and Grub2, but Grub2 in a partition boot sector is worse - and doesn’t work very long. qed
I have a multiboot system with Win7, opensuse11.4, fedoras and ubuntus. When I first installed 11.4 (after Win7), I placed legacy Grub boot loader in both MBR and 11.4’s root partition so that legacy Grub is the default bootloader in 11.4. From the Grub menu of 11.4 I can boot into 11.4 or any other Os’s. This arrangement has been working fine until now.
Where should I next put the (grub) boot loader when I install openSUSE 12.1 as a second opensuse distro?
Should I put Grub 2 boot loader in the root partition of 12.1?
Or should I place Grub (legacy?) (2?) boot loader in MBR only?
For Fedoras and Ubuntus, even Fedora 16 beta with Grub 2, I always place the boot loader in the root partition of the distro being installed. After reboot, openSUSE 11.4’s legacy Grub controls the booting of any other operating system.
When it comes to openSUSE12.1 (Beta/Final), I am somewhat confused because I don’t know which grub bootloader of the two opensuse’s will take over. Hence the questions in Post#19.
)
