Bug 994322

well, purpose of grub_installdevice is that it store information where grub2 is installed as yast2 cannot detect it by itself. Reason for activate and generic_mbr is again that yast2-bootloader read these values and show it to user for current configuration and if user confirm setup, it redo it. So even if something break MBR or remove 'boot' flag from disk, yast2-bootloader will fix it. Without this file, y2-bl do not know previous setup, so cannot help with changing existing configuration.

Currently what y2-bl do is that based on hardware setup propose to write grub2 to 
1) where lives partition for /boot/grub2/i386-pc/
2) extended_partition if /boot is on logical disk
3) where lives disk for /boot/grub2/i386-pc/

It is quite complex logic where to write, depending on many parts and can be overwritten. So I worry that without any replacement y2-bl no longer will know where it will be installed.

My proposel how to handle not so stable device names ( even when using udev ) is to detect such situation in y2-bl and write it to user with option to repropose configuration from scratch.

Ok, so yast also uses this file to store some settings.

Why is the file only readable by root, btw? Do we store some sensitive data here?

Anyway, isn't the idea that in future our standard grub setup is grub into mbr of the disk with boot files? It's not that complex, then (unless the user changes something).

And if we don't store defaults, the file will be gone in most cases. No?

(In reply to Steffen Winterfeldt from comment #2)
> Ok, so yast also uses this file to store some settings.
> 
> Why is the file only readable by root, btw? Do we store some sensitive data
> here?

I do not expect sensitive information there.

> 
> Anyway, isn't the idea that in future our standard grub setup is grub into
> mbr of the disk with boot files? It's not that complex, then (unless the
> user changes something).

Well, if there is plan for such change of setup, it should be properly communicate with customers, so they are aware about such change in proposal as it also have some drawbacks.

> 
> And if we don't store defaults, the file will be gone in most cases. No?

Yes, if we decide about stable defaults (stable in time), then we can ignore such file and simply use defaults if it is not there.

I've hacked a proof of concept:

https://github.com/openSUSE/perl-bootloader/pull/105

This will install grub even if grub_installdevice is missing or has some invalid device name.

It certainly solves not all issues (e.g. grub_installdevice can have more than one device entry) - but shows the direction we could go.

Well my idea is bascally similar to Steffen's, but the install scripts divided by install_location.

Eg
 /usr/lib/bootloader/grub2/install_device_disk
 /usr/lib/bootloader/grub2/install_device_extended
 /usr/lib/bootloader/grub2/install_device_root
 /usr/lib/bootloader/grub2/install_device_boot

And we set install script to one of them

 ln -s /usr/lib/bootloader/grub2/install_device_mbr /usr/lib/bootloader/grub2/install_00

In case we need secondary or third we increase that counter

 ln -s /usr/lib/bootloader/grub2/install_device_mbr /usr/lib/bootloader/grub2/install_01

It's easy to get the install location by following the link, and if things go wrong like the horrendous name scheme change it's easier to adapt the script than config. :)

Hi Steffen,

How do you think about the workaround for bsc#979002 for SP2? I know the schedule is for SP3 to remove grub_installdevice, but it may not help for SP2 guest that require running boot loader update in which invalid or missing device won't work. we may need a fallback method here to cover this case (like what you suggested in comment#4).
Thanks.

I would not do it via symlinks; that's likely to create a mess at some point
during package updates. Also, it's impractical if some tool needs to
determine the current state.

It might be a good opportunity to cut the line and move remaining config
vars out of grub_installdevice into /etc/sysconfig/bootloader.
grub_installdevice is not, as its name suggests, some file used by the
regular grub. So we can as well go the common SUSE-way of using
/etc/sysconfig.

In this case, say, bootloader::DESTINATION with values like 'disk', 'boot',
'root'.

We might put comment 4 into sp2 as it doesn't change the way things work
currently and only steps in if grub_installdevice is obviously invalid. But
for that I'd like some feedback also from Josef and particularly Olaf as to
whether this actually helps.

(In reply to Steffen Winterfeldt from comment #4)
> I've hacked a proof of concept:
> 
> https://github.com/openSUSE/perl-bootloader/pull/105

This seems to rely on df output. Does df return an usable device name, never things like "by-*/*-partN"? Would a stat + mknod be more reliable?

Looks like install() will always set installed even if grub2-install fails.

(In reply to Steffen Winterfeldt from comment #7)
> I would not do it via symlinks; that's likely to create a mess at some point
> during package updates. Also, it's impractical if some tool needs to
> determine the current state.
> 
> It might be a good opportunity to cut the line and move remaining config
> vars out of grub_installdevice into /etc/sysconfig/bootloader.
> grub_installdevice is not, as its name suggests, some file used by the
> regular grub. So we can as well go the common SUSE-way of using
> /etc/sysconfig.
> 
> In this case, say, bootloader::DESTINATION with values like 'disk', 'boot',
> 'root'.
> 
> We might put comment 4 into sp2 as it doesn't change the way things work
> currently and only steps in if grub_installdevice is obviously invalid. But
> for that I'd like some feedback also from Josef and particularly Olaf as to
> whether this actually helps.

Well, in past we try to reduce content of /etc/sysconfig/bootloader because it confuse users of other distribution which have everything in upstream files. So even for this case I suggest to check how do it other distributions? What they do if there is update in grub2 stage1 code? how they recognize in which location it should install it? I am sure RHEL, ubuntu and others have to have way how to do it, so if they use some common place, we should also use it to not confuse our users.

(In reply to Josef Reidinger from comment #9)
> Well, in past we try to reduce content of /etc/sysconfig/bootloader because
> it confuse users of other distribution which have everything in upstream
> files.

Its probably worth a check. But in the end using upstream "solutions" is always good for a laught. And it confuses OUR users already today (why would SUSE knowingly break my system?), see the localized grub.cfg for a prominent example...

Well, grub_installdevice isn't upstream either. So imho, if upstream doesn't have a solution and we have to supplement upstream functionality we should do it the SUSE way. And that would be sysconfig.

That doesn't mean we have to be ignorant about what other distros do but we don't have to blindly follow either.

> This seems to rely on df output. Does df return an usable device name, never
> things like "by-*/*-partN"? Would a stat + mknod be more reliable?

'df' is some classical unix tool and works quite fine. I don't think we improve
by re-implementing finding the device ourselves.

It returns the kernel names and even if it would not it wouldn't matter as long
as the device node it reports actually exists at that time. And I'd trust it
that far.

> Looks like install() will always set installed even if grub2-install fails.

'install_tried' might be a semantically more appropriate name, yes.

My idea was to find a valid device, then install. I don't think it's the task
of the script to handle the situation 'device exists - but grub can't be
installed there'. That would be a real config error and might as well be
visible as such.

Here's POC #2

https://github.com/openSUSE/perl-bootloader/pull/109

This goes a bit further and tries to resolve raid/lvm and crypto setups.

superseded by https://github.com/openSUSE/perl-bootloader/pull/117 which got merged. is this done?

Yes, can be closed; thanks.

SUSE-RU-2018:4085-1: An update that has three recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1079321,1108777,994322
CVE References: 
Sources used:
SUSE Linux Enterprise Server 12-SP3 (src):    perl-Bootloader-0.923-3.9.1
SUSE Linux Enterprise Desktop 12-SP3 (src):    perl-Bootloader-0.923-3.9.1
SUSE CaaS Platform ALL (src):    perl-Bootloader-0.923-3.9.1
SUSE CaaS Platform 3.0 (src):    perl-Bootloader-0.923-3.9.1

openSUSE-RU-2018:4102-1: An update that has three recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1079321,1108777,994322
CVE References: 
Sources used:
openSUSE Leap 42.3 (src):    perl-Bootloader-0.923-2.6.1

SUSE-RU-2018:4161-1: An update that has three recommended fixes can now be installed.

Category: recommended (low)
Bug References: 1079321,1108777,994322
CVE References: 
Sources used:
SUSE Linux Enterprise Module for Development Tools 15 (src):    perl-Bootloader-0.923-4.6.1
SUSE Linux Enterprise Module for Basesystem 15 (src):    perl-Bootloader-0.923-4.6.1

openSUSE-RU-2018:4239-1: An update that has three recommended fixes can now be installed.

Category: recommended (low)
Bug References: 1079321,1108777,994322
CVE References: 
Sources used:
openSUSE Leap 15.0 (src):    perl-Bootloader-0.923-lp150.3.6.1