Bug 581652

I just did another M2 install on a different machine with PATA and without RAID. I did not uncheck the boot flag box, but it unset the boot flag anyway, again rendering the machine unbootable from the HD just like in comment 0.

Created attachment 343850 [details]
y2logs.tgz from M2 non-RAID installation

I try to explain it.
"Set active Flag in Partition Table for Boot Partition" means set boot flag. It is the fact that it is not important if you write GRUB to MBR but there exist BIOS-es that doesn't support boot from device if there missing boot flag. It is reason why activating devices is set to true by default.

You can uncheck checkbox and boot flag for device is not set (skip activating).

Your problem is not (un)checked checkbox "Set active Flag in Partition Table for Boot Partition" but wrong configuration of GRUB settings.

You are using MD RAID and it is software raid. In this case GRUB doesn't know to boot directly from MD RAID devices and configuration is written to real devices /dev/sda and /dev/sdb.

yast2-bootloader propose correct configuration and it is to write GRUB to MBR. Your changes "Boot from Root Partition broken booting.

Boot from MBR means write GRUB to MBR but Boot from Root Partition means write GRUB to "/" partition. If you deselect "Boot from MBR" your MBR is not updated and it can include random data or previous boot code which can point to other device.

Finally it means your machine tried to boot but your MBR is not updated and it leads to known result.

I am sorry but you haven't a lot of options for configuration of GRUB if your boot or "/" partition is on MD RAID.

There could be also combination write generic boot code to MBR and set boot flag but ... it is really complicated settings if your boot or "/" partition is logical partition and it doesn't work if there is used MD RAID.

I am sorry the problem is broken GRUB configuration by user. Configuration is valid but it is not bootable ;-)

BTW your root is on /dev/md2 (/dev/sdb9 & /dev/sda9) and finally GRUB was written to your "/" partition

setup --stage2=/boot/grub/stage2 --force-lba (hd0,8) (hd0,8)

as I wrote before it is written to real devices because GRUB doesn't know to boot from software MD RAID.

I installed to sda10/sdb10/md3 immediately prior to opening this bug. I expect installer to accept in such a case (software RAID on only logical partitions, and no RAID devices on primary partitions) that I want no touching of any primary partitions, and no touching of MBR, because that is already taken care of by me 100% prior to installation. Therefore for such a case, touching of boot flags should never happen.

If the installer needs more checkboxes in order for it to understand it must not mess with what it has no business messing with, then please provide them, and not break what is not broken.

If the installer is incapable of writing Grub to its / target because / is on logicals combined as software RAID, then it should simply make a statement to that effect, and not break what was not broken.

(In reply to comment #4)
> You can uncheck checkbox and boot flag for device is not set (skip activating).
 
What happened was correct boot flag was set prior to starting installation. Then installation proceeded to remove the boot flag in conjunction with instruction given it to not touch MBR, which resulted in unbootable system, until I booted emergency mode to reset the flag that the installation process removed. There is no excuse for such an event to happen when the installer was told to do nothing at all involving MBR.

(In reply to comment #4)
> Your problem is not (un)checked checkbox "Set active Flag in Partition Table
> for Boot Partition" but wrong configuration of GRUB settings.

Grub worked perfectly prior to beginning installation, so there was no reason to change it.
 
> You are using MD RAID and it is software raid. In this case GRUB doesn't know
> to boot directly from MD RAID devices and configuration is written to real
> devices /dev/sda and /dev/sdb.

I disallowed writing to MBR, as writing to MBR was and is not necessary.
 
> yast2-bootloader propose correct configuration and it is to write GRUB to MBR.
> Your changes "Boot from Root Partition broken booting.

If yast2-bootloader cannot Grub to /dev/mdx, then it can proceed to tell me so. That is no excuse to disrupt what already works.
 
> Boot from MBR means write GRUB to MBR but Boot from Root Partition means write
> GRUB to "/" partition. If you deselect "Boot from MBR" your MBR is not updated
> and it can include random data or previous boot code which can point to other
> device.

My Grub was installed by me on /dev/sda1 precisely so it and I would control boot as managed by me and only me for multiple distro installations. I do not mount /dev/sda1 on /boot precisely so that no installation program will disrupt it. Yet, the openSUSE installer did precisely that, by removing its boot flag, and preventing the system from booting from the installed and working generic MBR code.

(In reply to comment #5)
> I installed to sda10/sdb10/md3 immediately prior to opening this bug.

Your logs from Description says that your "/" partition is /dev/md2 (sda9 and sdb9) If it is not right you attached wrong logs to bug.

yast2-bootloader tries always propose bootable configuration of GRUB. It is necessary because installation has 2 steps separated by reboot. If you want to configure own settings of installation GRUB you can change it but it deosn't mean that your changes are correct and your system will be bootable.

Next reason is that yast2-bootloader also check your other installed systems and add them to actual new installation. Yes of course it doesn't work on 100% because not all systems and type of devices are supported.

If you are not satisfied with options of yast2-bootloader you can add your ideas for increasing usability or adding new featrures here: https://features.opensuse.org/

Handling MD RAID in yast2-bootloader is supported BUT real configuration is not saved to /dev/md* but to real devices /dev/sda* and /dev/sdb* also other important information is that supported is only RAID1.

I am sorry but from logs in Description is clear that the original configuration of GRUB proposed by yast2-bootloader is correct and bootable. Your changes leads to unbootable system. I am not responsible for your changes. It is not my fault but your choice.

yast2-bootloader is only small part of YaST and it is software. It doesn't support all options of GRUB and using MD RAID also decrease the number of your options how to configure bootloader.

If you want to configure GRUB yourself without YaST assistance you can open yast2-bootloader -> Boot Loader Installation -> Boot Loader: "Do not Install Any Boot Loader".

Created attachment 345439 [details]
y2logs from new M2 install to /dev/md3

(In reply to comment #8)
> If you want to configure GRUB yourself without YaST assistance you can open
> yast2-bootloader -> Boot Loader Installation -> Boot Loader: "Do not Install
> Any Boot Loader".

I just tried to install again. Apparently I cannot select to install no bootloader, because if I try to it then refuses to create a menu.lst that the actual previously installed bootloader needs to find and use for its configfile stanza for booting M2. I could make my own M2 menu.lst, or an M2 emulation stanza complete with kernel and initrd lines, but either would have to be without the benefit of knowing what cmdline options M2 would like used.

So, instead of installing no bootloader, I proceeded by selecting to install bootloader to custom location, without specifying anything in the typing box below the custom location checkbox. That succeeded in leaving the boot flag on the primary partition undisturbed, and left a usable menu.lst in /dev/md3's /boot/grub/ for use by the actual installed bootloader's configfile stanza pointing to M2.

Note that if the previous or these y2logs claim installation to /dev/md2, then there's some other bug with the logging process, as both this and previous M2 installs went to /dev/md3. oS 11.0 lives on /dev/md1, and oS 11.1 lives on /dev/md2.

This may or may not be related, but installation this time failed to create any initrd. I kept a copy of the initrd from the previous M2 install, restored it by booting 11.1, and thus was able to boot the fresh M2 install.

(In reply to comment #8)
> (In reply to comment #5)
> > I installed to sda10/sdb10/md3 immediately prior to opening this bug.
 
> Your logs from Description says that your "/" partition is /dev/md2 (sda9 and
> sdb9) If it is not right you attached wrong logs to bug.

Correct. I mistakenly attached logs from 11.1 which then and currently lives on md2/sda9/sdb9.

As long as an x86 PC HD is not GPT partitioned, in which case primary/logical nomenclature is inapplicable, every partition defined in the end of its very first sector is a primary partition. Thus an extended partition entry in this location is a primary partition entry. With standard MBR code, boot flag must be set on one such partition, and normally only one such partition, in disk sector 1 partition table, regardless whether any primary partition carries or can carry any filesystem. Absent boot flag set on one partition in sector one, the disk cannot be booted from standard MBR code. YaST should not be allowed to leave a disk found and left with standard MBR code, and found with a required boot flag set, to exit without any required boot flag set.

Please attach y2logs.If you're in doubt follow:http://en.opensuse.org/Bugs/YaST
Thanks.

Created attachment 373157 [details]
y2logs from comment 0 installation

https://bugzilla.novell.com/attachment.cgi?id=372494 is y2logs from recent RC1 install on comment 0 system to same md3 /.

Created attachment 382967 [details]
y2logs from fresh 11.3 installation

Unless I'm misremembering (different machine from previous comments; installation target: sda7; no separate /boot):
1-I clicked disable boot from MBR
2-I clicked enable boot from /
3-I deselected boot from extended partition and boot from MBR
4-I selected boot from / partition
5-I left selected set active flag ... (due to bug 618286, while logical action would have been to deselect it, since the correct location already had the flag)
6-I deselected write generic MBR code (because that is what was already there, which I wanted 100% untouched by installation, and also due to bug 618286)

Luckily, I was able to notice in time when the too short countdown to reboot timer engaged, clicked no, switched to tty, did fdisk -l, and discovered the active flag had been moved from where I put it (first primary) to the extended partition (not acceptable).

OK, I check code what it do. I think that handling active flag is not enough covered in yast-bootloader

I've not encountered this problem in 12.1 or 12.2. Worksforme/fixed?

lets hope :-)