Bug 812266

Hi Tim

Could you help to test the yast2-bootloader package in this repository ?

http://download.opensuse.org/repositories/home:/michael-chang:/bnc812266/openSUSE_12.3/

Thanks.

Sure, after installation some parts of the file, like the GRUB_DISTRIBUTOR tag, still seem to be updated/replaced but the theme stays the same.

So from my part I would consider this resolved. Thanks for fixing the issue.

Hi Tim,

Let me explain, the /etc/default/grub now holds default settings and will be overridden by bootloader's proposed value. The GRUB_DISTRIBUTOR has proposed value while GRUB_THEME not.

I know the other way round seems better, that is /etc/default/grub overrides any proposed value but this requires more changes in pbl and grub2 package in order to not break the DVD installation case.

So this fix is a compromise .. do you have any strong opinion to custom other settings?

Not at all, from the Studio site it is fine, I just wanted to mention it.

Hi Tim,

The pull request has been sent to yast bootloader's github repo.

I found this bug in a search.  I was about to report a similar problem (also with 13.1M1).

First install - 32-bit.  I changed the boot options from "resume=/some/path" to "noresume".  On the installed system, it was still the original "resume=...".  Incidentally, the change was because I am using randomly encrypted swap, so the resume won't work.

Second install - also 32-bit.  The same problem.

Okay, neither is vital.  I could edit "/etc/default/grub" after install, then rebuild "initrd" to fix it.

Third install - 64-bit on a UEFI box.  I changed the Distributor field in the installer boot options (from "openSUSE 13.1" to "openSUSE_alt 13.1".  That did not take.  The installer tried to use "opensuse" rather than "opensuse_alt".  And that conflicted with another NVRAM entry.  I finished up with a system that was not bootable.  (I was able to rescue it).

Addendum for comment 6 -- these were all installs using the DVD image, not the live image.

Hi Neil,

For #1 #2 .. Are they regression to 12.3 ? ..

Hm .. if regression happens, this one indeed a related suspicious patch.. :(

> For #1 #2 .. Are they regression to 12.3 ? ..

I'm not sure.

My installs of 12.3 final were to an encrypted LVM, where I don't need to change that "resume=" line.

My best recollection, which could be wrong, is that I did have the same problem when I experimentally installed the education version
  openSUSE-Edu-li-f-e-12.3-1-i686.iso

As for the GRUB_DISTRIBUTOR - I can't be sure on that either.  For the
installation where I used "opensuse_alt", I originally installed as "opensuse" and only changed that later when the conflict caused me problems.

The GRUB_DISTRIBUTOR is the important one for me.  If that is not right, then things will break for every install of a milestone or beta release.  Perhaps I should take preemptive action and change the distributor name of my main 12.3 install, so that future installs won't conflict with that.

Neil,

The GRUB_DISTRIBUTOR could be affected by a kernel bug [1], could you please help to check your kernel outputs any suspicious message like this ?

[  169.877879] efivars: maxsize=0
[  169.877885] efivars: active_available=58354
[  169.877888] efivars: size=112
[  169.877890] efivars: storeage_size=65536
[  170.210621] efivars: maxsize=0
[  170.210622] efivars: active_available=58354
[  170.210623] efivars: size=26
[  170.210624] efivars: storeage_size=65536
[  170.210647] efivars: set_variable() failed: status=8000000000000009



If you frequently update your boot variable, this bug could happen if garbage collecting not triggered somehow according to the criteria of firmware.

[1] https://bugzilla.kernel.org/show_bug.cgi?id=55471

I have a whole other bug report related to that - bug 822770

I don't see how it could affect GRUB_DISTRIBUTOR, because that has to be set before anything is written to NVRAM.

Related to that kernel bug -- it's an example of why its a bad idea to be reinstalling grub for every "mkinitrd".  Every reinstall could do some churning and fragmenting of the NVRAM space.  With frequent kernel updates in Tumbleweed, I am seeing many unnecessary reinstalls of grub, when running "grub2-mkconfig" would be sufficient.

Here's the typical sequence:
  Tumbleweed kernel update messes with NVRAM
  Next boot, the firmware deletes the Windows boot entry.
  Next Windows boot (still possible from the grub menu), Windows puts its boot entry back with highest priority.
  I have to then get into the BIOS settings and change the boot order before I can boot opensuse.

If, instead, "grub2-mkconfig" were run, none of those problems would arise.  The system would just keep working as before, but using the newer kernel.

There are similar problems caused for people who use Windows boot manager to boot linux.

"update-bootloader --refresh" in it's man page

  --refresh
       activate the new config e.g. write boot loader to disk 

are come from the old age of lilo which requires reinstall bootloader each time you update a config. I did have a intention to fix that but the odd is that we cannot break lilo (although it's flagged as unsupported there's people still using it). 

We can proceed by introducing a new --refresh-config and we patch every package other than grub2 that calls "update-bootloader --refresh" in their scriplet to check the loader type and switch accordingly ..

if grub2
  update-bootloader --refresh-config
else
  update-bootloader --refresh
fi

[ don't touch grub unless anyone complain about it ]

Meanwhile, I'm downloading the 13.1 M1 image to check this regression or not.

Steffen,

Did you have any concern we implement comment#12 in 13.1 ?

Thanks.

(In reply to comment #12)

> We can proceed by introducing a new --refresh-config

Well, forcible reinstallation of bootloader was itself added as result of other bug reports

Fri Apr 27 12:06:09 CEST 2012 - mchang@suse.de

- fix after grub2 package update, the system become unbootable. (bnc#758570)

And

if (defined $oper{refresh}) {
    # Always set $avoid_init=0 to guarentee bootloader installed (bnc#759224)
    my $ret = UpdateBootloader(0);
    exit 1 if ( !$ret );
}

So the first question is - are conditions in these bug reports still apply? Or was it just papering over real problems in the first place?

That's an miserable fail attempt from me trying to fix this **superfluous excessive** installation of calling grub2-install and now I'm trying it again (2nd round). Without introducing a new parameter to update-bootloader I do not know how to fix the mess gracefully.

Yeah any risk is still possible when doing a change like this. (so we have milestone ..)

Btw .. that change was actually an revert commit of my failure attempt .. that stupid comment is somehow reflects my bad mood but not the fact.

> Did you have any concern we implement comment#12 in 13.1 ?

I think it's confusing. The user should not need to know the bootloader type
in use. I would keep '--refresh' doing what it should, that is, update the
config and reinstall the loader _if needed_. We might add '--reinstall' and
'--refresh-config' options that make it more clear what's actually done, though.

Thanks. For grub2 we now change to

 --refresh (== --refresh-config)  : only update config
 --refresh-config : only update config
 --reinstall : only install bootloader

This way we can avoid to change many packages but only grub2 to call update-bootloader --reinstall in addition to --refresh.

  update-bootloader --refresh && update-bootloader --reinstall || true

(In reply to comment #18)
 
>   update-bootloader --refresh && update-bootloader --reinstall || true

May be just

update-bootloader --refresh --reinstall || true?

Michael Chang - comment 12

>are come from the old age of lilo which requires reinstall bootloader each time
>you update a config.

I did use lilo for many years -- approx 1995-2006.  And I had to frequently
reinstall lilo for just about anything.

However, since suse 10.1 through opensuse 12.1, I used grub legacy, which
was never unnecessarily reinstalled.  It seemed to work well without
any reinstall (just an update of menu.lst).  I have also experimented with
Mint and Fedora, which seem to manage without a grub2 reinstall.

Andrey mentioned that the change originated with bug 758570.  However, I
see that was for an update to grub2 itself.  It makes sense to reinstall
when grub2 is updated.  And maybe updating the boot loader with Yast should reinstall, or at least have a reinstall option.  But it does not make
sense to reinstall grub whenever a kernel is updated or when some other
software update requires initrd to be rebuilt - updating "grub.cfg" should
be sufficient in those cases.

I can manage either way.  But my concern is for non-technical users who
have trouble coping with the side-effects of grub reinstall.  Many want to
leave their system booting Windows by default, and accessing linux via
the Windows boot manager.  That breaks whenever grub is reinstalled.  And then there are the problems of getting a good boot procedure for UEFI, and having to redo that for every update.

(In reply to comment #20)

> I did use lilo for many years -- approx 1995-2006.  And I had to frequently
> reinstall lilo for just about anything.
> 
> However, since suse 10.1 through opensuse 12.1, I used grub legacy, which
> was never unnecessarily reinstalled.  It seemed to work well without
> any reinstall (just an update of menu.lst).  I have also experimented with
> Mint and Fedora, which seem to manage without a grub2 reinstall.

Yes, I found that grub legacy ignored the avoid_init flag and will only update the config. This makes our plan to implement a reintall which will set avoid_init=0 wont work to it. But I think not too many would care about that as calling grub-install is easy enough to overcome it. 

> 
> Andrey mentioned that the change originated with bug 758570.  However, I
> see that was for an update to grub2 itself.  It makes sense to reinstall
> when grub2 is updated.  And maybe updating the boot loader with Yast should
> reinstall, or at least have a reinstall option.  But it does not make
> sense to reinstall grub whenever a kernel is updated or when some other
> software update requires initrd to be rebuilt - updating "grub.cfg" should
> be sufficient in those cases.

Yes. I agree with you and Andrey. 

> 
> I can manage either way.  But my concern is for non-technical users who
> have trouble coping with the side-effects of grub reinstall.  Many want to
> leave their system booting Windows by default, and accessing linux via
> the Windows boot manager.  That breaks whenever grub is reinstalled.  And then
> there are the problems of getting a good boot procedure for UEFI, and having to
> redo that for every update.

Thanks. Good and strong reason to backing the change.

(In reply to comment #19)

> update-bootloader --refresh --reinstall || true?

When posting the command I'm a bit not certain update-bootloader could handle more than one command at a time, since it can do that I think yours is better.

Now the problem is that I found no easy way to implement pure reinstall without touching refreshing config. The avoid_init=(0|1) will either update config only or performing both reinstall and renew the config. Therefore a naming like reinit could be more suitable.

It now looks like

 --refresh : update config (avoid_init=1)
 --reinit : update config and reintall (avoid_init=0)

Anyway I managed to reproduce the kernel option and grub distributor not written to config problem and fixed it in this commit.

https://github.com/WenhuaChang/yast-bootloader/commit/a553d672e711d905396902665909878d21fdc9ec

And the other patch to deal with the grub2 reintall problem

https://github.com/WenhuaChang/perl-bootloader/commit/7f907101c08eecb34594a0cf144ecccc919bf73a

(In reply to comment #23)
> And the other patch to deal with the grub2 reintall problem
> 
> https://github.com/WenhuaChang/perl-bootloader/commit/7f907101c08eecb34594a0cf144ecccc919bf73a

Please, update also POD ... --reinit is missing.

--><--
operation is one of --add, --remove or --refresh.
--><--

I think it needs clarification to explain difference between --refresh and --reinit.

(In reply to comment #24)

> Please, update also POD ... --reinit is missing.
> 
> --><--
> operation is one of --add, --remove or --refresh.
> --><--
> 
> I think it needs clarification to explain difference between --refresh and
> --reinit.

Thanks. I'm done.

Update for 13.1 Milestone 2.

My change from "resume=/dev/mapper/cr_swap" to "noresume" worked.

My change of Distributor from "openSUSE 13.1" to "openSUSE_alt 13.1" was ignored.

Later, running the installed system, I used Yast --> Bootloader, and again tried
to change the Distributor field.  It was ignored again.  Manually editing
"/etc/default/grub" seems to be the only way to change it.

This bug report is intended to fix the SUSE studio team's problem, that is be able to change the kernel append in it's most part. (And Tim has acked it in comment#4).

As I mentioned in comment#3, to meet your requirement in last comment may have to bring more changes and is out of scope of my intention (wrt this bug ..).

I set this one to be resolved fixed and you can open new one for your problem.

Thanks for your help.