I’ve recently installed openSUSE 11.3 on a Dell M1330 for kicks and to see what it’s like these days. SuSE was my first GNU/Linux experience many years ago. I installed 7.3 and then happily bought 8.0 Professional. What I remember best were the printed handbooks and the red wallpaper with bombs when (ack!) logging on as root. And “Have a lot of fun!” And the ugly fonts from those days…
I already had three other distsros installed and decided it would be fun to do a network install from the hard-drive. I downloaded the net .iso and with some patience and googleknowhow finally located the kernel and initrd on it as well as the necessary repository info. Then grub2 booted directly from the iso and the installation was underway. Most of it was intuitive and I was able to change the suggested partition scheme to what I wanted (new swap and all of SuSE on one partition). The time setting didn’t show the right time, though it’s now correct in KDE without any further adjustment. Kudos to the installer devs.
There are a few points I’d like to give feedback on, even if it is nothing new to the community:
Account defaults: I consider the automatic login and option to have the user password as root password to be poor default selections. I can only imagine there must have been some (possibly heated) discussions around these points in the community, but this sets a tone for less-secure-by-default.
The overview screen “Installation settings,” with the ability to select any of the previous screens from a list, rocks. This is just plain helpful and effectively encourages you to think twice about the settings before proceeding.
The installer overwrote the MBR, although I had imagined it was set not to.
This last point is no show-stopper, but a marked annoyance. The settings were: “Boot from MBR is disabled (enable)” and “Boot from “/” partition is enabled (disable).” (There was a warning that it is not below 128 GB and might not be able to boot, a chance I didn’t mind taking and turned out not to be a problem.) Now I imagine that when the program tells me that booting from the MBR is disabled, that it is not going to install GRUB in the MBR. Upon finishing the install it rebooted; instead of needing to update grub2 from another distro before booting into openSUSE as expected, she booted straight away. Each of the other distros installed uses grub2— As SuSE installed grub legacy, it only detected one of the other distros and couldn’t boot it. To top things off, I have a long, un-memorized WPA key and so couldn’t connect directly from SuSE to the Internet to find the commands to boot manually. I did finally work all of this out, booting into Debian and reinstalling grub2.
So the install was completely successful, though I can’t help noting it wouldn’t have been quite so contorted had it been obvious from the installer just what it was going to do with the MBR. Of course I could and should have looked into this in advance, but I do think it would be more social for the installer to be explicit. I guess it’s not unreasonable though to have to expect some subterfuge from a chameleon.
> There are a few points I’d like to give feedback on, even if it is
> nothing new to the community:
FWIW, I agree with your points but then I’m probably not the typical
user that the install is aiming at. Probably neither are you since you
have more than Win… already installed
> This last point is no show-stopper, but a marked annoyance. The
> settings were: “Boot from MBR is disabled (enable)” and “Boot from “/”
> partition is enabled (disable).” (There was a warning that it is not
> below 128 GB and might not be able to boot, a chance I didn’t mind
> taking and turned out not to be a problem.) Now I imagine that when the
> program tells me that booting from the MBR is disabled, that it is not
> going to install GRUB in the MBR. Upon finishing the install it
> rebooted; instead of needing to update grub2 from another distro before
> booting into openSUSE as expected, she booted straight away. Each of the
> other distros installed uses grub2— As SuSE installed grub legacy, it
> only detected one of the other distros and couldn’t boot it. To top
> things off, I have a long, un-memorized WPA key and so couldn’t connect
> directly from SuSE to the Internet to find the commands to boot
> manually. I did finally work all of this out, booting into Debian and
> reinstalling grub2.
IMHO, the suse grub install is a mess. It hasn’t worked properly for me
for the last several installs I’ve done. It seems to be sensitive to
something in my hardware setup. IIRC there’s a checkbox on one of the
auxiliary screens that decides what if anything it installs to the MBR
(you did find those little buttons that take you to other lists of
But yes, I generally rely on Ubuntu to set up grub for everything
nowadays and why suse hasn’t switched to grub2 isn’t clear to me either.
PS Actually, there’s one other possibility. You say it rebooted directly
after the install but does it keep rebooting directly to this
installation? Because IIRC, the first “reboot” is done without actually
rebooting - kexec, I think its called. What happens after a power cycle?
Yep it did overwrite the MBR with a generic boot code behind your back. That’s because YaST is expecting Windows (which likes generic boot code). This is very unfortunate and should hurt one’s Unix sensibilities. But many openSUSEr like this feature and and have other ideas about how booting should be handled. (I strongly disagree but I often feel lonely).
This ****ing option is enabled by default. First time it did it to me, I thought I had made a mistake. Second time I thought it could not be true. Over the years … I learned to accept that such things exist - well, “over the years” might be exagerated, because this wasn’t always the case. Overwriting the MBR with a generic boot code is not based on any scientific motivation. This was a political decision. … and IMHO a ridiculous and dangerous idea that could only have bloomed in Ballmer’s brain.
Think you over react. If it did not write the generic MBR then you would have situations where those that are replacing their Ubuntu or other with OpenSuse would have things not working. When doing anything but a default install you always need to look at read and understand ALL options. Something has to be default. You seem to maintain many different OS’s thus you may or may not want the MBR overwritten. It all depends. In this case you first told the installer that you want to boot from root. This requires that the MBR be either generic or you want to chain from an existing boot setup. You need to indicate which and in my opinion it is better to assume a MBR rewrite then not. But only the person installing can really know what he/she wants to happen.
While this is partially true, I disagree. Doing so can also create a situation where nothing is working. I guess this is what happened to the OP. If you install openSUSE into logical partitions only (an approach I have seen to often recommended here) and YaST writes a generic MBR, you won’t be able to boot openSUSE either. Under circumstamces (like if you don’t have the bootflag set on a primary partition with a valid bootcode) you won’t be able to boot anything.
Writing a generic boot code is rarely needed. Let us say it is never needed. If you’re running other Linux or Unix, you certainly don’t want that. If you’re running Windows, you must have it already. So what is openSUSE trying to achieve here? For the rare cases where it would be necessary (although I don’t see any except reviving Windows), there is no point to make it the default.
In a situation where you want to replace one Linux distro with another, the installer should replace Grub in MBR with its own Grub and never with a generic boot code. This is the only way to ensure that the system will reboot in any circumstamces. Otherwise, as in the case I mentionned above, it won’t.
Absolutely. It is just that this default is WRONG and based on the assumption that people are running Windows.
That’s perfectly true. But a generic MBR won’t help you to boot openSUSE if you put root in a logical partition.
Yes, but not with a generic boot code, not on Linux! OpenSUSE is the only one to enforce a generic MBR and - while this feature could be useful if applied properly - that should never had become the default behaviour. Regrettably, this makes openSUSE the most Windows friendly Linux distro but also the most tricky one to install in multiboot situations with other Linux.
IMHO, here’s how YaST should handle the situation in a more reasonable way:
if openSUSE is to be installed into logical partitions only, the option “Write generic Boot Code to MBR” should be greyed out and the option “Boot from Master boot record” (which means installing Grub stage1 there) should be enabled by defaut.
if another Grub (either Legacy or Grub2) is present, the user should get a warning and be asked for confirmation.
if root is to be installed in a primary partition and Windows is found, the default options are already correct, except that rewriting a generic bootcode should not be necessary. And everything which is not necessary includes a risk.
Also YaST should stop setting bootflags on logical partition, cause it doesn’t make sense. The fact that it doesn’t hurt and that Fedora does the same is not a good reason to do so. So if root it to be installed into a logical partition, the option “Set active Flag in partition table for boot partition” should be disabled and greyed out.
This is nothing new. Anyone with little experience in multibooting and Grub should have come to this conclusion. Only the desire to facilitate the coexistence between openSUSE and Windows could have motivated the - less efficient and more dangerous - approach taken here by YaST developpers. While this is understandable, this is also debatable.
You install into a logical partition. The boot sector is written to the extended partition (not the logical partition). A generic MBR with the extended partition flagged as active works just fine.
I would prefer installers (linux or Windows) leave the boot code in the MBR unchanged. However, I understand why they don’t. Suppose a user has messed up an install of linux, using the MBR. He decides to reinstall, but put the boot record elsewhere. He now has a messed up MBR that won’t boot, unless a generic MBR is provided by the install.
People like you and me, who don’t want the MBR touched, have enough skills to turn off the generic MBR install (if we think to look for it). Many linux newbies don’t understand enough about how booting works to be able to make those decisions. So it is best that the defaults are adequate for those newbies.
If I am installing anything on a system where I don’t want the MBR touched, I first make a backup of the MBR to somewhere safe. Then I can later reload that if the install monkeys with it.
The defaults are only adequate for Windows users. So in one way, YaST takes care of your Windows more than any other Linux setup. As crazy as it might sound, it makes it possible to repare a Windows which doesn’t boot anymore (due to a garbaged MBR) by installing openSUSE in parallel - since writing a generic boot code is like Windows fixmbr. If on the other hand “those newbies” are not using Windows but other Linux distros - even if they are a minority, I think they still deserve some respect too - they may experience a situation like the one the OP described.
> please_try_again;2285729 Wrote:
>> If you install openSUSE into logical partitions only (an approach I have
>> seen to often recommended here) and YaST writes a generic MBR, you won’t
>> be able to boot openSUSE either.
> You install into a logical partition. The boot sector is written to
> the extended partition (not the logical partition). A generic MBR with
> the extended partition flagged as active works just fine.
I’d just like to say a big thank you to please_try_again for the
explanation of the boot issues, and also to nrickert for this addendum.
It’s the clearest explanation I’ve seen of the options and problems that