Bugzilla – Bug 213256
Grub installs in MBR no matter what selected in YaST2-bootloader
Last modified: 2006-11-29 13:19:47 UTC
I selected to install grub on the root partition during installation but it was installed in the MBR. When starting YaST"-bootloader after installation there will be not checkbox checked of the possible bootloader destinations
Created attachment 101868 [details] YaST2.tgz
Boot Loader -> odabrunz
*** Bug 213577 has been marked as a duplicate of this bug. ***
Still in version Beta 1
Then this is a blocker IMHO, it is unacceptable that a installation destroy the MBR for a public test.
*** Bug 186255 has been marked as a duplicate of this bug. ***
The reason for overwriting the MBR is inside YaST, it write a /etc/grub.conf containing 2 setup lines, one for the selected boot partion one for the MBR e.g. setup --stage2=/boot/grub/stage2 (hd1,8) (hd1,8) setup --stage2=/boot/grub/stage2 (hd0) (hd1,8) quit This is not the only bug in YAST2 grub handling, ut also does not write the menu.conf correctely, the first lines with default 0 timeout 8 gfxmenu (hd1,8)/boot/message are missing.
From Bug 186255: ------- Comment #2 from stefan.fent@novell.com 2006-10-25 03:55 MST ------- Depending on what you had on the szstem before, this might have been necessary. MBR is just replaced by generic MBR, which makes sense in most cases. Did you disable this in the checkbox? So is there a change of behaviour now? So far I had to select when I wanted to replace MBR by generic code. Now I have to select if I _don't_ want it? Is that correct? Where can I find the checkbox you are talking about?
The checkboxes are off by default (in the boot loader details section) and I do not change anything there, so they are not the reason for the wrong config.
BTW - from YaST style guide point of view - you shouldn't use checkboxes but rather radio buttons when you want user to select just one option from the list.
Karsten, in your case you won't be able to boot w/o have grub in the MBR, as you try to boot from BIOS 0x81 logical partition. (It might be that you BIOS is capable of doing so, but there's no way to find out) So, in your case the Behaviuor is correct. Holgi, click on 'bootloader options' in the second tab of the bootloader configuration. Downgrading.
did you read my initial report? independently whatever I select in the bootloader it will _ALWAYS_ overwrite my MBR. Read: ALWAYS. And no, it did not do this for 9.1, 9.2, 9.3, 10.0, 10.1, SLED 10, SLES 10, SLES 8, SLES 9, all installed on the same machine. I have even attached YAST Logfiles for you to review.
No it is not correct (and I did not fill a bug because this bug describe exactely my problem: YaST/grub ALWAYS overwrite the MBR). I already have a boot loader in the MBR for all my test partions, until 10.2 Alpha5+ this was never overwritten, if I selected root or boot partion as boot source. The logfiles are the same. I see this wrong behavior on all my test machines with Alpha 5 plus. Never overwrite the MBR if the user did not request it. Only case where it should be the default is, if the HD is fully used by the new install and if it is the only HD.
To sf: The checkbox at 'bootloader options' do not work (does not change anything). Furthermore your statement "MBR is just replaced by generic MBR" is wrong. If you look to the /etc/grub.conf file you will see that (no mather) what you select within the YaST2 bootloader - it will be written to MBR AND boot partition. So you can select what you want (as I mentioned before) it will be written in MBR all the time.
Ok, to clearify: - Yes, the proposal in Beta1 is not what we want (Although at least you can be sure you're able to boot ;-P ) - There might as well be some problems with the interface - To comment #7: _not_ writing grub to MBR in this case would leave you with an unbootable System. Here we would need some kind of checkbox stating: "I know what I'm doing, I don't expect the system to boot by it's own" Finally, we should have 1 (one) bugzilla entry for one bug. This bug is about the wrong proposal. Could you please add bugzilla entries for _each_ of the problems you detect?
Are there any work-arounds for people who want to leave their MBR untouched during installation or update? My (untested) ideas: - make /etc/grub.conf immutable (with chattr +i /etc/grub.conf) - choose the option "Do not install a boot loader (or similar)" - backup the old MBR
I just installed 10.2 Beta1 on AMD64, went to the "Expert" Tab, and checked both "replace MBR with generic code" and "activate partition" (or whatever their exact wordings are). The result was a generic MBR, in case this helps anybody.
comment #19: You can edit the /etc/grub.conf during installation from within YaST and remove the corresponding line.
working on that in perl-Bootloader
BTW: For 'Boot Loader Location' i checked 'Custom Boot Partition', but in the list of partitions all logical partitions are missing.
Beta1Plus has the same problem.
Is fixed with new grub.conf handling in >= 0.4.0 in running system. please confirm whether the behaviour differs in instsys Am available through mobile phone (homesick)
This seems still being present in Beta 2 as when I installed Beta 2 the proposal was to install GRUB on /dev/hde2 but it was installed in MBR instead after the installation.
list of logical partitions addded for beta2+
I started http factory install about 24 hours ago. All those checkboxes need to be replaced with radio buttons so that grub can be installed in only one location. No matter what box or combination of boxes I selected, the summary always reported that grub will be installed on mbr of first HD. Grub did in fact get installed on the root partition as I wanted. So, it doesn't seem to be fixed correctly yet.
reopened because still present in RC1
this should be fixed now, will check tomorrow, finally with RC3
What is the status with RC3?
For me it worked with RC3. I selected to install grub to root partition. It did that and left mbr untouched. So i'm fine with it. To comment 28: the checkboxes are intentional. It should be able to select multiple places simultaneously. This is an expert dialog.
works for me too right now, works really smootly IMO