I have OS 11.4 running successfully. It has been a very solid distribution.
I recently downloaded and burned OS 12.2 and then attempted to install it in its own partitions. I customized the installation into /boot, /, and /home partitions, as well as a swap partition. I also choose the boot loader to be grub2, which is the default, to be placed in the /boot partition since I already have a multi-boot product in my MBR.
The installation started successfully, installing various packages while I watched the Details screen. But as soon as it attempted to install the grub2 package it just froze. It never continued and eventually I pressed the reset button on my computer. Thankfully nothing was lost in my hard disk partition setup, but this is really a disappointment that the installation of a major OS fails. It is not something I expected from the usually high quality programmers contributing to OpenSuse.
Is it some known bug that the installation fails when installing grub2 ? I realize grub2 is new with OS, so I must think that something has been overlooked in it setup in 12.x.
I could of course try again and specify that I want to use grub rather than grub2 as my boot loader, and perhaps then no attempt to install grub2 will be made and the installation will go on to completion. But I wanted to check here to see if anyone else has encountered this bug.
I do not need to write grub to the MBR. I already have a multi-boot program using the MBR. I wanted to install grub2 to the /boot partition. But that frze the install.
Check if you have floppy controller enabled in BIOS. It seems to cause all sorts of trouble when probing for existing devices. If enabled, disable it and try once more.
Also you could skip bootloader installation entirely and later directly load GRUB2 core.img from existing multi-boot product. This is deinitely possible with grub1.
Then follow the method in post #2 but use the --force option with grub2-install and the partition of your choice.
# grub2-install --force /dev/sdaX
You mention you have a multi-boot program. I assume you’re multi-booting with other OSes. Any other Unix like (not Linux)? I’m asking because grub2 might fail to install if there are BSD (0xA5, 0xA6, 0xA9) primary partitions. If your multi-boot program (that you didn’t name us) does something arbitrary to the partition table (such as hiding partitions, changing partition IDs) or you have BSD disklabels which lead grub2-probe nowhere, grub2 will indeed fail to install. And this is one out of several different reasons that could cause grub2 to fail to install - not just with openSUSE, but with any Linux distro.
I will try your suggestion with my floppy disk controller. But it was not during the probing for devices phase of the installation that it completely froze. It froze when it was installing packages, and most specifically when it was installing the grub2 package. It had not, AFAICS, yet attempted to initialize the /boot partition with grub2, unless of course it tries to do that as soon as the grub2 package is installed.
I do not see any reason to skip the bootloader installation entirely unless it was really failing because of it. The multi-boot product, which is Acronis OSS, cannot install grub2 from a Linux installation but it can find Linux bootup code in a partition and boot into that partition’s code.
If nothing works I will try using grub instead of grub2 and see if that gets me past the freeze.
I cannot help feeling that the Suse installation team has some sort of bug when the end-user chooses grub2 in the bootloader and also chooses to install grub2 to the installation’s /boot partition as opposed to the MBR.
The multi-boot program is Acronis OSS and it does hide partitons, which simply means that it changes the partition types on-the-fly. In that case what you say makes sense if it is true that grub2 will fail to install to a /boot partition in that case.
But that really seems to me to be a major failing with grub2. Why would it fail to install to a /boot partition because some other partition totally unrelated to the current install has its partition type changed ? The actual partitions I am using in the install have totally valid MBR partition types ( 0x83 for the Linux partitions and 0x82 for the swap partition ).
Do you still have installation logs? They are located under /var/log/YaST2. Could you make them available? It is not the first report that GRUB2 installation does something wrong and I try to find a pattern.
May I ask why you are hiding partitions? I actually happen to do the same thing “on the fly” with Legacy Grub. Actually I do worse, I rewrite partitions entries, so that the primary partitions have different offset and size depending on the operating system to boot. It allows me to “overlapp” BSD partitions in order to use different BSD disklabels. The purpose is to have the same BSD slices in all four BSD disklabels for data or other partitions to share between FreeBSD, NetBSD, openBSD and DragonFly BSD. I don’t know how many people in the world do this. We might probably be 6 or 7. It has worked for years. Actually it still does, except that Linux (Grub2) doesn’t install anymore on these machines. I think it is trying to be too clever, follow the BSD disklabels and gets confused because mine are ‘unconventional’ or simply gets confused with BSD disklabels in general. If I delete the partitions entries in the partition table (write 00 in each BSD primary partition 16 bytes entry), I can install any Linux which uses Grub2 without problems. Thus that’s what I have to do to install Linux nowadays. Next I install my os-prober version, which supports UFS2 (unlike any other os-prober version which tries to mount these partitions read-only as UFS1 and fails) and I don’t have problems. I wouldn’t have “problems” with another os-prober version, just lots of errors. But I don’t think the installation issue is related to os-prober. I think it is a grub2-probe issue. Your problem is probably totally different. However grub2 is very picky while scanning partitions, and you said that you’re hiding partitions. If I would hide partitions by just changing their partition IDs, it wouldn’t work. That’s of course the first thing I tried - because changing a partition ID is easier than deleting and rewriting the entire partition entry.
I agree. I would like not to have to apply such tricks some day. I would suggest the Linux installation kernel doesn’t have support for BSD disklabels (although I’m not 100% it does). That’s nothing interesting it can do with that … except completely confusing grub2-probe.
It tries to be clever. I didn’t have problems at the beginning (under Ubuntu, which has been using Grub2 for a couple years). It started with Grub2 version 1.99. I wrote a post here a long time ago, as I still couldn’t explain what exactly happened.
The disklabel (= the equivalent of the partition table) in each BSD is different and BSD disklabels are (more or less) incompatible with each other. The Linux kernel has support for the different BSD disklabels, which means that it is able to read these partition tables and create the device special files, which will allow you to mount BSD partitions (or slices) under Linux.
I hide partitons because Acronis OSS provides this feature and when I boot into an operating system I only want that system to see the partitions I make available to it. What I have found out is that Linux completely ignores the partition type when it needs to mount a partition, so hiding partitions under Linux, by changing its partition type to something other than the standard Linux 0x83 normally does nothing for me on Linux distributions. I even hid a partition which was a copy of another partition, with the same UUID, and Linux mounted the hidden partition instead of it original !!!
I do find it discouraging that grub2 would pay any attention to partition types given the situation mentioned jusrt above, especially when those partition types are not any partition currently being mounted.
Humm … So the fact that Acronis provides a feature is not a sufficient reason to use it. I’m sure I could provide a lot of features that you will never use.
From which other OSes are you talking about, please?
Yes, it’s OK. It does nothing to Linux … except that:
If you just want to get partitions out of the way, there are better methods to achieve that under Linux by writing udev rules for example. But it’s hard to help you if you don’t tell us which other OSses are so precious that you don’t want Linux to see them.
As you noticed, grub2-probe doesn’t like that.
Absolutely. So you see that it is not the good method. Btw, you should NEVER have 2 partitions with the same UUID (other than a backup). Grub2 uses partition UUIDs and NOT kernel device names. If you plan to keep the cloned partition on the same machine, change its UUID!
You didn’t tell us what you are doing exactly, but unless you’re doing something very complicated (but in this case, you wouldn’t probably ask here), you don’t need this Acronis OSS at all. Grub2 v 2.0 is able to hide partitions on the fly too with the command parttool](GNU GRUB Manual 2.12). although it is not as good as the partnew](GNU GRUB Manual 0.97) and parttype](GNU GRUB Manual 0.97) Legacy Grub commands. I miss these ones.
I suspect your boot manager is the cause of the problem. Dunno if it fakes a partition table or write garbage on the first track, or if grub2-probe just doesn’t like your hidden partitions.
I run 5 Linux distros ( Suse, Fedora, Mandriva, CentOS ( 5.8 & 6.3 ) ), Windows 7, and Windows Vista on the same multi-boot computer.
All Acronis OSS does to “hide” partitions is change the partition type ID. It does not do anything else to obfuscate those partitions. It obviously takes over the MBR and boots into the startup code of whatever OS you tell it to. It can do a few other clever things, but I highly doubt that it is mucking with Linux partitions in any other way to confuse grub2.
The only reason I had two partitiions with the same UUID is because I wanted one of my Linux distro upgrades, which was having trouble reading my second and third hard drives, to find the copy of a / partition on my first hard drive. After updating with this copied / partition I was going to copy it back to its original place and get rid of the copied partition. A number of upgrades seem to have problems with my second and 3rd hard drives, treating them as GPT when they are really MBR. They have no problems when I run the distro but their installations are deficient.
I find Acronis OSS better than grub/grub2. It provides a very good graphical interface for multi-booting. Each to their own.
Perhaps grub2 is at fault <g>. But I want to reiterate that the installation freeze occurs when the grub2 package is being installed, not necessarily when grub2 is doing anything. But perhaps the installation of the grub2 package also attempts to install grub2 in my /boot partition and it hangs because of some confusion of its own.
I just mounted them all to show you. They don’t have to be mounted when they are not needed (and I’m going to unmount them right away).
You don’t need a boot manager for that.
Yes a boot manager needs to put code in the MBR and in the following sectors.
It can not be worse than rewriting partitions geometry, as I do.
There isn’t any valid reason for having 2 partitions with the same UUID. Just don’t do that! Well, you do what you want, but you have be warned, and I won’t say it again.
That’s not fun.
Yes, first it is complicated, Second, you might be adding another level of complexity with your “Acronised” MBR(s). Some distros, such as Fedora, will create a GPT on a blank hard disk, even on non EFI systems. We’ve seen recently in other threads how openSUSE setup (on UEFI systems) will convert a non 100% compliant protective MBR into a hybrid MBR (which in turn would prevent WIndows from booting). I haven’t been able to complete Ubuntu’s installation for years now, without zero filling some partition entries (I’m not talking about just hiding them). So if your MBR is not “picobello” , Grub2 installation might fail, at least during Linux setup.
You should have the boot manager you like, but don’t expect too much support on Linux forums. Most of us simply don’t need third party boot managers, and therefore don’t know them.
No need to reiterate. I know the problem perfectly well. grub2 doesn’t get to do anything because it is busy scanning for devices and gets lost somehow, somewhere. The easiest thing to do is to boot from a live CD, mount your root partition (or /boot partition but don’t make things more complicated as they are. You don’t need a /boot partition!) and install Grub manually. How to achieve this is discussed in other threads. Some people will suggest using YaST. I won’t. But we are a multicultural community.
Most of us simply don’t need third party boot managers
Exactly
And most of us have better things to do than try and find some impossibly complicated messed up way of doing something, that then doesn’t behave as we want, just so we can create forum threads about it.
I’ve not seen any intelligent information here that gives justification for your ‘Heath Robinson’ methods.
Hi,
I will start with a quote from Ogden Nash “Breakfast foods get odder and odder, Its a wise child that knows its fodder”
From the contents of the threads I feel a number of us “newbies” are running into problems with Grub 2! Some would have opted to stay with Grub Legacy. But then Grub 2 would have been adopted by OpenSUSE for good reason! I have been trolling through a number of sites looking for guidance, especially for installing Grub2 in its own dedicated partition. The articles in respect of Ubuntu have a lot about such installation, but (for newbies) its applicability to Open SUSE 12.2 installation and necessary changes if any is a big question. I hope some more experienced member/s is able to spare time to clarify matters.
Personally, I have a Dell Dimension C521 with, two hard disks, one internal and the other external (Seagate GoFlex). The internal HDD is dedicated to Windows Vista, as is the first primary partition on the external drive. The balance space of I TB on the external disk is unallocated. I have set the booting order to DVD Drive, External HDD and Internal HDD. With External HDD disconnected the systems boots into Windows.
I desire to install 12.2 on the external HDD with a dedicated partition (primary) for Grub2, writing the Grub 2 to MBR of the external disk! The rest of the disk will be an extended partition with logical partitions for swap and different distros.
I expect this to work. I would explicitly select correct device (/dev/sda or whatever) and not trust which disk will be chosen by YaST2 as “MBR disk”. Otherwise sounds sane as long /boot is on the same disk as well.
There is no any valid reason for any program to crash or go amok either. If program cannot handle some condition it should fail gracefully and explain why. Not hang forever.
The problem is that installation issues are extremely hard to debug. They usually are unique to specific environment and nobody is willing to reproduce it over and over again to test yet another hypothesis about possible root cause …
I don’t know why so many people spread the idea that it would be better to install Grub in a dedicated partition, but after googling a little bit, it looks indeed like a newbie’s approach:
This is not a valid argument - in my humble opinion. It simply means that you’re unsure about what’s happening to your boot menu while installing a new distro and you’re looking for an apparently “safer” solution. In this case, why taking the risk of multi-booting? There is enough work to do with a single distro (believe me!). However I can see a good reason for installing Grub files in a smaller partition, but it is not the one given by most people. A smaller partition has less chances to get brocken and thus, core.img (or stage2 under legacy Grub) has less chances to be relocated (change offset on disk after a more or less brutal fsck). This is only helpful if the boot loader is installed in a partition boot sector, although booting for a live CD and reisntalling the boot loader if the core has moved is not a big deal either.
If you’re planning to rewrite udev, go on! But in the meantime, how about not arguing about the unique universality of universally unique identifiers? Or do you think that it will help people to believe that if they have 2 partitions with the same UUID and something goes wrong, it won’t be entirely their fault (because that’s what they’re going to understand from your post).
