Bug 839081 - Multiple bootloader locations do not work for grub2
Multiple bootloader locations do not work for grub2
Status: RESOLVED WONTFIX
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Bootloader
13.1 Milestone 4
Other Other
: P5 - None : Major (vote)
: ---
Assigned To: Michael Chang
Jiri Srain
SILVER
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-08 05:33 UTC by Andrei Borzenkov
Modified: 2018-04-13 17:19 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrei Borzenkov 2013-09-08 05:33:13 UTC
User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:23.0) Gecko/20100101 Firefox/23.0

As implemented currently, if multiple bootloader locations are checked (i.e. - boot from /boot, boot from root etc), pbl will ultimately run grub2-install for each of them. Because they cannot be embedded, each (except MBR) will use blocklists and point to core.img on /boot. Bvery grub2-install invocation will re-create core.img, thus invalidating previous one. I.e.

- User selects boot from boot, root and extended partition
- pbl first runs grub2-install /dev/boot-partition which creates and points to core.img
- pbl next runs grub2-install /dev/root-partition which creates core.img' and removes core.img
- pbl next runs grub2-install /dev/extended-partition which creates core.img'' and removes core.img'

At this point bootloaders on boot-partition and root-partition point to deleted file. This may appear to work as blocks are not reused immediately, but it will break as soon as blocks are overwritten.

Here is illustration what happens when multiple choices are checked (all except custom):

y2log:2013-09-08 09:06:37 <1> 10.0.2.15(22705) [pbl] yast-1503.1 Core::RunCommand.1641: run /usr/sbin/grub2-install --target=i386-pc --force --skip-fs-probe "(hd0,1)" >/var/log/YaST2/y2log_bootloader 2>&1 - ret 0 + output: /usr/sbin/grub2-bios-setup: warning: File system `ext2' doesn't support embedding.
y2log:2013-09-08 09:06:43 <1> 10.0.2.15(22705) [pbl] yast-1503.1 Core::RunCommand.1641: run /usr/sbin/grub2-install --target=i386-pc --force --skip-fs-probe "(hd0)" >/var/log/YaST2/y2log_bootloader 2>&1 - ret 0 + output: Installation finished. No error reported.
y2log:2013-09-08 09:06:47 <1> 10.0.2.15(22705) [pbl] yast-1503.1 Core::RunCommand.1641: run /usr/sbin/grub2-install --target=i386-pc --force --skip-fs-probe "(hd0,2)" >/var/log/YaST2/y2log_bootloader 2>&1 - ret 0 + output: /usr/sbin/grub2-bios-setup: warning: Attempting to install GRUB to a partitionless disk or to a partition.  This is a BAD idea..
y2log:2013-09-08 09:06:52 <1> 10.0.2.15(22705) [pbl] yast-1503.1 Core::RunCommand.1641: run /usr/sbin/grub2-install --target=i386-pc --force --skip-fs-probe "(hd0,5)" >/var/log/YaST2/y2log_bootloader 2>&1 - ret 0 + output: /usr/sbin/grub2-bios-setup: warning: File system `ext2' doesn't support embedding.

So we have 4 invocations of grub2-install. They result in the following bootloader setup:

============================= Boot Info Summary: ===============================

 => Grub2 (v2.00) is installed in the MBR of /dev/sda and looks at sector 1 of
    the same hard drive for core.img. core.img is at this location and looks
    for (,msdos1)/grub2.

sda1: __________________________________________________________________________

    File system:       ext2
    Boot sector type:  Grub2 (v1.99-2.00)
    Boot sector info:  Grub2 (v1.99-2.00) is installed in the boot sector of
                       sda1 and looks at sector 272874 of the same hard drive
                       for core.img, but core.img can not be found at this
                       location.
    Boot file info:      Grub2 (v2.00) in the file /backup_mbr looks at sector
                       1 of the same hard drive for core.img, but core.img
                       can not be found at this location.
    Operating System:
    Boot files:        /grub2/grub.cfg /grub2/i386-pc/core.img

sda2: __________________________________________________________________________

    File system:       Extended Partition
    Boot sector type:  Grub2 (v1.99-2.00)
    Boot sector info:  Grub2 (v2.00) is installed in the boot sector of sda2
                       and looks at sector 272478 of the same hard drive for
                       core.img. core.img is at this location.

sda5: __________________________________________________________________________

    File system:       ext4
    Boot sector type:  Grub2 (v1.99-2.00)
    Boot sector info:  Grub2 (v2.00) is installed in the boot sector of sda5
                       and looks at sector 274840 of the same hard drive for
                       core.img. core.img is at this location and looks for
                       (,msdos1)/grub2.
    Operating System:  Welcome to openSUSE 12.3 "Dartmouth" - Kernel ().
    Boot files:        /etc/fstab

Note that each of three grub2 installed in partition points to different disk location. Only the last one is correct:

File size of /boot/grub2/i386-pc/core.img is 26413 (26 blocks, blocksize 1024)
 ext logical physical expected length flags
   0       0   136396              12 merged
   1      12   136408               4 merged
   2      16   180529   136412     10 merged,eof

136396*2+2048 == 274840

The problem is that it will break LATER, without ANY connection to original source of problem whatever. This may be the reason for several mysterious "unable to boot after nothing has changed" cases.

I see two ways of fixing it

1. Quick fix - disallow multiple choices for grub2. I'm not sure whether this is useful anyway

2. Long term - use grub2-install for the first time to generate core.img and grub2-setup for all subsequent boot locations.

I am not sure I like 2. It means users MUST use pbl, otherwise result in undetermined as well. May be disallowing multiple choice is the most sensible way.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Comment 1 Michael Chang 2013-09-10 03:28:09 UTC
Hi Andrey,

Thanks. Personally I do prefer #1, the bootloader location UI widget should be mutual exclusive about the selection ..

However such setup came from grub, there might have some people using multiple location in case that mbr fails somehow (or overwritten accidentally by another distro's loader ..) he/she can boot into the system with chainloading partition to rescue or whatever.

For now, I think it's adequate to consider #1 for grub and seeking better solution (like you proposed using grub2-setup ..) .. Yeah .. #2 seems to be the way to go, but be ware of manual or other configuring tools (not sure whether grub2 kcmodules handles installation or not) may break the setup if without taking care the relocating core.img above mentioned ..

Btw, out of curiosity .. how did you dump the blocklist ? :D
Comment 2 Michael Chang 2013-09-10 03:46:07 UTC
May be better enabling multiple location if the file system supports embedding and temporally disable whichever uses blocklist ..

There's EXT4_IOC_SWAP_BOOT from that grub2-setup could leverage for embedding in ext4. The discussion is on grub2 upstream a while ago, but can't remember why it's eventually not implemented.
Comment 3 Andrei Borzenkov 2013-09-10 18:01:25 UTC
(In reply to comment #2)
> May be better enabling multiple location if the file system supports embedding
> and temporally disable whichever uses blocklist ..
> 

That's btrfs and zfs as of today. Pretty much irrelevant so far :)

> There's EXT4_IOC_SWAP_BOOT from that grub2-setup could leverage for embedding
> in ext4. The discussion is on grub2 upstream a while ago, but can't remember
> why it's eventually not implemented.

Because it does not solve the problem in this bug report at all - every time IOC is invoked it allocates *new* area. With exactly the same result - any bootloader pointing to old area becomes invalid.

And you still need to support configuration where this is not available ...

(In reply to comment #1)
>                                                            #2 seems to be the
> way to go, but be ware of manual or other configuring tools (not sure whether
> grub2 kcmodules handles installation or not) may break the setup if without
> taking care the relocating core.img above mentioned ..
> 

I'm not sure. It puts too much low level knowledge about grub2 internals into yast-bootloader/perl-bootloader. 

At some time I toyed with idea to allow multiple devices in grub-bios-setup; this would allow atomic testing whether embedding is possible on all devices. But it is way too intrusive.
Comment 4 Tomáš Chvátal 2018-04-13 17:19:45 UTC
This is automated batch bugzilla cleanup.

The openSUSE Tumbleweed changed its development model at the end of
year 2014. [1]
Which means that most of the older bugs are reported against completely
different product than the current release of openSUSE Tumbleweed.

There is very high probability that this bug is no-longer relevant at all.
As a result we are closing this bug.

If you can reproduce this bug against a current Tumbleweed installation of
openSUSE, or you can still observe it under openSUSE Leap 15.0, please
feel free to reopen this bug.

Thank you for reporting this bug and we are sorry it was not resolved
under the old product.

[1] https://en.opensuse.org/Portal:Tumbleweed